The latest security researches poof that an intruder can intercept and read emails sent from one email provider to another by performing a DNS MX record hijacking attack. Despite the fact that this attack is less pervasive than the TLS downgrade attack, it is equally effective at defeating email in-transit encryption.
As some of you may already know, DNS records are used to translate a domain address, for instance www.elie.net, into an Internet address, which are commonly known as IP addresses. Due to the fact that virtual machines only know how to communicate with an IP address and not a domain address, this translation is certainly needed. Besides, the translation appears to be helpful as it allows multiple servers and IP addresses to have the same domain address, allowing redundancy and scalability.
In addition, it makes 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.
Regarding the DNS MX records, they are a specific form of DNS record which let people know which IP address to use when sending an email to a given domain. For example, 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. In order to do this, her mail server asks the DNS server for the MX record for the domain, destination.com. Then the server will reply with the IP address that Alice’s server will connect to to deliver the email to Bob. In this case, Bob’s server has the IP address 1.2.3.4.
This is how DNS hijacking attacks work. 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.
The above-mentioned attack happens 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. Most probably, this shortcoming will be fixed with the deployment of DNSSEC and DANE.