This article 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, it is
equally effective at defeating email in-transit encryption. This article
explains how this attack works, how it can be mitigated and to what extent
it also affects the security of a website.
Before delving into how 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 records are used to
translate a domain address, let�s say www.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 records are 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 Bob�s 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 Alice�s
server will connect to to deliver the email to Bob. In our example, Bob�s
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 Alice�s mail server to find out where to deliver Alice�s 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. Alice�s server believes this IP
address is the legitimate one for Bob�s 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://www.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 don�t 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,
www.elie.net instead of https://www.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 don�t 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 owner�s private
key. This will guarantee that an attacker won�t be able to send a
spoofed DNS record to the client because they can�t 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 don�t 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.
By Elie Bursztein -
Google anti-fraud and abuse research team lead | |
