Cryptoheist!

The Heist

On Tuesday, a criminal gang advertised BGP routes for the DNS servers of "MyEtherWallet", a public Cryptocurrency wallet provider, redirecting traffic across the Internet and allowing them to respond to web requests for the service.

Users clicked through certificate warnings, and gave the criminals access to their wallets, losing their money.

Being a blockchain cryptocurrency, the transfers have been logged to an existing identity which has some $17.4 million dollars assigned to it. It turns out that crime actually does pay.

How bad is this?

The site already used HTTPS, and users were voluntarily ignoring certificate warnings. But it's important to note that the criminals demonstrated they could act with impunity at the IP routing layer of the Internet - such low-level control of traffic means that many basic security measures might not have worked.

Others, though, might have - so if you're operating a high-security service, what can you do to prevent this kind of attack?

BGP Hijacking

The Border Gateway Protocol is the protocol (and system) used to route traffic between ISPs. Each ISP routes traffic internally however they want, but on the edges of their network they exchange information about what traffic they can handle.

In some cases, that's traffic destined to networks they operate, and in others it's traffic destined to networks they connect to, and are willing to provide transit for. In either case, they advertise routes (and the Autonomous System Path they'll use).

In a BGP Hijack, an attacker advertises routes they don't really have, and then intercepts the traffic. The traffic is still going to the same IP address, and because the attacker now controls that address, they can act in every way as the IP address - responding to traffic at that level.

This means that traditional IP spoofing defences no longer work.

An endpoint cannot detect this kind of attack easily - you have to rely on higher-level protection.

In this particular case, the attacker hijacked the DNS service for MyEtherWallet, and so could provide bogus responses - but they could have hijacked the service itself, and had users connect to the same IP address.

So how can you protect your service? Strap on your security snorkel, and let's take a deep dive into some alphabet soup.

HTTPS

Putting in a proper, legitimate, certificate is your first step. In this case, this was done.

Really, users should never be clicking through security warnings, yet they clearly were in this case.

HSTS

HTTP Strict Transport Security allows a website operator to indicate that the website will use a valid certificate for a period of time - usually very long.

Had MyEtherWallet used this single header line, this particular attack would have been stopped dead - an HSTS enabled site will not allow a user to click through the security warning anymore.

But it gets even worse - because the criminals were able to take control of BGP routing, they could have obtained a legitimate certificate from a real CA. In this case, there would have been no warning at all.

They can do this because low-grade, "Domain-Validation", would check they controlled the DNS and server - which they can do - and then issue them a perfectly real certificate. Neither HSTS nor sensible users will help if an attacker controls the IP address of the real server.

CAA

Certificate Authority Authorization records are DNS records which tell a CA what CAs are allowed to issue certificates for a domain. A CA asked for a certificate for MyEtherWallet would then lookup a CAA record for the domain and check that it was allowed to do so.

CAA records were developed by people working for CAs, so they're well supported - although you'll need a DNS provider that supports them.

Clearly these are a good idea, but they're insufficient in this case - the attacker actually did subvert the entire DNS service, meaning that the CAA record, even if present, would be under the control of the attacker.

DANE

DANE records are again DNS records, this time telling a client what to expect from the TLS certificate. They're powerful records, and will work both to supplement or replace a traditional CA.

However, they're not well supported by browsers or DNS providers; clearly these would be useful if they were.

But again, the DNS was entirely subverted here - however, DANE records are reliant on DNSSEC, so perhaps all is not lost.

DNSSEC

DNSSEC is a set of standards for securing DNS. They are record security, not transport security - so you can look at a DNS record and know if it's genuine.

DNSSEC would make it very difficult for an attacker to subvert DNS, even with BGP Hijacking. Once this is in place, it also means that both CAA records and DANE records are reliable, making it very hard for an attacker to subvert TLS even if BGP Hijacking.

Unfortunately, many registrars, DNS providers, and even top level domains do not support DNSSEC today, and even many resolvers won't bother checking. In this case, the attacker had rerouted traffic to Amazon's Route53, which does not support DNSSEC.

CT

Certificate Transparency is another useful trick here. This means that the CAs publish a log of what certificates they issue, so a site owner can monitor for a CA issuing a certificate they don't know about.

This is a useful auditing tool, and while it wouldn't prevent anything, it does mean the window for criminal activity is smaller.

HPKP

Websites can also provide information about what certificates are valid, and how that might change, in the headers. HTTP Public Key Pinning means that regular visitors to your website can validate the certificate is one that you, the site owner, was expecting them to see.

Some browsers cache this data automatically and will reject this; but here's the thing - Google Chrome is dropping support for this in favour of a CT-based system. I'll be honest with you, I don't see how CT replaces this. I'll chalk it up to one of the many things I don't understand in security.

Other Protocols

So far, we've really only looked at HTTP. But there are other protocols... How secure are these from a BGP Hijacking attack?

HTTP relies for essentially all its security on TLS, and while the protocol does have authentication support, authentication has traditionally been implemented in a bespoke manner inside the webapp instead of at the protocol layer. Other protocols tend to have authentication as a mandatory, first-class feature, however, and so gain a lot of security from this - not least because many of the older authentication mechanisms were designed on the basis that TLS might not be present at all, and hence cope much better if it becomes compromised.

XMPP, for example, requires TLS, with valid certificates (and, these days, most people do deploy this way). But it also mandates that servers implement "SCRAM", which itself authenticates both ends of the connection. SCRAM is a SASL mechanism, and SASL is the subprotocol that more or less every protocol aside from HTTP uses to perform authentication.

This all means that an attacker would have to operate not as a replacement endpoint, but instead act as a Man In The Middle, allowing the user to authenticate through them, and then taking over the connection. This is, of course, well within the attacker's capability.

However, SCRAM has two forms - "SCRAM-SHA-1" and "SCRAM-SHA-1-PLUS". Servers which offer the latter one can detect if there is a MITM present, by a mechanism called channel binding. (A downgrade attack between them is also protected against, by the way).

Loosely, channel binding works by including the TLS negotiation traffic in the SASL mechanism, so both ends know they negotiated the same TLS session. As such, the attacker can no longer act as an MITM - they cannot make a new TLS session to the real server that looks the same as the one the client sees.

Sadly, channel binding is not well implemented - HTTP has no support for it, and as such the TLS stacks don't always provide the data needed. As an example, you cannot do this from a browser at all, nor in Java (and therefore not on Android). But where it works, XMPP (and other SASL_using protocols like IMAP, SMTP, LDAP, and even PostgresQL databases) can be secured relatively easily - and might even be secure against a BGP Hijack attack already.

Caveat

As always, I am not (really) a security expert. Any comments below are part of this article, and probably (hopefully!) include corrections and clarifications.