DNS cache poisoning used to steal emails

Posted by   Virus Bulletin on   Sep 12, 2014

Call to use end-to-end encryption and to deploy DNSSEC.

DNS is sometimes called 'the phone book of the Internet'. If true, then it is a phone book that makes it relatively easy to be tricked into calling someone else.

Whether it is through using social engineering to hijack a DNS account at a gullible registrar, or through DNS cache poisoning, occasionally someone loads a website that wasn't the one they asked for. This is embarrassing and potentially costly for the website owner. It can also lead to malware being served.

But DNS doesn't only tell web browsers where to go. It is used for many other Internet protocols, including email. Being able to modify DNS responses means you can control where mail is sent.

When an email is sent over the Internet, the sender's mail server needs to find the recipient's mail server. This takes two DNS lookups: first, the MX record for the recipient's domain is requested, which returns one or more domains of the inbound mail server. The A record of one of these domains is then requested to find the corresponding IP address.

If one of these two responses is controlled by a rogue actor, they can have incoming mail sent to their own server, without the sender or the intended recipient finding out.

Does this happen in practice? CERT/CC researchers Jonathan Spring and Leigh Metcalf have evidence to suggest that it does. Using passive DNS data, they found a number of incorrect responses for A records belonging to mail servers of the big three webmail providers (Gmail, Yahoo! and Hotmail).

Even though an increasing number of emails are sent over encrypted connections (using STARTTLS), there isn't really a way for the receiving mail server to enforce this, as HSTS does for secure HTTP connections.

The CERT/CC researchers name two solutions to prevent emails from ending up at a rogue server, one at the user level and the other at the server level.

At the user level, one should use end-to-end encryption using PGP or S/MIME. This doesn't guarantee delivery to the intended recipient, but does mean that no one else can read the content of the email.

PGP has been the subject of strong criticism (such as from crypto Prof Matthew Green here), and it is true that it may not be strong enough to protect your emails against an active adversary, but against someone passively slurping up emails, it is likely to provide sufficient protection.

At the server level, the issue should be solved by DNSSEC, which guarantees integrity of the DNS responses. However, while certainly a good idea, only a small minority of domains currently deploy DNSSEC.

On the subject of DNSSEC, I recommend attending the VB2014 presentation 'DNSSEC - how far have we come?' by CloudFlare researcher Nick Sullivan, in which he explains what DNSSEC does and doesn't do to make DNS responses more trustworthy.

  Only around 0.5% of the .com and .net domains currently support DNS (from Nick Sullivan's paper; the source of the graph is Verisign's DNSSEC Scoreboard).

As for the use of DNS poisoning to steal emails, the CERT/CC researchers neither know who is behind it, nor the scope of the issue. To this end, they provide a list of IP addresses used in the attack and ask others with more information to step forward.

I think it unlikely that such attacks are used for targeted espionage, as the attacker will have little control over which emails are going to be sent to the rogue server. However, being able to intercept a random selection of emails will give a skilled cybercriminal enough information to abuse.

Posted on 11 September 2014 by Martijn Grooten

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest posts:

VB2018 paper: Internet balkanization: why are we raising borders online?

At VB2018 in Montreal, Ixia researcher Stefan Tanase presented a thought-provoking paper on the current state of the Internet and the worrying tendency towards raising borders and restricting the flow of information. Today we publish both his paper…

The malspam security products miss: banking and email phishing, Emotet and Bushaloader

The set-up of the VBSpam test lab gives us a unique insight into the kinds of emails that are more likely to bypass email filters. This week we look at the malspam that was missed: banking and email phishing, Emotet and Bushaloader.

VB2018 paper: Where have all the good hires gone?

The cybersecurity skills gap has been described as one of the biggest challenges facing IT leaders today. At VB2018 in Montreal, ESET's Lysa Myers outlined some of the things the industry can do to help address the problem. Today we publish Lysa's…

Preview: Nullcon 2019

We look forward the Nullcon 2019 conference in Goa, India, at which VB Editor Martijn Grooten will give a talk on the state of malware.

From Amazon to Emotet: a look at those phishing and malware emails that bypassed email security products

We see a lot of spam in the VBSpam test lab, and we also see how well such emails are being blocked by email security products. Recently some of the emails that bypassed security products included a broken Amazon phishing campaign, a large fake UPS…

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.