Another BGP hijacking event is in the news today. This time, the event is affecting the Ethereum cryptocurrency. (Read more about it here, or here.) Users were faced with an insecure SSL certificate. Clicking through that, like so many users do without reading, they were redirected to a server in Russia, which proceeded to empty the user’s wallet. DNSSEC is important to us, so please check out the Deploy360 DNSSEC resources to make sure your domain names are protected. In this post, though, we’ll focus on the BGP hijacking part of this attack.
What happened?
First, here’s a rundown of routing attacks on cryptocurrency in general – https://btc-hijack.ethz.ch/.
In this case specifically, the culprit re-routed DNS traffic using a man in the middle attack using a server at an Equinix data center in Chicago. Cloudflare has put up a blog post that explains the technical details. From that post:
“This [hijacked] IP space is allocated to Amazon(AS16509). But the ASN that announced it was eNet Inc(AS10297) to their peers and forwarded to Hurricane Electric(AS6939).
“Those IPs are for Route53 Amazon DNS servers. When you query for one of their client zones, those servers will reply.
“During the two hours leak the servers on the IP range only responded to queries for myetherwallet.com. As some people noticed SERVFAIL.
“Any DNS resolver that was asked for names handled by Route53 would ask the authoritative servers that had been taken over via the BGP leak. This poisoned DNS resolvers whose routers had accepted the route.
“This included Cloudflare DNS resolver 1.1.1.1. We were affected in Chicago, Sydney, Melbourne, Perth, Brisbane, Cebu, Bangkok, Auckland, Muscat, Djibouti and Manilla. In the rest of the world, 1.1.1.1 worked normally.”
What does this have to do with MANRS and routing security?
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. (The others are anti-spoofing, address validation, and global coordination.) If all the operators along the path had implemented the MANRS actions – especially filtering – this would not have propagated across the Internet like it did.
For example, eNET also peers with Level3 (AS3356) and NTT (AS2914), but those operators didn’t forward the wrong information because they are MANRS compliant. (Other MANRS participants are listed here.)
Security Boulevard has also published a short recap of this BGP hijack event and called out MANRS as a potential solution.
What are you waiting for?
This can still happen at any time. Network operators have a responsibility to ensure a globally robust and secure routing infrastructure. Your network’s safety depends on a routing infrastructure that weeds out bad actors and accidental misconfigurations that wreak havoc on the Internet. The more network operators work together, the fewer incidents there will be, and the less damage they can do.
Learn more about MANRS here. Implement the four actions for network operators and join the communityof security-minded operators working together to make the Internet safer for everyone.
Leave a Reply