Introduction
This is the first part of a multi-part series detailing how netblocks are hijacked, the ramifications of such an event, how a netblock hijacking event can be mitigated or eliminated, and finally how Farsight’s DNSDB and other products can be part of the solution.
What is IP hijacking?
In the broadest sense of the term, it is the misplacement of routes. For the purpose of this series, we’ll define it as “the deliberate and malicious modification of public routing tables”.¹
There are multiple categories of route misplacement; briefly running through them will help illustrate why we’re focusing on what is the worst of the lot.
Intra-organization Hijack
This type is often a non-malicious systemic failure of one sort or another.
It could be a misbehaving protocol, human error, or legacy cruft that
hasn’t caused enough of a problem yet to be rectified. In any event, it is
restricted to an entity that can choose when and how it handles the
failure. Nobody on the public Internet should be affected. This type of
failure is more common in large organizations with many different
logistical domains, each with their own
IPAM and internal
processes. This environment is rife with fragmentation of IP space, both
public and RFC1918. A subset of
intra-organization hijack involves using non-RFC1918 IP space for an
internal network. This creates reachability issues from within the
organization to the correct place for those IPs. A common mistake is using
space within the 192.0.0.0/8 range that doesn’t include 192.168.0.0/16.
Public BGP Table Hijack
Here we span two variations: one where the IP space is hijacked, and another where the ASN and the IP space is hijacked. The former is more common and both can be either accidental as well as malicious. The latter is insidious, mostly because it can look like normal anycast to the rest of the Internet.
In-Path ASN Hijack
It is also possible for an attacker to insert a target ASN in announcements they make to the global routing table thereby causing some portion of traffic destined to the target to instead be routed through the attacker’s network. This presents a man-in-middle attack.
Public BGP Table Hijack (via Routing Registry)
This is the complete hijack scenario. For example, a network administrator went through the trouble to integrate their IRR objects correctly with a registry, but for some reason they find they are no longer in control of the maintainer object. Current recourse for recovery in this scenario is contacting the routing registry and regaining control of the maintainer object.
Censorship Hijack
Less common is the use of a network hijack for censorship, either at the behest of an individual, group, or sovereign nation. This type of hijack differs from the above because its main aim is to disable, restrict or deny access to specific sources or destinations on the internet.
Specific Effects and a Few Case Studies
The main effect of an IP hijack is denial of service. The problem with an IP hijack’s DoS footprint is that it creates a split horizon in the global routing table. An organization may be announcing the correct block, receiving most traffic destined for that block, and able to reach everything on the Internet. However, other places on the Internet may see the hijack BGP announcement as a more preferred route, and in the case of a non-malicious hijack, be unable to reach your organization. However, if the hijack is malicious, the hijacker may have created a duplication or man-in-the-middle attack devised to exfiltrate data from an organization. Another possible attack vector is a reflection attack against the hijackee. The attacker can issue TCP SYN queries around the Internet and across the split horizon and have the SYN/ACKs reflected at the legitimate organization. If the hijacked block is not black- or grey-listed, or worse, white-listed, a large volume of unwanted traffic may result.
Case Studies
As the Internet has matured, so too has the approach to routing. Specific failures have necessitated the creation of new methods for determining trust in routing relationships. Much like other areas of technology, these solutions often end up shoe-horned and inadequate, with holistic change a coveted but unrealized ideal. The introduction of RADb and expansion of IRRs in general was meant to lessen the impact of routing failures. Since it is opt-in, only used for verification of, and parallel to the actual Internet routing table, any network provider that does not require it of their downstream networks breaks the chain of trust. It is also the downstream networks’ prerogative to trust upstream announcements and filter their inbound routes as needed.
In the next article we’ll discuss the eventual and slowly deploying solution of RPKI, an analogue for global routing trust what DNSSEC is for namespace trust.
The easiest target for a netblock hijack is one that the Internet has forgotten. If nobody is in the forest, nobody can hear the tree fall, but it will certainly make a sound. An example of this is snowshoe spammers. The main tactic is to identify and hijack unused netblocks from large organizations with more specific network announcements. Their intent is to use the IP space temporarily, on the order of hours, send as much spam as possible before they are identified by the anti-spam community, then switch to the next block, and so on. The burden of mitigation remains on the targeted third parties, since the organization whose address space is being misused probably doesn’t know about it.
The largest group of netblocks that may be subject to successful hijack are part of small to mid-size organizations that have limited resources to identify and mitigate the threat. They are farther down in the routing food chain and may have to work through a few layers of their providers’ tech support. The support groups may be unequipped to understand, much less rectify, a hijack of their customer’s IP space. This assumes that the organization has a large enough footprint on the Internet to notice a split horizon without specifically monitoring for it.
A much murkier type of hijack involves sovereign or state-sponsored hijacks. With this type of hijack, there are two possibilities, the more common of which results in censorship of in-border access to the external Internet. This isn’t just a simple firewall at a country’s digital borders, but a complete redirection of traffic to provide monitoring, interdiction and other capabilities for authorities in that jurisdiction. The less common hijack involves accidental or malicious announcement of IP blocks to the Internet. An example of accidental hijack is the Pakistan Government’s hijack of Youtube.
Conclusion
In this first article of the series, you learned what hijacking is, how it can happen, and some of the more common symptoms and effects. In subsequent articles in coming weeks, we will delve into specific ways to identify and mitigate IP hijacks.
Endnotes
¹ There is a broader definition of IP hijacking here.
Dave Hauser is a Senior Network Engineer and Ben April is the Director of Engineering for Farsight Security, Inc.
Read the next part in this series: IP Hijacking, part 2
