BGP leaks and cryptocurrencies

Over the few last hours, a dozen news stories have broken about how an attacker attempted (and perhaps managed) to steal cryptocurrencies using a BGP leak.

CC BY 2.0 image by elhombredenegro

The Internet is composed of routes. For our DNS resolver 1.1.1.1 , we tell the world that all the IPs in the range 1.1.1.0 to 1.1.1.255 can be accessed at any Cloudflare PoP.

For the people who do not have a direct link to our routers, they receive the route via transit providers, who will deliver packets to those addresses as they are connected to Cloudflare and the rest of the Internet.

This is the normal way the Internet operates.

There are authorities (Regional Internet Registries, or RIRs) in charge of distributing IP addresses in order to avoid people using the same address space. Those are IANA, RIPE, ARIN, LACNIC, APNIC and AFRINIC.

CC BY 2.0 image by Magnus D

The broad definition of a BGP leak would be IP space that is announced by somebody not allowed by the owner of the space. When a transit provider picks up Cloudflare's announcement of 1.1.1.0/24 and announces it to the Internet, we allow them to do so. They are also verifying using the RIR information that only Cloudflare can announce it to them.

Although it can get tricky checking all the announcements. Especially when there are 700,000+ routes on the Internet and chains of providers exchanging traffic between each other.

By their nature, route leaks are localized. The more locally connected you are, the smaller the risk of accepting a leaked route is.In order to be accepted over a legitimate route, the route has to be either:

• A smaller prefix (10.0.0.1/32 = 1 IP vs 10.0.0.0/24 = 256 IPs)

• Have better metrics than a prefix with the same length (shorter path)

The cause of a BGP leak is usually a configuration mistake: a router suddenly announces the IPs it learned. Or smaller prefixes used internally for traffic engineering suddenly becoming public.

But sometimes it is done with a malicious intent. The prefix can be re-routed through in order to passively analyze the data. Or somebody can also set-up a service to reply illegitimately instead. This has happened before.

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/24205.251.193.0/24205.251.195.0/24205.251.197.0/24205.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.

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.

Normal case

After a BGP route leak

As previously mentioned, AS10279 announced this route. But only some regions got affected. Hurricane Electric has a strong presence Australia, mostly due to Internet costs. Chicago was affected because AS10279 has a physical presence resulting in direct peering.

The following graph displays the number of packets received in the affected regions and unaffected regions (Y axis normalized). The drop is due to the authoritative server not responding to our requests anymore (it only responded for the one website and all other Amazon domains were ignored).

The others transits used by eNet (CenturyLink, Cogent and NTT) did not seem to have accepted this route: a reason could be that they have filters and/or Amazon as a customer.eNet provides IP services, so one of their clients could have been announcing it.

As there are many actors involved, it is hard to determine fault. Actors involved:

• 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.

Just like a blockchain, a network change is usually visible and archived. RIPE maintains a database for this use.

This is a difficult question to answer. There are proposals for securing BGP:Some terms can be added to the RIR databases, so a list of allowed sources can be generated:

$ whois -h whois.radb.net ' -M 205.251.192.0/21' | egrep '^route:|^origin:|source:' | paste - - - | sort
route:      205.251.192.0/23	origin:     AS16509	source:     RADB
route:      205.251.192.0/23	origin:     AS16509	source:     REACH

Setting up RPKI/ROA records with the RIR as a source of truth regarding to the path of a route, although not everyone create those records or validate them. IP and BGP were created a few decades ago, with different requirements in mind regarding integrity and authenticity (less routes).

A few things can be done on the upper levels of the network stack.

On DNS, 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 you use Cloudflare as a DNS, you can enable DNSSEC within a few clicks in the panel.

On HTTPS, your browser will check the TLS certificate provided by the website. 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.

DNS over HTTPS would also allow to validate you are talking to the correct resolver in case the leak would be on the DNS resolvers instead of the DNS authority.

There is no perfect and unique solution. The more of these protections are in place, the harder it will be for a malicious actor to perform this kind of attack.