September 12, 2014 archive

Email Hijacking – New Research Shows Why We Need DNSSEC Now!

Want a great example of why we need DNSSEC now?  Consider this new research from the CERT/CC team at Carnegie Mellon University that finds that someone is hijacking email messages to relay them through another email server.  The messages are being delivered, but it’s unknown whether they are being modified before delivery or simply logged and monitored.  As they say:

The disconcerting aspect of this work is not how many domains we see being poisoned, as there are relatively few, but which domains they are. We observe changes in A records so that a domain resolves to a different IP address. But the domains being targeted are often listed as name servers or mail exchanges for other domains. The biggest free webmail providers have been repeatedly victimized on some unknown (but likely smaller) subsection of the Internet sometime during the last year.

Someone… or multiple entities… appear to be poisoning DNS caches so that they can interject their own mail server into the delivery path of the email messages.  The CERT/CC team goes on to explain the attack and provides a very useful diagram:

Figure 2 diagrams how this usual process can be thwarted if the DNS answer for the IP address of the destination MX is changed. The mail message makes an unintended pit stop at the poisonous IP address. That server can then forward the message to its intended destination. Since mail is transmitted asynchronously, the sender and recipient are not likely to notice anything out of the ordinary. The sending IP address in the message header would likely reflect the diversion, but since mail handling often has a few exchanges before the final destination, it is not immediately obvious to anyone along the path that the diversion was out of the ordinary. 

MX cache poisoning

They go on to outline the potential outcome of the attack:

Unless the whole message is cryptographically protected, the intermediate server can read and modify the message, or append malicious content. This attack would defeat opportunistic TLS encryption between MXs that is meant to ensure the confidentiality of messages in transit. And there are some small changes the intermediary could make to the mail that would make the attack worthwhile, such as changing a bank account number for a home purchase deposit.

Essentially, the attacker could do anything they want with the email message as it is now in their possession, including:

  • Modify the message to either add, change or remove content
  • Log the message (and all of its content) in some large database
  • Simply drop the message (i.e. don’t deliver it) so that the recipient never gets the message

The researchers don’t yet know who is behind this redirection.  It could be:

  • Criminals
  • Nation states (ex. intelligence agencies)
  • Other security researchers

All they know is someone is hijacking delivery of email messages for some reason – and they are seeking help from the larger Internet community!  (Please see the bottom of their post.)

How To Protect Your Email Delivery

As the researchers note, DNSSEC is designed to prevent this type of hijacking of DNS information.  This type of hijacking would be prevented if:

1. The recipient’s domain name was signed with DNSSEC which means that the MX records (and all other DNS records) would have a cryptographic signature added.

2. The sender’s local DNS resolver was performing DNSSEC validation in which it checked the DNSSEC signatures.

Had this been in place, then the sending mail server would not have received the false MX record and would not have delivered the email to the attacker’s server.  You can read more in our document about the two sides of DNSSEC.

This hijacking of email messages is going on right now on an ongoing basis according to the researchers, and so you can take two steps to ensure that your email messages are not being hijacked:

1. Sign Your Domain With DNSSEC

The first step is to sign your domain with DNSSEC so that your MX records are protected.  If you do not operate your own DNS servers, this may involve you contacting your DNS hosting provider or DNS registrar to ask them to perform DNSSEC-signing on your domain.  We have some information about how to do this here:

and ICANN has a list of some of the registrars that provide some degree of DNSSEC support.

If you do operate your own authoritative name servers for your domain, then you can determine what you need to do to sign the domain with DNSSEC.  Many of the common authoritative name servers such as BIND, NSD, Knot and Microsoft Windows Server 2012 all include support now for DNSSEC signing.  There are also additional tools such as OpenDNSSEC that can help make this work smoothly.  Some of the resources that may help:

Once you have signed your domain, you will then need to communicate your “DS record” to your parent zone (often the top-level domain) by way of your registrar.  See our page about working with registrars for more information.

2. Turn On DNSSEC Validation On Your Network

With signing, inbound email messages to you will not be hijacked (assuming the sender is performing DNSSEC validation), but the possibility will still exist for outbound messages you send to be hijacked if your mail server doesn’t learn the correct address for the recipient’s mail server.

To enable this layer of protection, all you need to do is turn on DNSSEC validation on your local DNS server – or whatever DNS resolver your email server uses.   That is the important part because in this instance we are trying to protect email delivery.  You want your email server to be getting the correct DNS information.

We wrote about how to do this and recommend an excellent whitepaper from SURFnet that explains how to easily do this with three of the common DNS resolvers: BIND, Unbound and Microsoft Windows Server.

Now… if you don’t control the local DNS server – for instance, if you use the DNS resolver at your local Internet service provider (ISP) – then you need to contact that organization to find out if they can enable DNSSEC validation.

If your ISP is unwilling/unable to turn on DNSSEC validation, you could set your mail server to use external DNS servers that perform DNSSEC validation such as Google’s Public DNS, but we don’t recommend this unless it is your last resort because using such a distant DNS server provides a lot of room for an attacker to still inject fake packets.  As we wrote about in our “plan for DNSSEC validation“, the ideal is to have the DNSSEC validation happening as close as possible to the mail server (in this case).    It would be much safer, and perhaps quite easy, to install a local DNSSEC-validating resolver on or near your mail server itself.

 

With those two steps, you will protect the delivery of email to your domains – and protect your mailserver from delivering email to whomever is out there right now hijacking all these messages.

Let’s do that today, okay?  If we all do it now we can make the Internet that much safer and more secure!

If you’d like more information about DNSSEC, please see our “Start Here” page to find resources tailored to your type of organization and role – and please let us know if you need even more information!

How Do We Define ‘SIP’ for Telecom In 2014? (Featured Blog)

"What is a minimum set of specifications that a vendor must implement to be able to say that it is SIP-compliant?" A friend asked me that question and my response was: "It depends." and even more unfortunately: "I don't know." It turns out to be a challenging question to answer... and it led me to ask: "How do we define what "SIP" is for telecommunications in 2014? How do we help vendors move their products/services to be based on SIP? As we talk about "turning off the PSTN" and "moving all telecom to IP", how can we make it easier for companies to switch to using SIP? More...

How Do We Define ‘SIP’ For Telecom In 2014? (Featured Blog)

More...

Facebook Launches IPv6-Only Data Cluster

If you are a Facebook user and are also interested in using IPv6 wherever possible, Facebook’s Paul Saab just announced yesterday that there is now a special link where you can connect to Facebook’s IPv6-ONLY data cluster. In the IPv6 group on Facebook (of course!) he posted:

Back in March I announced we were working towards having IPv6-only clusters. I’m happy to announce that we’ve successfully launched our latest cluster as IPv6-only. If you want to make sure that you’re using the IPv6-only cluster, we’ve redirected traffic for http://www.v6.facebook.com/ so that it uses it

Just to be 100% clear, you have been able to access Facebook over IPv6 ever since World IPv6 Launch back in 2012 just by going to the regular http://www.facebook.com/ URL.  Users of the IPvFoo/IPvFox browser add-ons have been able to see that we’ve been connecting to Facebook over IPv6.  It’s all worked great.

However, while the connection to the main Facebook page has been over IPv6, that page has also still required some connections over the legacy IPv4 network.

With yesterday’s news from Paul Saab, those of us who want to truly do everything over IPv6 can now do so by connecting to http://www.v6.facebook.com/. Admittedly, this may only be of interest to those of us who are advocates of IPv6, but still, it’s pretty cool to have full access to a major site like Facebook entirely over IPv6!

You may recall that back in March, Paul Saab gave an excellent presentation about how Facebook is moving to entirely using IPv6 within their internal networks.

fb-internal-ipv6

 

His slides are available and you’ll note that on his second to last slide he wrote:

  • Plans for first IPv6 only cluster (no RFC1918) by end of 2014

This news yesterday is the completion of those plans (and well before the end of 2014, too!).

Kudos to Paul and his team at Facebook – it’s great to see this work happening and to have a way we can work with Facebook in pure IPv6-only network. Thanks!

What are you waiting for?  Visit our “Start Here” page to find resources available to help you make the move to IPv6 – and let us know if there is anything more we can do to help you!