Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Cloud

4/25/2019
02:30 PM
Marc Laliberte
Marc Laliberte
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

How a Nigerian ISP Accidentally Hijacked the Internet

For 74 minutes, traffic destined for Google and Cloudflare services was routed through Russia and into the largest system of censorship in the world, China's Great Firewall.

On November 12, 2018, a small ISP in Nigeria made a mistake while updating its network infrastructure that highlights a critical flaw in the fabric of the Internet. The mistake effectively brought down Google — one of the largest tech companies in the world — for 74 minutes.

To understand what happened, we need to cover the basics of how Internet routing works. When I type, for example, HypotheticalDomain.com into my browser and hit enter, my computer creates a web request and sends it to Hypothtetical.Domain.com servers. These servers likely reside in a different state or country than I do. Therefore, my Internet service provider (ISP) must determine how to route my web browser's request to the server across the Internet. To maintain their routing tables, ISPs and Internet backbone companies use a protocol called Border Gateway Protocol (BGP).

BGP is a dynamic routing protocol, meaning it automatically updates routing tables as changes occur. The Internet isn't a single straight line from one point to another. There are generally a few different paths a connection can take from point A to point B. BGP's job is to decide which path is the "best" path (shortest) to reach any given destination network, and update routers accordingly. This path can change as routers are taken down and brought back up online. BGP handles all of these route changes automatically.

The Internet is broken up into a number of autonomous systems (ASs), exactly 6,3954 at this time of writing. Each AS is assigned an autonomous system number (ASN) by the Internet Assigned Numbers Authority (IANA). Your ISP has at least one ASN, likely even more. Big companies like Google also maintain their own border routing infrastructure and have their own ASN.

Autonomous systems form connections with their neighbors, called peers. Through these peer connections, ASs advertise the routes — or "network prefixes," as they are called — that they know how to reach. Neighbors forward on these advertisements to their other neighbors to propagate them across the Internet backbone. Eventually, because of these route advertisements, an ISP in Seattle can learn a route all the way to a web server hosted in Sydney.

Ground Zero: Internet Exchange Point, Nigeria
So, what exactly happened on November 12? It all starts with an organization called the Internet Exchange Point of Nigeria (IXPN). Internet exchange points (IXPs) are common, especially in developing countries. They provide a central location for regional ISPs to peer with each other and share data at reduced bandwidth costs. Without IXPs, regional ISPs might not have a direct connection with each other. This means traffic between them may travel an overly long distance, possibly even leaving the country before coming back in.

IXPs also act as a single point of connection for larger remote companies and services. In the case of IXPN, Google maintains a peering connection with participating Nigerian ISPs, allowing direct connections from their networks to Google's services. To facilitate this, Google announces its network prefixes (routes) to its ISP peers in Nigeria. Think of it like building a highway straight to Google instead of having to take a winding country road up through Europe.

These peering agreements and route advertisements are generally for the benefit of the ISPs and their customers alone, so they use route filters to prevent accidently advertising the prefixes beyond their own networks. Without these route filters, the ISP routers, using BGP, would continue to propagate the routes to their other neighbors across the Internet and risk changing how global Internet traffic routes to Google.

Next Stop China
On November 12, 2018, at around 21:13 UTC, MainOne Cable Company in Nigeria was performing routine maintenance on its routing infrastructure. During this maintenance, it accidently misconfigured its route filters, causing it to announce 212 Google prefixes (and several Cloudflare prefixes) to its other BGP neighbors.

China Telecom, one of MainOne's BGP peers, accepted the route advertisement and relayed it to its neighbors. Transtelecom, based in Russia, accepted this advertisement and relayed it to its peers. At this point, the advertisement had made it far enough into the Internet that many ASs began accepting it.

For around 74 minutes, most traffic destined for Google and Cloudflare services from around the world was routed through Russia, into China, and on to MainOne in Nigeria. Cloudflare was quick to spot the issue and update its routing topography to mitigate the problem. Many users attempting to access Google services, however, had their connections crash right into the largest system of censorship in the world, China's Great Firewall. Everyone else suffered extreme latency as their connections were routed across the world to Nigeria before reaching Google.

Why is this a big deal? This accident highlights a critical vulnerability in the fabric of the Internet. BGP relies on the trust system. Peers trust that their neighbors are advertising accurate routes. If a neighbor starts advertising routes to prefixes it doesn't own, it could start intercepting and man-in-the-middling connections to any connection it wants. A single small ISP from Nigeria managed to disrupt traffic to the largest company on the Internet because of a simple mistake. Now imagine what a malicious, coordinated BGP hijack could accomplish.

The good news is that there is a fix out there. Resource Public Key Infrastructure (RPKI) uses cryptographic signatures to authenticate BGP route advertisements, similar to how websites use certificates. Route origin validation (ROV) confirms that prefix advertisements come from the actual owner. Unfortunately, only 13% of advertised prefixes use RPKI, and less than 1% of ASs validate route advertisements. If our Internet service providers and other participants on the Internet backbone don't start adopting these standards soon, the next BGP hijack might not be an accident — and will likely be much worse.

Related Content:

 

 

Join Dark Reading LIVE for two cybersecurity summits at Interop 2019. Learn from the industry's most knowledgeable IT security experts. Check out the Interop agenda here.

Marc Laliberte is a senior security analyst at WatchGuard Technologies. Specializing in networking security protocols and Internet of Things technologies, Marc's day-to-day responsibilities include researching and reporting on the latest information security threats and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
The Problem with Proprietary Testing: NSS Labs vs. CrowdStrike
Brian Monkman, Executive Director at NetSecOPEN,  7/19/2019
RDP Bug Takes New Approach to Host Compromise
Kelly Sheridan, Staff Editor, Dark Reading,  7/18/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-14248
PUBLISHED: 2019-07-24
In libnasm.a in Netwide Assembler (NASM) 2.14.xx, asm/pragma.c allows a NULL pointer dereference in process_pragma, search_pragma_list, and nasm_set_limit when "%pragma limit" is mishandled.
CVE-2019-14249
PUBLISHED: 2019-07-24
dwarf_elf_load_headers.c in libdwarf before 2019-07-05 allows attackers to cause a denial of service (division by zero) via an ELF file with a zero-size section group (SHT_GROUP), as demonstrated by dwarfdump.
CVE-2019-14250
PUBLISHED: 2019-07-24
An issue was discovered in GNU libiberty, as distributed in GNU Binutils 2.32. simple_object_elf_match in simple-object-elf.c does not check for a zero shstrndx value, leading to an integer overflow and resultant heap-based buffer overflow.
CVE-2019-14247
PUBLISHED: 2019-07-24
The scan() function in mad.c in mpg321 0.3.2 allows remote attackers to trigger an out-of-bounds write via a zero bitrate in an MP3 file.
CVE-2019-2873
PUBLISHED: 2019-07-23
Vulnerability in the Oracle VM VirtualBox component of Oracle Virtualization (subcomponent: Core). Supported versions that are affected are Prior to 5.2.32 and prior to 6.0.10. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox...