BGP Hijacking: A Deep Dive

2022-10-07 pentestresearch

Sometimes, during security assessments and penetration tests an in-depth analysis of the Autonomous Systems security posture and BGP routes is overlooked. Here’s my deep dive into a long forgotten protocol on which the internet is built upon.

Nameservers and the Domain Name System

A nameserver is a server that hosts a DNS (Domain Name System), which is an application that runs on the nameserver responsible for translating (resolving) human readable names (such as www.example.com) to the corresponding IP address(es) associated with it.

For semplicity sake, in this article we will consider IPv4 only, but the can be applied to IPv6 as the process is exacly the same for the most part.

This is a simplified overview, but this is not the place to discuss this topic in more details, please do your own research.

sequenceDiagram participant Client participant Nameserver Client->>Nameserver: resolve example.com? Nameserver-->>Client: 93.184.216.34 Client->>93.184.216.34: connect

Autonomous Systems

To provide a more comprehensive assessment of DNS zones for every nameserver in scope, the idea was to provide some edge case example that could invalidate at least one implemented security measure. Let’s analyze the process:

A name server is asked an IP corresponding to the domain requested. (eg:example.com)

The nameserver, which has an IP itself, answers the request.

 # Example request to example.com to Google's DNS (ns.google.com)
 # the answer is: example.com has IP 93.184.216.34
 $ dig example.com +noall +answer @ns.google.com
 example.com.		83860	IN	A	93.184.216.34

The client who asked for the IP address simply visits the IP address and trusts the DNS.

In this process, the validity of the IP address is never questioned. Is there a security measure to guarantee that that IP address will really bring me to the legitimate example.com?

Short answer: there is, but not everyone implements it.

When an IP has to be routed to the correct server the entire world, in the context of public internet, relies on massive public and private owned routers that send the received requests to the hopefully intended next-hop.

These massive routers and relative subnets are called Autonomous Systems.

graph LR subgraph AS1 [Autonomous System 1] R1[Border router] end subgraph AS2 [Autonomous System 2] R2[Border router] end R1 <--> R2

The Border Gateway Protocol

Bastion routers implement BGP (Border Gateway Protocol) because internet is a network of networks, or a network of autonomous systems.

graph TB AS1[AS 1] --- AS2[AS 2] AS2 --- AS3[AS 3] AS3 --- AS4[AS 4] AS4 --- AS1 AS1 --- AS3

BGP is the protocol that allows gateways to know where to send a packet when a certain IP address is requested. Typically, the smallest range of public IPs that a border gateway running BGP can advertise is a C class address range, having at least 254 IPs in the network.

A powerful computer (BGP router), placed inside an important datacenter, could theoretically start to advertise subnets that should not be handled by it. One could configure a computer with the purpose of effectively stealing a company routes.

BGP has not a secure method to establish if a particular server is authorized to present itself with a particular IP address, that is why it is so important that the ones responsible for an IP address make sure that the subnets are advertised correctly. This is done using workarounds to make the protocol secure.

The most effective workaround is RPKI (Resource Public Key Infrastructure) to extend the IRR (Internet Routing Registry). Basically, RPKI is a cryptographically signed entry associated with a route prefix and an autonomous system. To trust a route coming from an autonomous system, a BGP router should check if the RPKI is signed from the correct entity, if the autonomous system has the correct number and if it is authorized to advertise that route. A practical example with google.com:

$ dig google.com              
...
google.com.		99	IN	A	142.250.184.4
...

$ whois 142.250.184.46                                                                                               
...
NetRange:       142.250.0.0 - 142.251.255.255
CIDR:           142.250.0.0/15
NetName:        GOOGLE
...
OriginAS:       AS15169
...

You can validate a route’s RPKI status yourself with Cloudflare’s RPKI validator, passing it the prefix and origin AS number you want to check.

Failing to configure this entry to validate the advertised routes might result in an accidental, or intentional BGP Hijacking, which has major consequences for businesses and government infrastructures, some examples are:

Exploit RPKI Misconfigurations

While this is a theoretical exercise, it would be absolutely possible to exploit an unsigned route to effectively steal a subnet for a short amount of time, which sometimes is enough to deal much damage to a business.

Kenneth Finnegan is a (legendary) engineer who made an exercise, as an individual, to set up and deploy a BGP router borrowing some IP addresses from a friend and demonstrating how it would be possible (and sort of easy) to start being an autonomous system with a border gateway. His journey is described in this blog post.

Looking at this information with the eyes of a very motivated threat actor, possibly state sponsored, it would be trivial to exploit this unsecured opening to unleash all kinds of attacks: credential stealing, fund stealing, social engineering, service denial, man in the middle attacks… etcetera.

Conclusions

While state owned assets are not usually misconfigured, many critical businesses are. A BGP misconfiguration might lead to a brutal denial of service in the best case, but in a consistent loss of funds AND a denial of service in the worst case.

Many businesses are vulnerable. Many are not exploited because they never had a motivated and knowledgeable attacker that was willing to risk this kind of attack.