BGP hijacking is how attackers can silently divert huge swathes of internet traffic, making your data go wherever they please.
Imagine the internet as a massive, interconnected highway system. BGP (Border Gateway Protocol) is the GPS system that guides traffic between these different networks (Autonomous Systems, or ASes). When a network wants to announce its presence and how to reach its IP addresses, it tells its neighbors about it using BGP. This announcement is called a "BGP prefix advertisement."
Here’s a live example of what a BGP announcement looks like from the perspective of a router, using the vtysh command on a Cisco-like device:
router bgp 65001
neighbor 192.168.1.2 remote-as 65002
!
address-family ipv4
network 192.0.2.0/24
neighbor 192.168.1.2 activate
neighbor 192.168.1.2 route-map INBOUND in
neighbor 192.168.1.2 route-map OUTBOUND out
exit-address-family
In this snippet:
router bgp 65001: We are configuring BGP for AS 65001.neighbor 192.168.1.2 remote-as 65002: We are establishing a BGP peering session with a neighbor at IP 192.168.1.2, which belongs to AS 65002.network 192.0.2.0/24: This is the IP address block (prefix) that AS 65001 is announcing. It’s saying, "Hey, if you want to reach anything in the 192.0.2.0/24 range, I know how to get there."neighbor ... route-map ...: These lines configure policies for incoming and outgoing routes, crucial for controlling what advertisements are accepted and sent.
When a network announces a prefix, it’s essentially saying, "I own these IP addresses, and here’s the best path to reach them." The problem is, BGP, by design, trusts these announcements. It doesn’t inherently verify if the announcer actually owns those IP addresses. This is where hijacking comes in.
How Attackers Reroute Internet Traffic
An attacker can exploit this trust by announcing a prefix they don’t own, but which belongs to a legitimate organization. They do this by advertising that prefix to their BGP neighbors. Because BGP routers choose the "best" path based on various metrics (like the number of hops, local preference, etc.), and often a shorter, more direct path is preferred, the attacker’s false announcement can be seen as a better route by other networks.
Once this false announcement propagates through the internet’s BGP routing tables, traffic destined for the hijacked IP addresses will start flowing towards the attacker’s network. The attacker can then:
- Eavesdrop: Inspect all the traffic that passes through their network. This is invaluable for stealing sensitive data like login credentials, financial information, or proprietary secrets.
- Modify: Alter the traffic in transit, injecting malicious content, redirecting users to fake websites (phishing), or even causing denial-of-service by dropping packets.
- Blackhole: Simply drop all the traffic, effectively making the targeted IP addresses unreachable for legitimate users. This is a common tactic for disruption.
Consider this scenario: A large company, "ExampleCorp," owns the IP address block 203.0.113.0/24. An attacker gains control of a small, poorly secured network (AS 65000) that has BGP peering with a major internet backbone provider (AS 65001). The attacker then makes a BGP announcement to AS 65001, saying:
AS 65000: I announce prefix 203.0.113.0/24 via path AS 65000.
If AS 65001 finds this path acceptable (perhaps it’s shorter or has higher local preference than ExampleCorp’s legitimate announcement), it will start directing traffic for 203.0.113.0/24 to AS 65000. Suddenly, all users trying to reach ExampleCorp’s servers will have their traffic routed through the attacker’s network.
The Technical Levers: AS Paths and Origin AS
The core of BGP routing is the AS Path attribute. When a network advertises a prefix, it prepends its AS number to the path. So, if AS 65001 announces 203.0.113.0/24, the AS Path might look like 65001. If AS 65001 learned this prefix from AS 65002, the path would be 65002 65001.
The Origin AS is the AS that originally announced the prefix. BGP routers use policies to decide which AS Path is best. Generally, a shorter AS Path is preferred.
In a hijacking scenario, the attacker creates a BGP announcement for a prefix they don’t own, but they list their AS as the Origin AS and prepend their AS number to the path. If this crafted path is considered better than the legitimate one, it gets accepted.
Preventing and Detecting BGP Hijacks
The primary defense against BGP hijacking is Resource Public Key Infrastructure (RPKI). RPKI is a framework that allows IP address holders to cryptographically sign their route origin authorizations (ROAs). These ROAs specify which AS numbers are authorized to originate advertisements for specific IP address blocks.
BGP routers can then use RPKI validation to check if an incoming BGP announcement is legitimate. If an announcement comes from an AS not authorized by the ROA for that prefix, the router can reject it.
Another crucial technique is prefix filtering. Network operators should:
- Ingress Filtering: Only accept BGP announcements from neighbors that are for prefixes they are supposed to receive (e.g., from customers, not from upstream providers if they are not customers). This prevents upstream providers from announcing prefixes they shouldn’t.
- Egress Filtering: Only send BGP announcements to neighbors that are for prefixes you legitimately own. This prevents a compromised router within your own network from announcing prefixes it shouldn’t.
The Counterintuitive Nuance: The "Path Leak"
Most people think of BGP hijacking as a malicious actor actively announcing someone else’s prefix. While that’s a major threat, a surprisingly common and damaging form of hijack is a "path leak." This happens not through malicious intent, but through misconfiguration. Imagine a large ISP with multiple peering points and transit providers. If they accidentally announce a customer’s prefix to one of their transit providers (when they should only be announcing it to peers or customers), that transit provider might see it as a shorter path to reach that customer’s network and start sending traffic destined for that customer through the misconfigured ISP. The ISP didn’t intend to hijack anything, but their misconfiguration caused traffic to be rerouted through them, potentially leading to eavesdropping or blackholing. This highlights how critical precise BGP policy and filtering are, even in the absence of outright malice.
The next challenge after securing your own routing is understanding how to effectively monitor the global routing table for anomalies.