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:

In memoriam: Dr Alan Solomon

We were very sorry to learn of the passing of industry pioneer Dr Alan Solomon earlier this week.

New paper: Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

In a new paper, researchers Aditya K Sood and Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited in order to gather threat intelligence, and present a model of mobile AppInjects.

New paper: Collector-stealer: a Russian origin credential and information extractor

In a new paper, F5 researchers Aditya K Sood and Rohit Chaturvedi present a 360 analysis of Collector-stealer, a Russian-origin credential and information extractor.

VB2021 localhost videos available on YouTube

VB has made all VB2021 localhost presentations available on the VB YouTube channel, so you can now watch - and share - any part of the conference freely and without registration.

VB2021 localhost is over, but the content is still available to view!

VB2021 localhost - VB's second virtual conference - took place last week, but you can still watch all the presentations.

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.