On April 24, 2018, users of a popular Ether (a popular cryptocurrency comparable to Bitcoin) wallet service got an unusual message when they navigated to the website to log in: the SSL certificate on the website read as invalid. On further examination, they would find that the certificate was self-signed.
Some users would have stopped there. After all, it’s common sense not to log in to a website with a certificate error. Full stop.
But not everybody. With the certificate error being all that was wrong and everything else looking completely correct, some users still signed in against their best instincts. Anyone who did immediately saw a 10 second countdown timer before their available cryptocurrency was transferred to another wallet.In other words, they got phished.But how did this happen? Nobody clicked a lookalike link in an email, they navigated directly to the website or used their bookmark.
So, what happened?
We’ll get to that. But let’s back up a bit. First, we have to get into some of the nitty gritty of how the internet works. To begin with, there’s DNS.As a registrar, we’re in the business of selling domain names, which means we let you assign a name, let’s say example.com, to the IP address of the server you host a service on, like your website, your email, etc.DNS is how you tell the internet what IP address goes with what name. You assign DNS servers to your domain name that have it all mapped out as to which IP addresses go with example.com, www.example.com, etc., which ones have your email on them and so on.Then, when someone opens a browser window and types in ‘example.com,’ their computer asks a DNS resolver what IP address it should connect to to find your site. If they or someone else on the same network recently visited your site, then the DNS resolver probably has that information stored in its cache and it can just give that answer to your computer. If it doesn’t know, it will go up the chain and ask the next DNS server.The DNS resolver then caches the response to use later, for a set period of time (called the time-to-live, or TTL).
That way, the next time someone on the network asks for a particular response, the answer doesn’t have to be requested from the source.These days it’s increasingly rare for owners of domain names to run their own DNS servers. They usually use their registrar’s DNS servers or a third-party provider like Cloudflare or Amazon Web Services.Because it’s distributed, DNS is a very robust system. But at the same time, it has a weakness. The system is built on trust. Each DNS server along the way trusts the DNS server above it to give it the right answer.What happened with the case of the Ether wallet phishing was that somehow, someone got everyone’s DNS resolvers to
think a fake answer was the real one.
How do you fake a DNS response?
DNS requests and responses are not encrypted and they can be read by anyone.If an attacker can intercept your DNS request, then they can spoof the response and point your computer to the wrong IP address. To do that, an attacker would have to hack their target’s internet service provider, their DNS, or their DNS provider.In the Ether wallet site attack in April 2018, all DNS requests to the attacked site received the wrong answer in response. Somehow, someone hijacked the website’s DNS servers.
Hijacking DNS servers
The website in question was using a popular web service’s DNS servers as their domain’s DNS servers. If an attacker wanted to steal Ether coin, one way would be to hack the site’s web server and change the code. It would be easier, though, if an attacker could just point the site’s DNS to a new, malicious website. If they were able to hack the DNS provider, they would have full control over the site’s DNS and could point it to any website.But instead, the attackers in last April’s Ether wallet site attack chose to provide fake replies to DNS queries to the nameservers already assigned to the Ether wallet site’s domain.How they did it gets to another bit of nitty gritty about how the internet works.
Routing tables
The internet isn’t just one big network. It’s a network of networks.What that means is when you’re connecting to the web at home, you’re transmitting and receiving data—including DNS requests—to and from your ISP network. Your ISP network’s router is then figuring out how to get what you’re transmitting to the right place.These routers have direct connections to some networks but to send data to some networks, they first have to send it through another network who then sends it to the right network.Basically, it pieces together a map of how it can reach every individual network. This is called a routing table. Next, the router shares all of this information with all the networks it’s directly connected to, and so these routing tables get propagated across all the networks on the internet.You probably already know that the internet uses IP addresses to locate any given computer on the internet. Each IP address has a “prefix” that you could think of a bit like a zip code. Each network on the internet advertises to all the other networks on the internet that it can deliver data to IP addresses in that prefix.
When sending data to a destination, a network router uses its routing tables—its map of the internet—to send data to the right network for the destination IP address and on to its destination. This is how all communication happens on the internet. Including DNS requests. After all, DNS servers have IP addresses too.
Just like with DNS, because the system is built on the reliability of the information out there, when incorrect routing information is maliciously or even accidentally sent out by a network, that information can wind up in the routing tables across the internet.
The attack last spring on the Ether website involved doing exactly that. Attackers got core routers on the internet to route traffic to the IP addresses of the Ether wallet site’s DNS service to a server that they owned and controlled.Then, when anyone sent a DNS query for a domain managed on the IP address the attackers hijacked, the attackers’ server sent the response, not the Ether wallet site’s provider. And if someone sent the attackers a DNS query for the Ether coin site’s domain name, the attackers’ server would answer with the IP address of the fake website, and then steal the victim’s information when they logged in to the fake site.
At the end of the day, over $17 million worth of cryptocurrency was stolen.
While some might say all of this demonstrates that cryptocurrencies are inherently a risky proposition, that the users who were victims of the attack should have known better, or that the DNS provider or the Ether coin wallet service somehow failed to protect their users, none of these factors are relevant to the main issue: even though every attack offers lessons for future improvements, it’s important to remember that at its most basic, phishing exploits users’ trust.
On the one hand the takeaway is: you can’t trust anything, not even DNS. But on the other, it begs the question: how can we improve the trustworthiness of the system?
That’s where DNSSEC comes in.
DNSSEC
In DNS as it was created there was no way to know whether the DNS responses you got were actually from the source they purported to be from. As the internet grew, people started to realize that this was an important oversight, and so people started proposing “extensions” to DNS, specifically a set of “DNS SECurity extensions” or DNSSEC.
It took some experimentation to get it right, but DNSSEC as it exists today consists of signing DNS records using public key cryptography. Domain owners generate their own key-pairs, and then send the public key to their domain registrar (usually by uploading them). The registrar then sends the keys to the registry, who then signs the keys and publishes them. It’s similar to the way SSL certificates are generated by website admins, then sent to and signed by a certifying authority (CA).
When a DNS zone is signed using DNSSEC, every time a DNS record in that zone is looked up, it can be verified whEther the record received actually came from where it was supposed to have come from.
That means that any man-in-the-middle, cache poisoning, and even compromise of your DNS servers can all be detected when DNSSEC is used on the zone.
Above all, DNSSEC enables you to be able to trust that the answers you get back from a DNS server are correct. In the case of the Ether website, the fraudulent DNS server wouldn’t have been able to fake the signed DNS records and point users to a fraudulent website.
What’s more, without DNSSEC, the attackers could have used their control of the attacked website’s DNS servers to create a real SSL certificate that looks just as valid to a browser as any other valid certificate leaving users with zero warning whatsoever that the page was fraudulent. With DNSSEC, that wouldn’t be possible.
Risk and trust
It’s important to note that what happened to the Ether coin wallet website isn’t some risk inherent to cryptocurrency. DNS hijacking doesn’t just happen to cryptocurrencies. In late 2016, a Brazilian bank had their domains hijacked by the same kind of attack suffered by the Ether coin wallet website, which not only impacted their website, but ATMs across the country, in the US, and the Virgin Islands, exposing millions to potential theft.
But neither of these attacks targeted a currency or a chain, but targeted websites. Any website could be compromised in this way, not just a cryptocurrency site, and not just a financial site.
The risk is present anytime exploiting vulnerabilities in technology can lead to huge paydays for would-be thieves.But the other side of the coin (fiat or not) is the issue of trust. It’s easy enough to be jaded by the many cyberattacks out there and the seemingly obvious vulnerabilities that are exploited. The type of attack suffered by the Ether coin wallet website’s users, though, was not so different from the typical scams running and succeeding everyday.
People wire money to Nigerian princes because they trust that when an email arrives in their mailboxes that it must be honest and reliable information. They click links in phishing emails because they trust that the domain they see in the link is the one it appears to be. And they ignore certificate warnings and log in to their cryptocurrency wallets anyway because they trust the core services of the internet, like DNS and network routing.
DNSSEC is a useful technology because it uses cryptography to increase trust in one of those core services and we highly recommend everyone to use it, not just to avoid these types of attacks, but because it helps us all feel more confident in what we can and cannot trust. But it isn’t perfect.
Other considerations
One consideration is that the Ether site’s domain name didn’t have HSTS enabled. This protection would have made it harder to bypass the self-signed certificate warning since no option would have been presented to the user to ignore the warning and proceed anyway.
On the other hand, the fact that users got a warning at all was a lucky break. Because the attackers were redirecting all DNS traffic for the Ether wallet site’s domain to their own servers, that means they could have also acquired a “valid” SSL certificate using DNS validation.
Another consideration is that if the attacker had chosen to re-route traffic to a DNS resolver, everyone using that resolver could have their traffic re-routed to a phishing site of their choice and DNSSEC would be powerless to stop it. That’s because DNSSEC verification is done by the DNS resolver itself, so if DNS is hijacked anywhere between your browser to the DNS resolver itself, DNSSEC won’t protect you.
In the end, no single security technology is ever sufficient to protect against every type of attack. And an attack can always be thwarted in multiple ways. DNSSEC is no silver bullet to stop all attacks like this.
Tagged in DNSSecurity
