What are the dangers of next-hop hijacking?
Hi guys, I've been doing some research on BGP security recently and I've discovered a hijacking method called BGP next-hop hijacking. But I don't know how this will cause harm, as modifying the next-hop only redirects traffic. Are there any actual cases of such hijacking parties? Best, *Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
On 1/7/23 4:33 PM, Brandon Zhi wrote:
Hi guys,
I've been doing some research on BGP security recently and I've discovered a hijacking method called BGP next-hop hijacking. But I don't know how this will cause harm, as modifying the next-hop only redirects traffic.
Are there any actual cases of such hijacking parties?
hi, you can find an in-depth analysis on the topic here: http://clathomasprime.github.io/papers/NextHopBGP.pdf work by Clay Thomas and Gavriel Hirsch from princeton -- antonio
Antonio Prado wrote on 07/01/2023 17:22:
you can find an in-depth analysis on the topic here: http://clathomasprime.github.io/papers/NextHopBGP.pdf
work by Clay Thomas and Gavriel Hirsch from princeton
this paper appears to refer to prefix hijacking rather than next-hop IP address hijacking (see page 3, definition 1). Nick
Hello Nick Antonio and Gert, you can find an in-depth analysis on the topic here:
Thanks for the paper, I will continue reading it. I would consider this to be as bad as any sort of "in-flight manipulation
of BGP reachability information" - either changing prefixes, or changing next-hop would permit an attacker to redirect "user traffic", and then interfere with *that*.
When network A is under DDoS attack, and network A switches all of its prefixes to network B in an IXP, I assume this is going on. This may be harmful to network B? Not sure how hard it is today to inject a BGP segment into an existing
TCP session without being able to see the actual TCP stream (IXP filters should prevent ARP/MAC spoofing).
I think every internet exchange has port security, which will be able to filter out unauthorised Mac addresses. But for members binding another member's IP address to their own IX LAN, maybe the internet exchange has checks against Macs and IPs? By scanning ARP and NDP? (This said, I've never actually seen or heard about an actual attack
on a BGP session - it can obviously done, but seems to be either so stealthy that nobody notices, or uninteresting enough that nobody does it)
I think there are three cases of modifying or attacking the next-hop aspect. *Case1:* Assume that Network A and an ISP (Network B) are in the same IXP and Network A sets the next hop of all routes to the IP address of the ISP without authorization or purchase of IP Transit. This will allow the ISP's routes to be used without purchasing the service (output traffic only), which also requires another ISP(Network C) for incoming traffic. The graph is shown below. [image: Case1.png]man-in-the-middle I have heard of instances where these have been caused by a lack of source address validation by the ISP. *Case2:* This attack is more of a man-in-the-middle attack, assuming that Network A and Network B are in an Internet exchange. The attacker, Network C, sets the next hop to itself by capturing the packet UPDATE, which enables it to capture the packet between Network A and Network B. [image: Case2.png] However, as Nick says, this is more likely to happen with multi-hop BGP, as it is difficult for network C to modify packets restricted to BGP when A is directly connected to B. *Case3:* Suppose network A is under DDos attack and network A announces the next hop of the prefixes it sends for network B so that network B will carry this traffic. But it looks like all of these methods are easily prevented, and I recently came up with a method which can even pass RPKI. I call it AS-SET-based BGP hijacking. *AS-SET-based BGP hijacking* Assume network A is hosting a banking website. As compared to the other networks, the AS-PATH between the attacker (network B) and network A is shorter. Attacker Network B can add the victim's (Network A) ASN to its own AS-SET so that filters on other networks will add Network B's prefixes. Network B can then announce Network A's prefix to the other networks. [image: AS-SET-based BGP hijacking.jpg] In response, an attacker could deploy a reverse proxy to the source site (the bank's website) on Network A. and use HTTP authentication to request a TLS/SSL certificate as a way to perform a man-in-the-middle attack. If the bank will monitor the issuance of TLS/SSL certificates, the hijacker can use HTTP directly, which will reduce the likelihood of detection. If the prefix of network A has an RPKI, the attacker network B can pass the RPKI authentication by prepending the ASN of network A to the prefix. It may seem like these conditions are a bit harsh, but they would be much easier if the attacker had created a fake bank website. I don't know much about ASPA, but I think that if "enable first as" is not enabled upstream, the attacker may can still pass the filter? Best, *Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Sun, 8 Jan 2023 at 02:58, Nick Hilliard (INEX) <nick@inex.ie> wrote:
Antonio Prado wrote on 07/01/2023 17:22:
you can find an in-depth analysis on the topic here: http://clathomasprime.github.io/papers/NextHopBGP.pdf
work by Clay Thomas and Gavriel Hirsch from princeton
this paper appears to refer to prefix hijacking rather than next-hop IP address hijacking (see page 3, definition 1).
Nick
Brandon Zhi wrote on 08/01/2023 08:56:
*Case1:*
Assume that Network A and an ISP (Network B) are in the same IXP and Network A sets the next hop of all routes to the IP address of the ISP without authorization or purchase of IP Transit. This will allow the ISP's routes to be used without purchasing the service (output traffic only), which also requires another ISP(Network C) for incoming traffic. The graph is shown below.
Case1.pngman-in-the-middle I have heard of instances where these have been caused by a lack of source address validation by the ISP.
*Case2:*
This attack is more of a man-in-the-middle attack, assuming that Network A and Network B are in an Internet exchange. The attacker, Network C, sets the next hop to itself by capturing the packet UPDATE, which enables it to capture the packet between Network A and Network B.
In the real world, the IXP would terminate the service for the attacking network. I.e. this is a trick you can play only once.
Case2.png
However, as Nick says, this is more likely to happen with multi-hop BGP, as it is difficult for network C to modify packets restricted to BGP when A is directly connected to B. * * *Case3:*
Suppose network A is under DDos attack and network A announces the next hop of the prefixes it sends for network B so that network B will carry this traffic.
But it looks like all of these methods are easily prevented, and I recently came up with a method which can even pass RPKI. I call it AS-SET-based BGP hijacking.
RPKI is not designed to protect against malicious attacks. If you spoof the origin ASN, you bypass RPKI.
*AS-SET-based BGP hijacking*
Assume network A is hosting a banking website. As compared to the other networks, the AS-PATH between the attacker (network B) and network A is shorter.
Attacker Network B can add the victim's (Network A) ASN to its own AS-SET so that filters on other networks will add Network B's prefixes. Network B can then announce Network A's prefix to the other networks.
again, you get to play this trick once. When you're found out, your transit connection will be terminated. Nick
with regards to the last point: cannot confirm that - because it might not be that obvious even the amount of times I get added to random as-sets and having to complain to them to *NEVER GET EVEN AN RESPONSE BACK* is annoying as hell. [pcdog@lappeenranta ~]$ whois as-ubnix-members|grep 41666 members: AS41666 [pcdog@lappeenranta ~]$ I am not peering there, they are not replying. they added me on 5th of january. this is why my stance is that as-sets are inherently broken. also thanks/credits to Benjojo for making a tool that shows me this a lot easier/alerting me ;) Silvan Von: "Nick Hilliard (INEX)" <nick@inex.ie> An: "Brandon Zhi" <Brandon@huize.asia> CC: Manrs-community@elists.manrs.org Gesendet: Sonntag, 8. Januar 2023 23:31:20 Betreff: Re: [manrs-community] What are the dangers of next-hop hijacking? Brandon Zhi wrote on 08/01/2023 08:56: <shortened> again, you get to play this trick once. When you're found out, your transit connection will be terminated. Nick -- Manrs-community mailing list Manrs-community@elists.manrs.org https://elists.manrs.org/mailman/listinfo/manrs-community
Hi, On Sat, Jan 07, 2023 at 11:33:09PM +0800, Brandon Zhi wrote:
I've been doing some research on BGP security recently and I've discovered a hijacking method called BGP next-hop hijacking. But I don't know how this will cause harm, as modifying the next-hop only redirects traffic.
I would consider this to be as bad as any sort of "in-flight manipulation of BGP reachability information" - either changing prefixes, or changing next-hop would permit an attacker to redirect "user traffic", and then interfere with *that*.
Are there any actual cases of such hijacking parties?
... OTOH, for this to have a noticeable affect, you'd need to sit on a shared network with the two routers whose BGP session is modified (injecting into a remote session won't get you the traffic, so this would be more some obscure sort of routing stability attack) - so IXPs are the only place where I could imagine this attack being done. Not sure how hard it is today to inject a BGP segment into an existing TCP session without being able to see the actual TCP stream (IXP filters should prevent ARP/MAC spoofing). Using BGP MD5 would also make this attack close to impossible, even if MD5 is not that much of a strong authentication. (This said, I've never actually seen or heard about an actual attack on a BGP session - it can obviously done, but seems to be either so stealthy that nobody notices, or uninteresting enough that nobody does it) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Brandon Zhi wrote on 07/01/2023 15:33:
I've been doing some research on BGP security recently and I've discovered a hijacking method called BGP next-hop hijacking. But I don't know how this will cause harm, as modifying the next-hop only redirects traffic.
The default for ebgp (in general) is for the router receiving the UPDATE to set the next-hop to be the interface IP address of the router sending the UPDATE. The main practical exception for ebgp is that the sending router can set the NH to another IP address in the same subnet of the connecting interface. Unwinding this, if you have a transit connection, the customer won't be able to set the next-hop to someone else, unless the transit provider is servicing different ASNs on the same subnet, or unless the provider has explicitly overridden this using a configuration knob. I.e. not generally an issue there. The main place where you can expect to see NH rewriting is at IXPs, which is described in rfc7948, section 4.8. There are several situations where there are legitimate reasons to rewrite NHs at IXPs, but occasionally it happens that rewriting NHs is done for malicious purposes, for example hijacking third party bandwidth. For this reason, rfc7948 recommends that IXP route server operators protect against this specific issue. You can find example code here:
https://github.com/inex/IXP-Manager/blob/master/resources/views/api/v4/route...
Also, IXP participants should rewrite next-hop to be the IP address of the peer-as router on all IXP bgp sessions. If you use multihop ebgp for data-plane traffic delivery, you probably get what you deserve.
Are there any actual cases of such hijacking parties?
yes - this was why section 4.8 made it into rfc7948. Nick
Hi, On 07/01/2023, 19:18, "Manrs-community" <manrs-community-bounces@elists.manrs.org> wrote:
Are there any actual cases of such hijacking parties?
yes - this was why section 4.8 made it into rfc7948. Should we consider including this recommendation into the MANRS IXP requirements? Regards, Andrei
* Should we consider including this recommendation into the MANRS IXP requirements?*
I guess they should, checking if the next hop is correct is not a hard task for the route server. But also I think IXPs should forced the IP address and the Mac be corrected (I don't have access to many internet exchanges, as far as I know internet exchanges only have port security.)
*the amount of times I get added to random as-sets and having to complain to them to *NEVER GET EVEN AN RESPONSE BACK* is annoying as hell.*
Well, I have a way for the regional Internet address registry to address that, not by ASPA. Even If ASPA has been completed, and it will take a lot of time to deploy it in all networks. Let's talk about it in this weekend. Best, Brandon Zhi HUIZE LTD www.huize.asia | www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On 2023年1月9日周一 下午4:14 Andrei Robachevsky <robachevsky@isoc.org> wrote:
Hi,
On 07/01/2023, 19:18, "Manrs-community" < manrs-community-bounces@elists.manrs.org> wrote:
Are there any actual cases of such hijacking parties?
yes - this was why section 4.8 made it into rfc7948.
Should we consider including this recommendation into the MANRS IXP requirements?
Regards,
Andrei
Hi guys, I notice that there exists a object on the whois system which calls member-of. Is this parameter designed to prevent your own ASN from being included in the AS-SET without permission? Best, *Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Tue, 10 Jan 2023 at 07:32, Brandon Zhi <Brandon@huize.asia> wrote:
* Should we consider including this recommendation into the MANRS IXP requirements?*
I guess they should, checking if the next hop is correct is not a hard task for the route server. But also I think IXPs should forced the IP address and the Mac be corrected (I don't have access to many internet exchanges, as far as I know internet exchanges only have port security.)
*the amount of times I get added to random as-sets and having to complain to them to *NEVER GET EVEN AN RESPONSE BACK* is annoying as hell.*
Well, I have a way for the regional Internet address registry to address that, not by ASPA. Even If ASPA has been completed, and it will take a lot of time to deploy it in all networks. Let's talk about it in this weekend.
Best,
Brandon Zhi HUIZE LTD www.huize.asia | www.ixp.su | Twitter
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
On 2023年1月9日周一 下午4:14 Andrei Robachevsky <robachevsky@isoc.org> wrote:
Hi,
On 07/01/2023, 19:18, "Manrs-community" < manrs-community-bounces@elists.manrs.org> wrote:
Are there any actual cases of such hijacking parties?
yes - this was why section 4.8 made it into rfc7948.
Should we consider including this recommendation into the MANRS IXP requirements?
Regards,
Andrei
On 16/01/2023, 15:07, "Brandon Zhi" <Brandon@huize.asia> wrote: Hi guys, I notice that there exists a object on the whois system which calls member-of. Is this parameter designed to prevent your own ASN from being included in the AS-SET without permission? In a way. It is used to allow to construct the membership of an as-set by reference (see “mbrs-by-ref:” in RFC2622, https://www.rfc-editor.org/rfc/rfc2622#section-5). But I do not think this feature is widely used. Instead, people list members explicitly in the “members:” attribute. This is aggravated by the fact that the semantics of an as-set is not defined. It can be provider’s customer cone, its peers or all networks in a data-center. All three assume different routing policy, but it is not defined (or rather, the most common case is assumed – a customer cone). Regards, Andrei Best, Brandon Zhi HUIZE LTD www.huize.asia <https://huize.asia/> | www.ixp.su<https://www.ixp.su/> | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Tue, 10 Jan 2023 at 07:32, Brandon Zhi <Brandon@huize.asia<mailto:Brandon@huize.asia>> wrote:
Should we consider including this recommendation into the MANRS IXP requirements?
I guess they should, checking if the next hop is correct is not a hard task for the route server. But also I think IXPs should forced the IP address and the Mac be corrected (I don't have access to many internet exchanges, as far as I know internet exchanges only have port security.)
the amount of times I get added to random as-sets and having to complain to them to *NEVER GET EVEN AN RESPONSE BACK* is annoying as hell.
Well, I have a way for the regional Internet address registry to address that, not by ASPA. Even If ASPA has been completed, and it will take a lot of time to deploy it in all networks. Let's talk about it in this weekend. Best, Brandon Zhi HUIZE LTD www.huize.asia<http://www.huize.asia> | www.ixp.su<http://www.ixp.su> | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On 2023年1月9日周一 下午4:14 Andrei Robachevsky <robachevsky@isoc.org<mailto:robachevsky@isoc.org>> wrote: Hi, On 07/01/2023, 19:18, "Manrs-community" <manrs-community-bounces@elists.manrs.org<mailto:manrs-community-bounces@elists.manrs.org>> wrote:
Are there any actual cases of such hijacking parties?
yes - this was why section 4.8 made it into rfc7948. Should we consider including this recommendation into the MANRS IXP requirements? Regards, Andrei
Hi Andrei, Thank you for your explanation, I have read it https://www.rfc-editor.org/rfc/rfc2622#section-5. I was a little busy the other week, so I can only respond now. It doesn't look like there is a attribute that allows an ASN to only be included in a specific AS-SET? Attribute Value Type aut-num <as-number> mandatory, single-valued, class key .... ...... asset-allowed <as-set-names> optional, multi-valued asset-included <as-set-names> optional, multi-valued asset-allowed: Declare that this ASN can be included in the AS-SET asset-included: Declare that this ASN can only be included in a specific AS-SET. Once enabled, AS-SETs that are not included in asset-allowed and asset-included will not be able to add this ASN as a member. I think RIRs and software (e.g. bgpq4) working together will solve the problem better. For RIRs, stop AS-SET from introducing unauthorized ASNs. This also requires the help of software, because there are many IRRDBs in the world. For software, the asset-included parameter in the ASN should be checked while updating the prefix from the AS-SET and refreshing the filter. If the AS-SET includes an ASN that has been added without authorization, then this prefixes from this ASN will be ignored. Best, *Brandon Zhi* HUIZE LTD www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus. On Mon, 16 Jan 2023 at 16:52, Andrei Robachevsky <robachevsky@isoc.org> wrote:
On 16/01/2023, 15:07, "Brandon Zhi" <Brandon@huize.asia> wrote:
Hi guys,
I notice that there exists a object on the whois system which calls member-of.
Is this parameter designed to prevent your own ASN from being included in the AS-SET without permission?
In a way. It is used to allow to construct the membership of an as-set by reference (see “mbrs-by-ref:” in RFC2622, https://www.rfc-editor.org/rfc/rfc2622#section-5).
But I do not think this feature is widely used. Instead, people list members explicitly in the “members:” attribute. This is aggravated by the fact that the semantics of an as-set is not defined. It can be provider’s customer cone, its peers or all networks in a data-center. All three assume different routing policy, but it is not defined (or rather, the most common case is assumed – a customer cone).
Regards,
Andrei
Best,
*Brandon Zhi*
HUIZE LTD
www.huize.asia <https://huize.asia/>| www.ixp.su | Twitter
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
On Tue, 10 Jan 2023 at 07:32, Brandon Zhi <Brandon@huize.asia> wrote:
* Should we consider including this recommendation into the MANRS IXP requirements?*
I guess they should, checking if the next hop is correct is not a hard task for the route server. But also I think IXPs should forced the IP address and the Mac be corrected (I don't have access to many internet exchanges, as far as I know internet exchanges only have port security.)
* the amount of times I get added to random as-sets and having to complain to them to *NEVER GET EVEN AN RESPONSE BACK* is annoying as hell.*
Well, I have a way for the regional Internet address registry to address that, not by ASPA. Even If ASPA has been completed, and it will take a lot of time to deploy it in all networks. Let's talk about it in this weekend.
Best,
Brandon Zhi HUIZE LTD www.huize.asia | www.ixp.su | Twitter
This e-mail and any attachments or any reproduction of this e-mail in whatever manner are confidential and for the use of the addressee(s) only. HUIZE LTD can’t take any liability and guarantee of the text of the email message and virus.
On 2023年1月9日周一 下午4:14 Andrei Robachevsky <robachevsky@isoc.org> wrote:
Hi,
On 07/01/2023, 19:18, "Manrs-community" < manrs-community-bounces@elists.manrs.org> wrote:
Are there any actual cases of such hijacking parties?
yes - this was why section 4.8 made it into rfc7948.
Should we consider including this recommendation into the MANRS IXP requirements?
Regards,
Andrei
participants (6)
-
Andrei Robachevsky -
Antonio Prado -
Brandon Zhi -
Gert Doering -
Nick Hilliard (INEX) -
Silvan M. Gebhardt