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.


MyEtherWallet DNS Attack Offers Opt-In Lessons

Attackers poisoned BGP route tables to redirect Amazon's Route 53 name servers to their malicious servers.

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.
  • MANRSMutually 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.
  • RPKIResource 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:

Interop ITX 2018

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.

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/13/2020
Where Are the 'Great Exits' in the Data Security Market?
Dave Cole, Cofounder and CEO, Open Raven,  10/13/2020
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-10-19
A prototype pollution vulnerability has been found in `object-path` <= 0.11.4 affecting the `set()` method. The vulnerability is limited to the `includeInheritedProps` mode (if version >= 0.11.0 is used), which has to be explicitly enabled by creating a new instance of `object-path` and settin...
PUBLISHED: 2020-10-19
On Windows the Veyon Service before version 4.4.2 contains an unquoted service path vulnerability, allowing locally authenticated users with administrative privileges to run malicious executables with LocalSystem privileges. Since Veyon users (both students and teachers) usually don't have administr...
PUBLISHED: 2020-10-19
An exploitable denial of service vulnerability exists in the ENIP Request Path Logical Segment functionality of Allen-Bradley Flex IO 1794-AENT/B 4.003. A specially crafted network request can cause a loss of communications with the device resulting in denial-of-service. An attacker can send a malic...
PUBLISHED: 2020-10-19
An exploitable denial of service vulnerability exists in the ENIP Request Path Logical Segment functionality of Allen-Bradley Flex IO 1794-AENT/B 4.003. A specially crafted network request can cause a loss of communications with the device resulting in denial-of-service. An attacker can send a malic...
PUBLISHED: 2020-10-19
A flaw was found in Infinispan version 10, where it permits local access to controls via both REST and HotRod APIs. This flaw allows a user authenticated to the local machine to perform all operations on the caches, including the creation, update, deletion, and shutdown of the entire server.