APNIC Labs/CloudFlare DNS 1.1.1.1 Outage: Hijack or Mistake? Thumbnail
Mutually Agreed Norms for Routing Security (MANRS) 31 May 2018

APNIC Labs/CloudFlare DNS 1.1.1.1 Outage: Hijack or Mistake?

By Aftab SiddiquiFormer Senior Manager, Internet Technology - Asia-Pacific

At 29-05-2018 08:09:45 UTC, BGPMon (A very well known BGP monitoring system to detect prefix hijacks, route leaks and instability) detected a possible BGP hijack of 1.1.1.0/24 prefix. Cloudflare Inc has been announcing this prefix from AS 13335 since 1st April 2018 after signing an initial 5-year research agreement with APNIC Research and Development (Labs) to offer DNS services.

Shanghai Anchang Network Security Technology Co., Ltd. (AS58879) started announcing 1.1.1.0/24 at 08:09:45 UTC, which is normally announced by Cloudflare (AS13335). The possible hijack lasted only for less than 2min. The last announcement of 1.1.1.0/24 was made at 08:10:27 UTC. The BGPlay screenshot of 1.1.1.0/24 is given below:

Anchang Network (AS58879) peers with China Telecom (AS4809), PCCW Global (AS3491), Cogent Communications (AS174), NTT America, Inc. (AS2914), LG DACOM Corporation (AS3786), KINX (AS9286) and Hurricane Electric LLC (AS6939). Unfortunately, Hurricane Electric (AS6939) allowed the announcement of 1.1.1.0/24 originating from Anchang Network (AS58879). Apparently, all other peers blocked this announcement. NTT (AS2914) and Cogent (AS174) are also MANRS Participants and actively filter prefixes.

Dan Goodin (Security Editor at Ars Technica, who extensively covers malware, computer espionage, botnets, and hardware hacking) reached out to Cloudflare about this possible hijack and received following statement from Cloudflare PR stating that they are ruling out any malicious intent and there was no drop in customer traffic and it was fixed quickly, but also blamed Hurricane Electric (AS6939) for the leaked route.

Considering this just a configuration mistake which was rectified quickly and didn’t cause any reported damage but it doesn’t solve the problem and there is a possibility that someone with a bad intent can do a lot of harm like the way it was done during Amazon Route 53 hijack, unless we take appropriate steps towards a secure and resilient internet.

Once again, this attack would have been easily avoided if proper prefix filtering was done by Hurricane Electric. As discussed in the previous blog, MANRS can be part of the solution here. Mutually Agreed Norms for Routing Security (MANRS) calls for four simple, but concrete actions ALL network operators should take to reduce the most common routing threats. The first is filtering, which prevents the propagation of incorrect routing information (others are anti-spoofing, address validation, and global coordination.).

So, what are you waiting for? Be part of the solution and help protect the core. Join MANRS.

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related Posts

Strengthening the Internet 6 September 2024

US Government Networks Get a Security Boost: White House Roadmap Tackles Routing Vulnerabilities

The White House's Roadmap to Enhancing Routing Security is an important step toward strengthening routing security in the United...

Strengthening the Internet 14 May 2024

The US Makes a Big Step Toward Better Routing Security

The US Department of Commerce began implementing better routing security practices—a step in the right direction for wider MANRS...

Securing Border Gateway Protocol (BGP) 18 April 2024

The US FCC Signals a Dangerous New Course on BGP Security

The US Federal Communications Commission recently released a draft Declaratory Ruling and Order in the Open Internet Proceeding. However,...