This post looks at how an attacker can intercept and read emails sent from one email provider to another by performing a DNS MX record hijacking attack. While our research on the state of email delivery security indicates that this attack is less pervasive than the TLS downgrade attack discussed in a previous post, it is equally effective at defeating email in-transit encryption. This post explains how this attack works, how it can be mitigated and to what extent it also affects the security of a website. Before delving intohow this attack works and countermeasures, I will briefly summarize DNS and DNS MX records for the readers who are not familiar with this aspect of the Internet. If you are familiar with this topic, you can skip the next two sections.
Understanding DNS records
DNS (domain name server)records are used to translate a domain address, lets say https://elie.net, into an Internet address, which are commonly known as IP addresses. This translation is needed because computers only know how to communicate with an IP address and not a domain address. This translation is also helpful because it allows multiple servers and IP addresses to have the same domain address, which allows redundancy and scalability. It also helps make the Internet faster by allowing big services and CDNs to host the same content in many different countries on various servers and return the IP address of the closest server to the client when they look up the domain address. This technique is called geoIP load balancing.
Understanding DNS MX records
DNS MX recordsare a specific form of DNS record that allows us to know which IP address to use when sending an email to a given domain. As visible in the diagram above, when Alice wants to send an email to Bob (bob@destination.com), her server (smtp.source.com) needs to resolve the IP address of Bobs mail provider server. To do this, her mail server asks the DNS server for the MX record for the domain, destination.com. The server will reply with the IP address that Alices server will connect to to deliver the email to Bob. In our example, Bobs server has the IP address 1.2.3.4.
DNS MX record hijacking
DNS hijacking attacks work as follows. The attacker poses as or compromises the DNS server used by Alices mail server to find out where to deliver Alices email to Bob. Instead of returning the legitimate IP address, the DNS server returns the IP address of a server owned by the attacker, as illustrated in the diagram above. Alices server believes this IP address is the legitimate one for Bobs server and delivers the email to the rogue server. The attacker reads the email and to make the attack invisible, forwards the email to the real server. This attack is possible because DNS was not designed with security in mind and as a result, there is no default security mechanism baked into it to authenticate that the request was sent by the rightful owner of the domain. This shortcoming will eventually be fixed with the deployment of DNSSEC and DANE. This deployment and other ways to mitigate this type of attack are discussed at the end of this post.
Are websites vulnerable as well?
Can an attacker use DNS hijacking to prevent HTTPS and read or intercept web pages? At the moment (2015), the answer is complicated but hopefully in a few years the answer will be a straightforward no :) Like email until DNSSEC is deployed and enforced, websites are vulnerable to DNS hijacking. However, there are a few mitigations that make such attacks significantly harder than for emails, at least until almost the same mitigations are deployed for emails in transit, which is what Gmail and the other big email providers are working on. Here are the two key differences that make DNS attacks harder against websites.
HTTP vs HTTPS separation: In the web world, the non-encrypted version (HTTP) and the encrypted version of the protocol (HTTPS) use different addresses and are treated differently by browsers (same orgin policy). When you enter a URL starting with https, e.g. https://elie.net, you are instructing your browser to establish an encrypted connection. In that context, carrying out a DNS hijacking attack does not help the attacker because they will still need a valid certificate for the domain because the browser will refuse to establish the connection otherwise. So, if you type a URL starting with https or click on a link with the https prefix, you are safe.
HTTP Strict Transport Security (HTST): This specification helps mitigate what happens when you dont specify whether you want to talk to the server in clear (http) or encrypted (https). Typing the URL directly in a browser is common, for example, elie.net instead of https://elie.net. In that case, the browser has no idea if you want the encrypted version of the site or not. For backward compatibility reasons, as some sites dont support HTTPS yet, your browser will default to the unencrypted version. HSTS aims to mitigate this issue by allowing websites to tell the browsers that they should only connect over HTTPS. Technically, a website sets HSTS by sending a HTTP header to the browser. Once this header is received by the browser, every subsequent request to the site (and possibly its subdomains) will be automatically upgraded to HTTPS by the browser. Therefore, this also protects against the set of attacks in which the attackers supply to their victims a link that starts with http:// in an attempt to intercept the communication, since the browser will upgrade it to HTTPS before the request is sent over the network.
Preventing DNS hijacking attacks
The long-term solution to this issue is the deployment and enforcement of DNSSEC, which will hopefully make DNS hijacking an obsolete attack by requiring DNS records to be signed with the domain owners private key. This will guarantee that an attacker wont be able to send a spoofed DNS record to the client because they cant forge the signature. This will protect every protocol, including SMTP and HTTP, against those attacks. In the shorter term, mail providers are working on developing a technology similar to HSTS but for SMTP traffic. This SSTS protocol (the name is yet to be defined) will allow us to pin a certificate and enforce that all emails are sent encrypted. This will prevent both MX hijacking attacks and TLS downgrades for providers that deploy it. This protocol is still in the early stage of specification but hopefully deployment is not too far in the future. Today, signing emails with DKIM and enforcing signing with DMARC help alleviate the issue by preventing an attacker from modifying intercepted emails. The attackers dont have access to the legitimate DKIM private key, so when the receiving server checks for the presence of DKIM and checks the email signature, if the email was modified in any way, the receiving server will reject it. DMARC also helps in detecting attacks against your domain by allowing you to supply an email address where you will receive a statistical report of how many emails have failed the DKIM signature check. If you found this post useful, please share it on your favourite social networks. This helps me to know if my posts are useful and motivates me to keep writing. Please also let me know if you would be interested in me doing a series of posts on how email authentication technologies work.
