BGP hijack steals AWS IP range; cryptocurrency theft ensues

Earlier this week, a “threat actor” hijacked the DNS traffic for Amazon Web Services. Welp.

Route 53, the AWS DNS service, lost its routes from large swathes of the Internet. Instead, requests were redirected to persons unknown. This caused traffic to a major cryptocurrency wallet to go to a fake site, leading to theft of Ethereum.

What can we learn from this unfortunate event? In this week’s Security Blogwatch, we ponder BGP and DNSSEC.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: BLR Zucc 

State of Security Operations 2018: Go Inside World SOCs

AWS DNS pwned via BGP FAIL: ETH MIA

What’s the craic? Shaun Nichols recounts the Audacious BGP seizure of Route 53 IP addys:

Crooks … hijacked internet connections to Amazon Web Services systems to ultimately steal a chunk of alt-coins from … MyEtherWallet.com. [They] redirected DNS lookups … to a malicious website masquerading as the real thing.

Crucially, this DNS hijacking was possible after miscreants pulled off a classic BGP hijacking attack. … Someone was able to send BGP – Border Gateway Protocol – messages to the internet's core routers to convince them to send traffic destined for some of AWS's servers to a renegade box, [which] gave out the wrong IP addresses for MyEtherWallet.com.

BGP is the glue of the internet. … The routing equipment at the core of the internet exchanges BGP messages to maintain their tables of active routes. … BGP hijacking is, sadly, decades old, and has proven a reliable technique for criminals and other scumbags.

The hijack underscores the need to address fundamental vulnerabilities in BGP.

And Dan Goodin has these goods[You’re fired—Ed.]

Amazon lost control of a small number of its cloud services IP addresses for two hours on Tuesday. … In a statement, Amazon officials wrote: "Neither AWS nor Amazon Route 53 were hacked or compromised. An upstream Internet Service Provider (ISP) was compromised."

Despite its crucial function … BGP still largely relies on the Internet-equivalent of word of mouth from participants who are presumed to be trustworthy. Organizations such as Amazon whose traffic is hijacked currently have no effective technical means to prevent such attacks.

The attackers managed to steal about $150,000 of currency from MyEtherWallet users. [But] the attacker wallet already contained about $17 million … an indication the people responsible for the attack had significant resources. [It] is leading to speculation that MyEtherWallet wasn't the only target. … Another theory is that [this was a] test run.

Interesting theory, if utterly frightening. Kevin @gossithedog Beaumont adds more scary detail:

An unknown actor … re-routed DNS traffic using a man in the middle attack using a server at Equinix in Chicago. … This would allow them to intercept traffic globally across the internet to Amazon Route 53 customers.

Mounting an attack of this scale requires access to BGP routers at major ISPs and real computing resource to deal with so much DNS traffic. It seems unlikely MyEtherWallet.com was the only target. … The security vulnerabilities in BGP and DNS are well known [but] this is the largest scale attack I have seen … it underscores the fragility of internet security.

Wait. Pause. I've heard before about Equinix's Chicago facility. aaronb1138 rings a bell:

People should be much more concerned an Equinix Chicago site was believed to be the MITM location. Equinix's main location in Chicago (350 E. Cermak) is the termination point for a dedicated / dark fiber run which goes straight to the New York Stock Exchange to reduce latency to / from the Chicago Mercantile Exchange.

Tons of companies have cages at that facility for doing algo-trading as well as human run trading. Every entry way has security halls 10 or so feet long. … Full hand print scans + badge + pin to get inside.

So BGP is badly broken? Well, yes and no, says I4ko:

It has security. The edge providers have responsibility to not accept announces from customers for IP subtest that do not belong to them. It seems like the guys in Ohio screwed up and allowed receiving and redistributing any announce whatsoever. This is not backbone. Edges should use BGP filters from customers.

But who knows what the left hand is doing elsewhere? Voland's right hand has a go:

It goes to prove a perennial point - something those of us involved in various aspects of Internet architecture and peerings have been saying since the late 90s. The current private peering system in the USA is criminal in its insecurity. There are no ACLs on the route announcements and if you are big enough to peer in the first place, you can announce any **** you like. That is very difficult to pull in Europe … you have to hack the RIPE routing registry first, pass all of its safeguards and leave a trail of evidence mile long and half a mile wide.

The issue was further exasperated by the route53 architecture. It does not use traditional large scale Service Provider DNS resilience methods such as anycast so hacking the routing for one region is generally enough to take out any DNS services [in] that region.

With which jennystonermeyer agrees:

There are tools to mitigate and check for this, interesting that AWS doesn't use them and/or didn't detect.

But how did the attackers get an EV cert for their fake site? Um, they didn’t, according to Zuizzi:

There was a warning about security certificate for anyone that went to the site. … People that ignore it (literally click ignore when it pops up) deserve to have their funds taken. This is money we're talking about, if that's what it takes for them to learn let it be.

Harsh. But who else is to blame? Louis Poinsignon has a go:

  • The ISP that announced a subnet it did not own.
  • The transit providers that did not check the announcement before relaying it.
  • The ISPs that accepted the route. The lack of protection on the DNS resolvers and authority.
  • The phishing website hosted on providers in Russia.
  • The website that did not enforce legitimate TLS certificates.
  • The user that clicked continue even though the TLS certificate was invalid. …
You can use DNSSEC to sign your records. The IPs returned by the fake DNS would not have been signed as they do not have the private keys.

If HSTS is enabled, the browser will require a valid certificate all the time. The only way to generate a legitimate TLS certificate for a domain would be to poison the cache of a non-DNSSEC DNS resolver of the Certificate Authority.

DANE provides a way of pinning certificates to a domain name using DNS.

And boudin elaborates:

With DNSSEC, the public key is not hosted on the zone itself, where your zone delegation is hosted. It's the DS records.

in this scenario they only hijacked the dns traffic and were using it to resolve a domain to another IP, so they were changing the DNS zone. DNSSEC would have prevented this as the change they did in the zone needs to be signed, so it would require them to also get the private key used to sign the zone.

If they managed to hijack the route to the server itself, there's no need to hijack DNS at all, so it's a different issue that can't be solved at DNS level.

Meanwhile, Francisco @Francisckrs Donoso frightens us even more:

High potential that this was a distraction for other activity that required the BGP hijack.

If I was a Route53 customer - I'd be looking at historical DNS data and certificate transparency logs to make sure I wasn’t affected.

This was a lot of effort / planning from the attackers and I don’t think only one site was affected.


The moral of the story? Is your service safe from a BGP hijack? Does your cloud provider proactively monitor its routes? Does your CA use DNSSEC? Do you use HSTS and DANE?

And finally …

The anonymous BLR guy actually managed to make Zucc’s testimony even more awkward


You have been reading Security Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or sbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE.

Image source: David McBee (cc0)

Topics: Security