We somehow got used to that cryptocurrencies live their own lives, and networks and network services their own. And certainly, cryptocurrency developers do not often need the
BGP protocol, which is used by Internet channel providers to exchange route information. Well, this did not prevent the attackers to use their ingenuity, knowledge of network technologies, and arrange an elegant robbery of trusting cryptocurrency owners Ethereum.

The essence of the attack is simple: using BGP, attackers were able to
redirect Amazon Route 53 traffic (this is a DNS service provided by Amazon) to their DNS server, which gave the IP address of the attacker to the MyEtherWallet.com website, which contains a slightly corrected clone original site. The original MyEtherWallet.com contains the Ethereum web wallet implementation for a cryptocurrency wallet, while a clone conducted a phishing attack, which resulted in the attackers stealing 215 ETH (~ 137 thousand dollars) in two hours.

')
The substitution of the fictitious route was
carried out on behalf of the large American Internet provider
eNet (
AS 10297 ), located in Columbus (Ohio, USA). After the BGP announcement, all the eNet peers, among which are the largest operators such as Level 3, Hurricane Electric, Cogent and NTT, began to wrap traffic sent to Amazon Route 53, according to the route set by the attackers. Because of the bogus announcement of BGP, requests for five Amazon-owned / 24-sized subnets (for a total of about 1300 IP addresses):
- 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
redirected to the attacker-controlled server located in the data center of the provider Equinix in Chicago, where the MiTM-attack was launched to substitute DNS responses. As a result, the usual DNS operation scheme, in which the request is sent to an authoritative server for a domain (on the slide below, server 205.251.195.x) continued to work as before, however, the attackers server began to appear at 205.251.195.x:


The situation is anecdotal, but for
almost two hours (from 11:05 to 12:55 UTC, April 24, 2018) no one noticed this substitution, and people used a replacement website, even (attention!) Despite the fact that A
self-signed HTTPS certificate was used (for which browsers issue a warning about problems with a secure connection). In case of accepting a certificate (!) And authentication on a phishing site, the user was
charged all funds from the wallet.
It is noteworthy that the attackers, apparently, are not poor people: on the ETH-wallet, to which transfers were redirected during the attack, currently there are 24,276 ETHs, which is more than 15 million US dollars.
While it is known for sure that during the attack, the DNS records were replaced for the site MyEtherWallet.com, but this does not mean that it is only with this site that everything is over. It seems logical to assume that getting access to the BGP router of a large ISP and the availability of resources to handle the huge DNS traffic indicates that the attack was not limited only to MyEtherWallet. This hypothesis is also supported by the uninterrupted flow of transfers to the ETH wallet used in the attack. According to other assumptions, there was only a test experiment before conducting more massive attacks.
The question with the certificate, I must say, is quite thin. The attackers could easily get a certificate from Let's Encrypt, since DV-checking was quite capable of them, unless it made you spend some time on it - or, which is likely (thanks to
Ghost_nsk for the clarification), the LE server is far enough in the network sense from the attackers , so that the announcements do not reach them, and LE did not “see” the malicious DNS.
Obviously, the idea of using more secure protocols and technologies for working with DNS, such as DNS over HTTPS (DoH), or DNS over TLS (both offered by CloudFlare in its
DNS service 1.1.1.1 ) seems to be all more reasonable, despite the associated overhead.