DNS cache poisoning used to steal emails

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.

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