Security Sense: DNS - The Keys to the Cyber-Castle

And so it was Tesla’s turn. Website compromised. Twitter compromised. Founder’s Twitter compromised. It all unravelled very quickly for them this weekend with seemingly independent digital assets falling victim simultaneously. How do you lose your social media accounts (it was multiple accounts of Tesla’s alone in addition to Elon’s) and your website simultaneously? Bad passwords or even a compromised password then reused would be one way, but there’s another way which can pose even more risk: DNS hijacking.

There’s an old adage along the lines of your email being your skeleton key to just about everything you do online due to it being the primary channel by which you reset passwords on services. But there’s an even more powerful key – one key to rule them all – that is owning the DNS of an organisation. Once you own where both the web traffic and the email goes, as an attacker you start to get some rather tasty options.

One option is obviously controlling email itself. In the case of Tesla, we know that DNS was compromised and we know that Twitter password resets, like most account resets, are orchestrated over email. We also know that Twitter offers login verification via an independent channel which makes this attack very difficult… and we know that it’s optional so draw what conclusions you will from that. Assuming their Twitter account is managed via the compromised teslamotors.com domain, it’s pretty easy to join the dots on this one. Oh – and as we saw with Lenovo recently, once you own the mail records you also own the inbound mail so anything sent to an address @teslamotors.com during the period of compromise can now be considered owned by the attackers.

The other option is simply re-routing web traffic. During the attack, the Tesla website didn’t look real pretty but of course this wasn’t the Tesla website at all, rather an entirely standalone website which had traffic routed to it from the compromised domain. Frankly, if anything the attackers were a bit charitable on this front as they could quite easily have used the compromised domain to get rather malicious (siphon off credentials, serve malware) rather than just muck around with garish colours and images.

The really worrying bit though is when you start to speculate around just how far this attack could have been taken. Tesla exposes API endpoints on the compromised domain – what could you do if you owned the traffic to this? In the case of Tesla, “owning traffic” goes beyond a mere metaphor as you’re talking about a company with vehicles on roads that talk via API. It’s not entirely clear how dependent the cars are on the compromised domain, but certainly if you want to go and build an app as a developer, you’re going to be talking to teslamotors.com which then talks to the car.

Could we have solved the hijacked API traffic problem with SSL? You’d need to see a valid certificate served from the compromised server then and the attackers wouldn’t have this, right? Except that when you own the domain, you can issue another legitimate cert with nothing more than email verification anyway. Short of applying certificate pinning in the consuming apps, SSL would provide zero defence against a determined adversary.

DNS hijackings remain rampant, even Google fell victim to it recently. Sometimes it’s just simple social engineering that results in the compromise as was the notable case related to the Twitter @n account last year. Other times the compromise is related to old hat tricks including login brute force of the domain registrar or DNS provider, sometimes it’s simply a fact of bad credentials. Regardless, DNS attacks remain very successful ways of gaining access to all the victim’s cyber-things.

Troy Hunt
http://troyhunt.com
@troyhunt
Microsoft MVP - Developer Security