MyEtherWallet DNS Attack Offers Opt-In Lessons
Attackers poisoned BGP route tables to redirect Amazon's Route 53 name servers to their malicious servers.
April 26, 2018
Combine exploits of two of the Internet's foundation protocols with a human behavior "vulnerability" and you get an attack that can be quite successful: That's what happened on Amazon's domain name service on April 24, and the result is a $150,000 lesson in stacked vulnerabilities.
The attack was first spotted around 8 a.m. Central Daylight Time on Tuesday, when bogus routes began getting published by a small number of networks taking their cue from Route53, the domain name system for Amazon. The bogus routes sent traffic to fake name servers, which then directed those looking for MyEtherWallet.com to a server in Russia, where some users blew through warnings to answer questions from a phishing app and give up their cryptocurrency credentials. Those users lost the contents of their cryptowallets.
The Border Gateway Protocol (BGP) was the foundation of the attack. Misdirection then moved to DNS, sending some users to a server that didn't have the proper certificate for an HTTPS connection. Looking at the exploit as it moved up the stack can help us understand why three well-known and technologically unsophisticated exploits combined for success in this attack.
Own the Route
BGP is the protocol that tells routers the best way to send traffic along the multi-hop path that makes up each internet session. These instructions come from complex algorithms, constant monitoring, and, in many cases, skilled professional "router jockeys" who know their router performance and what's going on in their network neighborhood. The entire process relies on trust at each level and step.
With all the trust, there's a bias built into the system: The more specific a route, the better. The attackers in this case saw routes to some of the Amazon Route53 name servers that were advertised as /23 and substituted /24 routes.
"The bad guys strategically poisoned the BGP route tables to redirect the Route 53 name servers to their servers. They had to cherry-pick two or three /24s that just happened to be the ones for [MyEtherWallet.com]," says Cricket Liu, chief DNS architect at Infoblox. The choice of name servers to target didn't require deep inside information, either. "The information is publicly available; just look up the DNS records for them, and you know which address spaces you need to commandeer," he says.
The attack began with the /24 routes advertised by a server at eNET Inc., an ISP in Columbus, Ohio. eNet servers forwarded them to other BGP servers, as they are supposed to do. eNET hosts in an Equinix facility in Columbus, which has a direct link to the substantial Equinix facility in Chicago. This made propagation of the links somewhat faster, though, as Liu says, "This could have been done anywhere. Any authoritative servers could have done it."
While the spurious routes were advertised, not all routers accepted the new routes. "Most ISPs will actively filter the prefixes from other providers," says Alex Henthorn-Iwane, vice president of product marketing at ThousandEyes. The weakness in the system, he says, is that the filtering is part of good BGP hygiene and is voluntary. As a result, "Most of the providers rejected [the new routes], but a couple didn't, and those two propagated them out to the rest of the internet. That means it wasn't as widespread as it might be, but it did hit some people."
According to AWS, neither AWS nor Amazon Route 53 were compromised in the attack. "An upstream Internet Service Provider (ISP) was compromised by a malicious actor who then used that provider to announce a subset of Route 53 IP addresses to other networks with whom this ISP was peered. These peered networks, unaware of this issue, accepted these announcements and incorrectly directed a small percentage of traffic for a single customer’s domain to the malicious copy of that domain," the company said in a statement.
Own the Name
The malicious route didn't go to a fake version of MyEtherWallet. Instead, it directed queries to a malicious DNS server. "It is rare to see the DNS on top of the BGP attack," says Patrick Sullivan, senior director of security strategy at Akamai. "Someone exploited the lack of integrity checking with BGP route advertising and the lack of integrity for DNS responses."
Once individuals trying to reach MyEtherWallet were given the malicious route, the next level of the exploit became easier. "The authoritative servers looked like they had legitimate addresses, but because of BGP they went to spurious authoritative servers that then served bad resolution," says Merike Käo, CTO at Farsight Security.
Part of the unusual nature of this attack is that the threat actors were phishing rather than trying to capture traffic. "The fear is a man in the middle attack where they try to decrypt HTTPS traffic offline after they capture it," says Sullivan.
Instead of being stealthy about information capture, the attackers required users to type it in — and ignore warnings to do it.
Own the User
While the focus has been on the BGP and DNS elements of this attack, neither would have been effective without cooperation from the users. "This was poor end-user security hygiene where users saw some pretty dire warnings and they just clicked straight through," Sullivan says. "They saw that it was not a CA-approved cert and blew through the warnings."
Aside from more training, it's unclear how else to prevent users from falling for this. "Because it's human, it's vulnerable. Humans can opt in or opt out of practices," says Henthorn-Iwane. "The human factor, on balance, is always going to be a security vulnerability."
And that makes the final point of the nature of this attack. "I would call it the criminal underground taking advantage of basic Internet hygiene," says Käo.
Routes Forward
There are technologies and standards of practice that prevent a layered attack like this one:
DNSSEC — DNS Security Extensions (DNSSEC) is a basic step that many more organizations should be implementing, experts say. DNSSEC provides for a chain of certificates attesting to the validity of an address. "DNSSEC isn't enormously difficult or expensive. In the early days it was, but that was 20 years ago," says Liu.
MANRS — Mutually Agreed Norms for Routing Security (MANRS) are principles for making sure that malicious and spurious routes are not propagated through the Internet. The basics are clear policies and active filtering for routes and addresses that come from questionable sources.
BCP38 — Originally intended to provide protection from DDoS attacks, BCP38 is an implementation of RFC2827 Network Ingress Filtering. It provides for standard ways of filtering packets with spoofed IP addresses. As it turns out, it would also significantly hinder BGP takeovers that propagate spurious routes and addresses.
RPKI — Resource Public Key Infrastructure (RPKI) is a way for resource owners to specify which autonomous systems can originate IP address prefixes. In the context of this attack, RPKI would have prevented the first step from occurring.
The primary limitation of all four of these is that they require website, DNS server, or router owners to opt in to the protection. Any owners who choose to opt out present realistic attack surfaces for criminals.
Meantime, even if your organization isn't targeted, it can be affected by this type of attack. "When you're running a digital business it's not just about being hit directly, it's about being hit when someone else is targeted," says Henthorn-Iwane. "You don't have to be targeted to be damaged."
"It is my hope that events like this will further raise the awareness to follow best practice mandates," says Käo. "Even if you're helping protect someone else, some day it will come back and help protect you."
Related Content:
Join Dark Reading LIVE for a two-day Cybersecurity Crash Course at Interop ITX. Learn from the industry’s most knowledgeable IT security experts. Check out the agenda here. Register with Promo Code DR200 and save $200.
About the Author
You May Also Like
Cybersecurity Day: How to Automate Security Analytics with AI and ML
Dec 17, 2024The Dirt on ROT Data
Dec 18, 2024