Cloudflare maintains a range of BGP collectors gathering BGP information from hundreds of routers around the planet.
Between approximately 11:05:00 UTC and 12:55:00 UTC today we saw the following announcements:
BGP4MP|04/24/18 11:05:42|A|205.251.199.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.197.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.195.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.193.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.192.0/24|10297
...
BGP4MP|04/24/18 11:05:54|A|205.251.197.0/24|4826,6939,10297
Those are more specifics announcements of the ranges:
205.251.192.0/23
205.251.194.0/23
205.251.196.0/23
205.251.198.0/23
This 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.
BGP hijack this morning affected Amazon DNS. eNet (AS10297) of Columbus, OH announced the following more-specifics of Amazon routes from 11:05 to 13:03 UTC today:
205.251.192.0/24
205.251.193.0/24
205.251.195.0/24
205.251.197.0/24
205.251.199.0/24
— InternetIntelligence (@InternetIntel) April 24, 2018
Correction: the BGP hijack this morning was against AWS DNS not Google DNS. https://t.co/gp3VLbImpX
— InternetIntelligence (@InternetIntel) April 24, 2018
For instance, the following query will return you legitimate Amazon IPs:
$ dig +short myetherwallet.com @205.251.195.239
54.192.146.xx
But during the hijack, it returned IPs associated with a Russian provider (AS48693 and AS41995). You did not need to accept the hijacked route to be victim of the attack, just use a DNS resolver that had been poisoned.
Example of what the page would look like with a bad certificate
If you were using HTTPS, the fake website would display a TLS certificate signed by an unknown authority (the domain listed in the certificate was correct but it was self-signed). The only way for this attack to work would be to continue and accept the wrong certificate. From that point on, everything you send would be encrypted but the attacker had the keys.
If you were already logged-in, your browser will send the login information in the cookie. Otherwise, your username and password would be sent if you typed them in on a login page.
Once the attacker got the login information, it used them on the legitimate website to transfer and steal Ethereum.
AFTER THE HACK
