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 SiddiquiSenior 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 articles

Mutually Agreed Norms for Routing Security (MANRS) 2 November 2023

Achieving Greater Heights for MANRS

Partnering with the Global Cyber Alliance (GCA), we believe that MANRS will continue to be further established as the...

Mutually Agreed Norms for Routing Security (MANRS) 12 April 2022

Routing Security Goes to Washington

A month ago, the United States Federal Communications Commission (FCC) published a “Notice of Inquiry” (NOI) around a subject...

Mutually Agreed Norms for Routing Security (MANRS) 15 February 2022

MANRS in 2021: A Year of Growth and Change

Here are some highlights in the MANRS Community Report 2021 and outline some of our plans for 2022.