Re: Amprnet? (was Re: [anti-abuse-wg] Yet another BGP hijacking towards AS16509)

[borg]

Yeah, ARDC sold part of it to Amazon. I doubt they even had right to do
so due to 44/8 was an legacy IP range.. ARIN allowed it.. All too shady.

Anyway, according to AMPRnet that range was unallocated, so no active
radio ham networks were at that range, so I doubt it was someone
from AMPRnet. Getting parts of 44/8 reannounced by different gw
than ucsd.edu is not that easy after all.

-- Original message --

From: Ellenor Agnes Bjornsdottir 
To: nanog@nanog.org
Subject: Amprnet? (was Re: [anti-abuse-wg] Yet another BGP hijacking towards
AS16509)
Date: Tue, 30 Aug 2022 04:13:24 +

Wasn't 44/8 the space for AMPRNet?

I looked it up and they sold part of it to Amazon. Ok. Got it.

Possible that a potential highjack could be a good faith radio ham who
hasn't somehow been updated on the sale of that space? Or more likely to
be a malicious highjack?

On 8/23/22 02:05, Siyuan Miao wrote:
> Amazon was only announcing 44.224.0.0/11 <http://44.224.0.0/11> at first.
> 
> https://bgp.tools/prefix/44.235.216.0/24
> 
> On Tue, Aug 23, 2022 at 4:03 AM Ronald F. Guilmette
>  wrote:
> 
> In message
> ,
> Siyuan Miao  wrote:
> 
> >Hjacking didn't last too long. AWS started announcing a more specific
> >announcement to prevent hijacking around 3 hours later. Kudos to
> Amazon's
> >security team :-)
> 
> Sorry.  I'm missing something here.  If the hijack was of
> 44.235.216.0/24 <http://44.235.216.0/24>, then
> how did AWS propagate a "more specific" than that?
> 
> 
> Regards,
> rfg
> 
> --
> 
> To unsubscribe from this mailing list, get a password reminder, or
> change your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
> 

Amprnet? (was Re: [anti-abuse-wg] Yet another BGP hijacking towards AS16509)

[Ellenor Agnes Bjornsdottir]

Wasn't 44/8 the space for AMPRNet?

I looked it up and they sold part of it to Amazon. Ok. Got it.

Possible that a potential highjack could be a good faith radio ham who
hasn't somehow been updated on the sale of that space? Or more likely to
be a malicious highjack?

On 8/23/22 02:05, Siyuan Miao wrote:

Amazon was only announcing 44.224.0.0/11  at first.

https://bgp.tools/prefix/44.235.216.0/24

On Tue, Aug 23, 2022 at 4:03 AM Ronald F. Guilmette
 wrote:

In message
,
Siyuan Miao  wrote:

>Hjacking didn't last too long. AWS started announcing a more specific
>announcement to prevent hijacking around 3 hours later. Kudos to
Amazon's
>security team :-)

Sorry.  I'm missing something here.  If the hijack was of
44.235.216.0/24 , then
how did AWS propagate a "more specific" than that?


Regards,
rfg

--

To unsubscribe from this mailing list, get a password reminder, or
change your subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/anti-abuse-wg

Re: [EXTERNAL] Re: Yet another BGP hijacking towards AS16509

[Randy Bush]

as a fellow researcher said the other week, ROV, ASPA, ... are intended
to provide safety, not security.

randy

Re: [EXTERNAL] Re: Yet another BGP hijacking towards AS16509

[Job Snijders via NANOG]

Heya,

On Wed, Aug 24, 2022 at 09:17:03AM +0200, Claudio Jeker wrote:
> On Tue, Aug 23, 2022 at 08:07:29PM +0200, Job Snijders via NANOG wrote:
> > In this sense, ASPA (just by itself) suffers the same challenge as
> > RPKI ROA-based Origin Validation: the input (the BGP AS_PATH) is
> > unsigned and unsecured; thus spoofable.
> 
> ASPA enforces that the neighbor AS appears as first element in the
> ASPATH. It also disallows empty ASPATHs from eBGP sessions. 

Yup, this is a helpful property of ASPA. ASPA also nukes routes which
have an AS_SET segment anywhere in the AS_PATH (which helps the
community to get a move on with 
https://datatracker.ietf.org/doc/html/draft-ietf-idr-deprecate-as-set-confed-set)
The addition of type of constraints helps keep the global Internet
routing tables clean.

> Because of this spoofing becomes harder. The problem is that this only
> works for paths that are validated by ASPA (all AS hops have been
> verified). An ASPA-unknown path can still be spoofed.

We might be talking about different types of 'spoofing'. ASPA doesn't
help verify the *authenticity* of the neighbor (or the ASes behind the
neighbor). Does the AS number transmitted in the BGP OPEN message really
belong to the entity that controls the router on the other side of the
link? Is the neighbor on the other side of the IX Route Server really
who they claim they are? ASPA doesn't solve that type of question.

Publication of ASPA records & verification of BGP UPDATES against the
published ASPA records will impose additional constraints on the global
routing table "so and so ASN should only appear behind AS X". This is
helpful, and I'm sure it'll knock down some fake paths generated by BGP
optimizers. :-)

> Spoofing will become much harder once a critical mass of infrastructure
> deployed ASPA.

I'd phrase it as "fat fingering will become even harder". :-)

Route Origin Validation based on RPKI ROAs reduced the number of BGP
routing incidents; but cynical critics could argue "silly you, you
published the exact list of Origin ASNs we need to spoof to bypass
ROV!". Similarly, publication of ASPA records tells the world what
exactly the fabricated AS_PATH should look like to bypass ASPA validation.
This is OK, it just means that ROV + ASPA is not a complete solution.

I think in-band signatures (BGPsec) are also needed to complete the
puzzle.

Kind regards,

Job

Re: [EXTERNAL] Re: Yet another BGP hijacking towards AS16509

[Claudio Jeker]

On Tue, Aug 23, 2022 at 08:07:29PM +0200, Job Snijders via NANOG wrote:
> On Tue, Aug 23, 2022 at 05:18:42PM +, Compton, Rich A wrote:
> > I was under the impression that ASPA could prevent route leaks as well
> > as path spoofing.  This "BGP Route Security Cycling to the Future!"
> > presentation from NANOG seems to indicate this is the case:
> > https://youtu.be/0Fi2ghCnXi0?t=1093 
> 
> I'm not sure how ASPA can prevent AS Path spoofing. Perhaps something
> got lost in translation?
> 
> ASPA records are published in the RPKI, from there a RPKI RP transforms
> the ASN.1/X.509/crypto stuff into something 'plain text'. This 'plain
> text' data is loaded into EBGP routers via RTR, which then compare the
> *plain text* AS_PATH attribute to the table of plain-text ASPA records,
> to determine if it came via an authorized upstream provider or not.
> 
> In this sense, ASPA (just by itself) suffers the same challenge as RPKI
> ROA-based Origin Validation: the input (the BGP AS_PATH) is unsigned and
> unsecured; thus spoofable.

ASPA enforces that the neighbor AS appears as first element in the ASPATH.
It also disallows empty ASPATHs from eBGP sessions.  Because of this
spoofing becomes harder. The problem is that this only works for paths
that are validated by ASPA (all AS hops have been verified). An
ASPA-unknown path can still be spoofed.

Spoofing will become much harder once a critical mass of infrastructure
deployed ASPA.
-- 
:wq Claudio

Re: Yet another BGP hijacking towards AS16509

[Job Snijders via NANOG]

Hi Douglas, group,

On Tue, Aug 23, 2022 at 03:03:31PM -0300, Douglas Fischer wrote:
> I was thinking a little about this case...
> 
> I'm almost certain that this case cited by Siyuan would have been
> avoided if there was a cross-check between the items contained in the
> AS-SET objects (and others such as the Route-Set), and the "member-of"
> attributes of the referred objects.

You are right that stronger 'arcs' ("connections") between the various
IRR objects at first glance potentially offer a solution; unfortunately
the objects exist in separate databases ("namespaces"), one has to be
cautious for object name collisions!

Cross-references (through "member-of:" <> "members:" links) for RPSL
objects only work within a single IRR source, in other words: if objects
exist in the same database. An object in one database can't reference
(through 'member-of:') an object in a different database.

> I participated in a small exchange of ideas about this, and there were
> questions about whether this crosscheck should be done by the consumer
> of the IRR data, or if it should be validated at the time of insertion
> in the base through NRTM.

As far as I understand the data model, only the ultimate consumer of IRR
data would be in a position to enforce some kind of policy (such as
requiring cross-references both ways 'members:' <> 'member-of:'); the
middle layer (software packages like IRRD) lack context.

I know of examples where fairly robust RTBH filters were generated using
members:/member-of pairing as a prerequisite; but I'm not aware of a
"cross-RIR" solution.

Kind regards,

Job

Re: [EXTERNAL] Re: Yet another BGP hijacking towards AS16509

[Job Snijders via NANOG]

On Tue, Aug 23, 2022 at 05:18:42PM +, Compton, Rich A wrote:
> I was under the impression that ASPA could prevent route leaks as well
> as path spoofing.  This "BGP Route Security Cycling to the Future!"
> presentation from NANOG seems to indicate this is the case:
> https://youtu.be/0Fi2ghCnXi0?t=1093 

I'm not sure how ASPA can prevent AS Path spoofing. Perhaps something
got lost in translation?

ASPA records are published in the RPKI, from there a RPKI RP transforms
the ASN.1/X.509/crypto stuff into something 'plain text'. This 'plain
text' data is loaded into EBGP routers via RTR, which then compare the
*plain text* AS_PATH attribute to the table of plain-text ASPA records,
to determine if it came via an authorized upstream provider or not.

In this sense, ASPA (just by itself) suffers the same challenge as RPKI
ROA-based Origin Validation: the input (the BGP AS_PATH) is unsigned and
unsecured; thus spoofable.

> Also, can't the path spoofing protection that BGPsec provides be
> defeated by an attacker advertising a hijacked prefix with a forged
> AS_PATH without BGPsec?

An attacker certainly can try to announce hijacked prefixes with a
forged AS_PATH (knowing that BGPsec-protected paths also exist). But the
attacker has no influence on the local routing policy of other networks.
I imagine that in a 'partial BGPsec' deployment future some operators
might opt to assign a higher LOCAL_PREF to BGPSec secured paths; or
apply a form of 'peerlock' ("I only accept routes with so-and-so ASN if
seen via BGPsec secured paths); this is an area of future study.

> In order to get around this vulnerability, all of the Internet would
> have to only perform BGPsec which doesn't seem realistic.

The vulnerability is "if the operator configures their routers to use
non-signed paths, the operator choose to use a non-signed path" (I hope
this makes sense).

> Security solutions where everyone has to implement the control before
> it works effectively are rarely adopted.

Fully agreed. Fortunately, I see a number of scenarios in which a partial
deployment of BGPsec benefits those who deployed it. Ultimately BGPsec
deployment is a 'selfish' act, as in that the benefits are immediate to
the two adjacent networks using BGPsec to protect the paths between
then.

Perhaps I should prepare a NANOG presentation to outline why BGPsec does
not require 100% deployment to be beneficial?

Kind regards,

Job

Re: Yet another BGP hijacking towards AS16509

[Douglas Fischer]

I was thinking a little about this case...

I'm almost certain that this case cited by Siyuan would have been avoided
if there was a cross-check between the items contained in the AS-SET
objects (and others such as the Route-Set), and the "member-of" attributes
of the referred objects.

I participated in a small exchange of ideas about this, and there were
questions about whether this crosscheck should be done by the consumer of
the IRR data, or if it should be validated at the time of insertion in the
base through NRTM.

Em ter., 23 de ago. de 2022 às 05:50, Job Snijders via NANOG <
nanog@nanog.org> escreveu:

> Dear Siyuan, others,
>
> Thank you for the elaborate write-up and the log snippets. You
> contributed a comprehensive overview of what transpired from a
> publicly-visible perspective, what steps led up to the strike.
>
> I want to jump in on one small point which I often see as a point of
> confusion in our industry:
>
> On Tue, Aug 23, 2022 at 01:54:50AM +0200, Siyuan Miao wrote:
> > Nowadays hijacking a service by forging AS path is pretty easy and
> > RPKI won't be able to solve this (as it validates origin AS and
> > prefixes only) :-(
>
> I do think RPKI can help solve this! The "RPKI" is a cryptographically
> secured distributed database of authorizations for Internet Resource
> Numbers (IP addresses & AS numbers). (((yikes, that's a mouthful :-)))
>
> Another way of looking at the RPKI is as a "general purpose framework",
> a framework on top of which the Internet community can build multiple
> "applications". These applications include:
>
> A) Route Origin Validation (aka "BGP Prefix Origin Validation", RFC 6811)
> B) BGPSec (AS Path validation, RFC 8205)
> C) ASPA (draft-ietf-sidrops-aspa-{profile,verification}, combating
>  routeleaks by publishing what ASNs are your upstreams)
> D) .. and others: https://datatracker.ietf.org/wg/sidrops/documents/
>
> Nowadays Item A ("BGP Origin Validation") is widely deployed: all major
> IP Transit carriers & major IX Route Server operators use RPKI ROAs to
> filter out BGP announcements which have the wrong BGP Origin AS in the
> AS_PATH. This is fantastic (and relatively recent) news!
>
> Item B ("BGPsec") and C ("ASPA") are "work in progress": people are
> building software, running experiments, studying what it would take to
> get those technologies deployed in the wild (the 'production Internet').
>
> BGPSec and ASPA are complementary solutions, each has its challenges and
> opportunities. BGPsec prevents path spoofing, while ASPA can prevent
> route leaks. These are similar but not identical threats that are often
> conflated. ASPA and BGPsec should not be thought of as mutually
> exclusive or incompatible; both of these technologies will support
> routing security in the long term.
>
> I recently co-authored an elaboration to the FCC on where the industry
> stands and how some technologies relate to each other, this might be of
> interest to some folks:
>
> https://sobornost.net/~job/fastly-fcc-noi-secure-internet-routing-reply-comments-20220510-201259363-pdf.pdf
>
> Kind regards,
>
> Job
>


-- 
Douglas Fernando Fischer
Engº de Controle e Automação

Re: [EXTERNAL] Re: Yet another BGP hijacking towards AS16509

[Compton, Rich A]

I was under the impression that ASPA could prevent route leaks as well as path 
spoofing.  This "BGP Route Security Cycling to the Future!" presentation from 
NANOG seems to indicate this is the case: https://youtu.be/0Fi2ghCnXi0?t=1093
Also, can't the path spoofing protection that BGPsec provides be defeated by an 
attacker advertising a hijacked prefix with a forged AS_PATH without BGPsec?  
In order to get around this vulnerability, all of the Internet would have to 
only perform BGPsec which doesn't seem realistic.  Security solutions where 
everyone has to implement the control before it works effectively are rarely 
adopted.

-Rich

On 8/23/22, 2:49 AM, "NANOG on behalf of Job Snijders via NANOG" 
 
wrote:

CAUTION: The e-mail below is from an external source. Please exercise 
caution before opening attachments, clicking links, or following guidance.

Dear Siyuan, others,

Thank you for the elaborate write-up and the log snippets. You
contributed a comprehensive overview of what transpired from a
publicly-visible perspective, what steps led up to the strike.

I want to jump in on one small point which I often see as a point of
confusion in our industry:

On Tue, Aug 23, 2022 at 01:54:50AM +0200, Siyuan Miao wrote:
> Nowadays hijacking a service by forging AS path is pretty easy and
> RPKI won't be able to solve this (as it validates origin AS and
> prefixes only) :-(

I do think RPKI can help solve this! The "RPKI" is a cryptographically
secured distributed database of authorizations for Internet Resource
Numbers (IP addresses & AS numbers). (((yikes, that's a mouthful :-)))

Another way of looking at the RPKI is as a "general purpose framework",
a framework on top of which the Internet community can build multiple
"applications". These applications include:

A) Route Origin Validation (aka "BGP Prefix Origin Validation", RFC 6811)
B) BGPSec (AS Path validation, RFC 8205)
C) ASPA (draft-ietf-sidrops-aspa-{profile,verification}, combating
 routeleaks by publishing what ASNs are your upstreams)
D) .. and others: https://datatracker.ietf.org/wg/sidrops/documents/

Nowadays Item A ("BGP Origin Validation") is widely deployed: all major
IP Transit carriers & major IX Route Server operators use RPKI ROAs to
filter out BGP announcements which have the wrong BGP Origin AS in the
AS_PATH. This is fantastic (and relatively recent) news!

Item B ("BGPsec") and C ("ASPA") are "work in progress": people are
building software, running experiments, studying what it would take to
get those technologies deployed in the wild (the 'production Internet'). 

BGPSec and ASPA are complementary solutions, each has its challenges and
opportunities. BGPsec prevents path spoofing, while ASPA can prevent
route leaks. These are similar but not identical threats that are often
conflated. ASPA and BGPsec should not be thought of as mutually
exclusive or incompatible; both of these technologies will support
routing security in the long term.

I recently co-authored an elaboration to the FCC on where the industry
stands and how some technologies relate to each other, this might be of
interest to some folks:

https://sobornost.net/~job/fastly-fcc-noi-secure-internet-routing-reply-comments-20220510-201259363-pdf.pdf

Kind regards,

Job


E-MAIL CONFIDENTIALITY NOTICE: 
The contents of this e-mail message and any attachments are intended solely for 
the addressee(s) and may contain confidential and/or legally privileged 
information. If you are not the intended recipient of this message or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply e-mail and then delete this message and any attachments. If you are 
not the intended recipient, you are notified that any use, dissemination, 
distribution, copying, or storage of this message or any attachment is strictly 
prohibited.

Re: Yet another BGP hijacking towards AS16509

[Job Snijders via NANOG]

Dear Siyuan, others,

Thank you for the elaborate write-up and the log snippets. You
contributed a comprehensive overview of what transpired from a
publicly-visible perspective, what steps led up to the strike.

I want to jump in on one small point which I often see as a point of
confusion in our industry:

On Tue, Aug 23, 2022 at 01:54:50AM +0200, Siyuan Miao wrote:
> Nowadays hijacking a service by forging AS path is pretty easy and
> RPKI won't be able to solve this (as it validates origin AS and
> prefixes only) :-(

I do think RPKI can help solve this! The "RPKI" is a cryptographically
secured distributed database of authorizations for Internet Resource
Numbers (IP addresses & AS numbers). (((yikes, that's a mouthful :-)))

Another way of looking at the RPKI is as a "general purpose framework",
a framework on top of which the Internet community can build multiple
"applications". These applications include:

A) Route Origin Validation (aka "BGP Prefix Origin Validation", RFC 6811)
B) BGPSec (AS Path validation, RFC 8205)
C) ASPA (draft-ietf-sidrops-aspa-{profile,verification}, combating
 routeleaks by publishing what ASNs are your upstreams)
D) .. and others: https://datatracker.ietf.org/wg/sidrops/documents/

Nowadays Item A ("BGP Origin Validation") is widely deployed: all major
IP Transit carriers & major IX Route Server operators use RPKI ROAs to
filter out BGP announcements which have the wrong BGP Origin AS in the
AS_PATH. This is fantastic (and relatively recent) news!

Item B ("BGPsec") and C ("ASPA") are "work in progress": people are
building software, running experiments, studying what it would take to
get those technologies deployed in the wild (the 'production Internet'). 

BGPSec and ASPA are complementary solutions, each has its challenges and
opportunities. BGPsec prevents path spoofing, while ASPA can prevent
route leaks. These are similar but not identical threats that are often
conflated. ASPA and BGPsec should not be thought of as mutually
exclusive or incompatible; both of these technologies will support
routing security in the long term.

I recently co-authored an elaboration to the FCC on where the industry
stands and how some technologies relate to each other, this might be of
interest to some folks:
https://sobornost.net/~job/fastly-fcc-noi-secure-internet-routing-reply-comments-20220510-201259363-pdf.pdf

Kind regards,

Job

Re: [anti-abuse-wg] Yet another BGP hijacking towards AS16509

[Siyuan Miao]

Amazon was only announcing 44.224.0.0/11 at first.

https://bgp.tools/prefix/44.235.216.0/24

On Tue, Aug 23, 2022 at 4:03 AM Ronald F. Guilmette 
wrote:

> In message <
> cao3camot9gc_evd-cczg06a-o_majmltxlhbxfnaudomyqo...@mail.gmail.com>,
> Siyuan Miao  wrote:
>
> >Hjacking didn't last too long. AWS started announcing a more specific
> >announcement to prevent hijacking around 3 hours later. Kudos to Amazon's
> >security team :-)
>
> Sorry.  I'm missing something here.  If the hijack was of 44.235.216.0/24,
> then
> how did AWS propagate a "more specific" than that?
>
>
> Regards,
> rfg
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
>

Re: [anti-abuse-wg] Yet another BGP hijacking towards AS16509

[Ronald F. Guilmette]

In message 
, 
Siyuan Miao  wrote:

>Hjacking didn't last too long. AWS started announcing a more specific
>announcement to prevent hijacking around 3 hours later. Kudos to Amazon's
>security team :-)

Sorry.  I'm missing something here.  If the hijack was of 44.235.216.0/24, then
how did AWS propagate a "more specific" than that?


Regards,
rfg

Re: Yet another BGP hijacking towards AS16509

[Siyuan Miao]

Just noticed another thing:

➜  ~ whois -h whois.ripe.net -- "--list-versions AS1299" | tail -n10
2862  2022-07-11T14:44:49Z  ADD/UPD
2863  2022-07-27T11:17:25Z  ADD/UPD
2864  2022-08-02T08:43:02Z  ADD/UPD
2865  2022-08-10T12:11:29Z  ADD/UPD


*2866  2022-08-17T10:47:43Z  ADD/UPD2867  2022-08-18T12:53:37Z  ADD/UPD*
% This query was served by the RIPE Database Query Service version 1.103
(WAGYU)

➜  ~ whois -h whois.ripe.net -- "--show-version 2865 AS1299" | grep 209243
➜  ~ whois -h whois.ripe.net -- "--show-version 2866 AS1299" | grep 209243
import: from  AS209243 accept AS209243
mp-import:  afi ipv6 from AS209243 accept AS209243


*➜  ~ whois -h whois.ripe.net  -- "--show-version
2867 AS1299" | grep 209243import: from  AS209243 accept
AS-SET209243mp-import:  afi ipv6 from AS209243 accept AS-SET209243*

Looks like the first thing that AS209243 had done after they got AS1299
transit is ... hijacking an Amazon prefix ..?

On Tue, Aug 23, 2022 at 1:51 AM Siyuan Miao  wrote:

> Hi folks,
>
> Recently I read a post regarding the recent incident of Celer Network and
> noticed a very interesting and successful BGP hijacking towards AS16509.
>
> The attacker AS209243 added AS16509 to their AS-SET and a more specific
> route object for the /24 where the victim's website is in ALTDB:
> (Below is our IRRd4 server NRTM logging, UTC timezone)
>
> irrd.log-20220817.gz:31106270-ADD 96126
>
> irrd.log-20220817.gz:31106280-
>
> irrd.log-20220817.gz:31106281-as-set: AS-SET209243
>
> irrd.log-20220817.gz:31106306-descr:  quickhost set
>
> irrd.log-20220817.gz:31106332-members:AS209243, AS16509
>
> irrd.log-20220817.gz:31106362:mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220817.gz:31106392-changed:cruss...@quickhostuk.net
> 20220816
>
> irrd.log-20220817.gz:31106438-source: ALTDB
>
> irrd.log-20220817.gz:31147549-ADD 96127
>
> irrd.log-20220817.gz:31147559-
>
> irrd.log-20220817.gz:31147560-route:  44.235.216.0/24
>
> irrd.log-20220817.gz:31147588-descr:  route
>
> irrd.log-20220817.gz:31147606-origin: AS16509
>
> irrd.log-20220817.gz:31147626:mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220817.gz:31147656-changed:cruss...@quickhostuk.net
> 20220816
>
> irrd.log-20220817.gz:31147702-source: ALTDB
>
>
> Then they started announcing the prefix ... under another AWS ASN (AS14618)
> I guess AS1299 Arelion doesn't check if the origin AS of an announcement
> is in the customer's AS-SET but it's pretty normal and understandable.
>
>
> https://stat.ripe.net/widget/bgplay#w.resource=44.235.216.0/24=true=1660694458=1661032798=0=null=bgp
>
>
> Type: A > announce Involving: 44.235.216.0/24
> Short description: The new route 34854 1299 209243 14618 has been
> announced
> Path: 34854, 1299, 209243, 14618,
> Community: 1299:35000,34854:3001
> Date and time: 2022-08-17 19:39:50 Collected by: 00-2.56.11.1
>
> Hjacking didn't last too long. AWS started announcing a more specific
> announcement to prevent hijacking around 3 hours later. Kudos to Amazon's
> security team :-)
>
> Type: A > announce Involving: 44.235.216.0/24
> Short description: The new route 58057 34549 5511 1299 16509 has been
> announced
> Path: 58057, 34549, 5511, 1299, 16509,
> Community: 5511:521,5511:666,5511:710,5511:5511,34549:100,34549:5511
> Date and time: 2022-08-17 23:08:47 Collected by: 00-194.50.92.251
>
> The attacker cleaned up the IRR objects on 17 Aug and surprisingly no one
> seems to notice them ...
>
> irrd.log-20220819.gz:26517714-ADD 96196
>
> irrd.log-20220819.gz:26517724-
>
> irrd.log-20220819.gz:26517725:as-set: AS-SET209243
>
> irrd.log-20220819.gz:26517750-descr:  quickhost set
>
> irrd.log-20220819.gz:26517776-members:AS209243, AS35437, AS37497
>
> irrd.log-20220819.gz:26517815-mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220819.gz:26517845-changed:cruss...@quickhostuk.net
> 20220817
>
> irrd.log-20220819.gz:26517891-source: ALTDB
>
>
>
> irrd.log-20220819.gz:26517910-DEL 96197
>
> irrd.log-20220819.gz:26517920-
>
> irrd.log-20220819.gz:26517921-route:  44.235.216.0/24
>
> irrd.log-20220819.gz:26517949-descr:  route
>
> irrd.log-20220819.gz:26517967-origin: AS16509
>
> irrd.log-20220819.gz:26517987-mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220819.gz:26518017-changed:cruss...@quickhostuk.net
> 20220816
>
> irrd.log-20220819.gz:26518063-source: ALTDB
>
>
>
> Nowadays hijacking a service by forging AS path is pretty easy and RPKI
> won't be able to solve this (as it validates origin AS and prefixes only)
> :-(
>
> Regards,
> Siyuan
>
>
>

Yet another BGP hijacking towards AS16509

[Siyuan Miao]

Hi folks,

Recently I read a post regarding the recent incident of Celer Network and
noticed a very interesting and successful BGP hijacking towards AS16509.

The attacker AS209243 added AS16509 to their AS-SET and a more specific
route object for the /24 where the victim's website is in ALTDB:
(Below is our IRRd4 server NRTM logging, UTC timezone)

irrd.log-20220817.gz:31106270-ADD 96126

irrd.log-20220817.gz:31106280-

irrd.log-20220817.gz:31106281-as-set: AS-SET209243

irrd.log-20220817.gz:31106306-descr:  quickhost set

irrd.log-20220817.gz:31106332-members:AS209243, AS16509

irrd.log-20220817.gz:31106362:mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220817.gz:31106392-changed:cruss...@quickhostuk.net 20220816

irrd.log-20220817.gz:31106438-source: ALTDB

irrd.log-20220817.gz:31147549-ADD 96127

irrd.log-20220817.gz:31147559-

irrd.log-20220817.gz:31147560-route:  44.235.216.0/24

irrd.log-20220817.gz:31147588-descr:  route

irrd.log-20220817.gz:31147606-origin: AS16509

irrd.log-20220817.gz:31147626:mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220817.gz:31147656-changed:cruss...@quickhostuk.net 20220816

irrd.log-20220817.gz:31147702-source: ALTDB


Then they started announcing the prefix ... under another AWS ASN (AS14618)
I guess AS1299 Arelion doesn't check if the origin AS of an announcement is
in the customer's AS-SET but it's pretty normal and understandable.

https://stat.ripe.net/widget/bgplay#w.resource=44.235.216.0/24=true=1660694458=1661032798=0=null=bgp


Type: A > announce Involving: 44.235.216.0/24
Short description: The new route 34854 1299 209243 14618 has been announced
Path: 34854, 1299, 209243, 14618,
Community: 1299:35000,34854:3001
Date and time: 2022-08-17 19:39:50 Collected by: 00-2.56.11.1

Hjacking didn't last too long. AWS started announcing a more specific
announcement to prevent hijacking around 3 hours later. Kudos to Amazon's
security team :-)

Type: A > announce Involving: 44.235.216.0/24
Short description: The new route 58057 34549 5511 1299 16509 has been
announced
Path: 58057, 34549, 5511, 1299, 16509,
Community: 5511:521,5511:666,5511:710,5511:5511,34549:100,34549:5511
Date and time: 2022-08-17 23:08:47 Collected by: 00-194.50.92.251

The attacker cleaned up the IRR objects on 17 Aug and surprisingly no one
seems to notice them ...

irrd.log-20220819.gz:26517714-ADD 96196

irrd.log-20220819.gz:26517724-

irrd.log-20220819.gz:26517725:as-set: AS-SET209243

irrd.log-20220819.gz:26517750-descr:  quickhost set

irrd.log-20220819.gz:26517776-members:AS209243, AS35437, AS37497

irrd.log-20220819.gz:26517815-mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220819.gz:26517845-changed:cruss...@quickhostuk.net 20220817

irrd.log-20220819.gz:26517891-source: ALTDB



irrd.log-20220819.gz:26517910-DEL 96197

irrd.log-20220819.gz:26517920-

irrd.log-20220819.gz:26517921-route:  44.235.216.0/24

irrd.log-20220819.gz:26517949-descr:  route

irrd.log-20220819.gz:26517967-origin: AS16509

irrd.log-20220819.gz:26517987-mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220819.gz:26518017-changed:cruss...@quickhostuk.net 20220816

irrd.log-20220819.gz:26518063-source: ALTDB



Nowadays hijacking a service by forging AS path is pretty easy and RPKI
won't be able to solve this (as it validates origin AS and prefixes only)
:-(

Regards,
Siyuan