The myetherwallet.com hijack and why it’s risky to hold cryptocurrency in a webapp
Yesterday, several sources reported that “hackers” have targeted the myetherwallet.com cryptocurrency wallet.
But what really happened here? In fact, myetherwallet’s servers were never breached. What really happened is that attackers manipulated not one, but three, of the Internet’s core protocols — BGP routing, DNS, and TLS (aka HTTPS) — to redirect myetherwallet users to a bogus server that impersonated the legitimate myetherwallet site, which then stole user’s credentials and cryptocurrency.
I’ve studied the security of the Internet’s core protocols since 2005, and this is one of the most brazen attacks I’ve ever seen. In this blog post, I’ll summarize material appearing in other blogs and articles and highlight two lessons that I think we can learn from this incident.
Lesson 1: Attackers are becoming more sophisticated.
Back in the day, it was rare for a single security incident to involve the manipulation of multiple Internet protocols. But the myetherwallet incident required the attacker to manipulate several different protocols, pivoting from one to the next in each step of the attack. To me, this serves as counterpoint to an argument I’ve heard (and even made) several times: namely, that an exploit is not “interesting” or “practical” if it requires the manipulation of multiple protocols. (Today, certain attacks start to feel less “far fetched”.)
To understand the complexity of this attack, let’s walk through it step by step. The myetherwallet attacker had to:
(1) Control a BGP-speaking infrastructure router. (These are large infrastructure routers that enable network to network connectivity, not a dinky Linksys home router. It’s usually hard for your average Joe to gain access to these, although we do know that router hacking is a favorite activity of intelligence agencies and possibly also criminals.)
(2) Use that router to launch a subprefix hijack to manipulate BGP, the Internet’s routing protocol.
(3) Use this subprefix hijack to reroute traffic destined for a DNS server that serves the entire Amazon Route53 cloud service to an attacker-controlled bogus DNS server. (Per Cloudflare, this Route53 DNS server did not use DNSSEC; more on this in my next blog post.)
This step, in my opinion, is the craziest part of the attack. It means that all the websites and services using Amazon Route53 had their DNS traffic redirected to the attacker’s bogus DNS server. Not just myetherwallet.com. So many other sites were likely affected by this part of the attack, as collateral damage.
(4) Use the attacker-controller DNS server to redirect clients looking for the myetherwallet.com webserver to an attacker-controlled bogus webserver.
(5) Use an attacker-controlled bogus webserver to serve the user a bogus version of the myetherwallet.com website. This bogus website then phished for that user’s credentials.
The site had an invalid TLS certificate. (Thus, users might have seen a warning, and definitely did not see a green lock on the top left corner of their screen.) Nevertheless, some users did fall for this because the bogus webserver had the correct domain name (myetherwallet.com). (The attacker made sure the domain name was correct through its actions in step (4).)
In summary: crazy. Lots of protocol manipulations working in concert.
Lesson 2: It’s risky to store cryptocurrency in a webapp.
The Internet is insecure. See above.
This why storing cryptocurrency in a webapp (i.e. uploading secret keys and credentials to the a webserver) can be risky. It’s because those credentials need to travel over the public Internet.
It’s important to remember that myetherwallet did use TLS to encrypt any credentials that were sent by users to the myetherwallet webserver. Nevertheless, the attacker still managed to obtain those credentials via manipulation of other protocols (BGP, DNS) and via TLS usability failures. (Note: there are ways to work around TLS usability failures, like HSTS, but it looks like myetherwallet did not use them. More on this in another next post.)
So webapps can be risky.
We’re building a desktop app instead.
This is one reason why Commonwealth Crypto is building a user-facing desktop app, rather than a webapp.
Our desktop app allows users to trade on their favorite exchange. It will also support the secure non-custodial trading protocol that we are currently developing. That’s all I’ll say about this for now, except that our app will be entering closed beta testing shortly. If you’d like to become a beta tester, please let us know!
More soon!
I’m planning to write two other posts as follow ups to this one.
One post will describe how different Internet security solutions could have prevented (or failed to prevent) the myetherwallet attack.
The other post will describe how to build desktop apps that limit the risk of network protocol attacks.
Stay tuned. Now back to building.
