Hi, this is Jonathan Spring with my colleague Leigh Metcalf. For some time now, we've been working through a problem we found, but it's time to discuss it more broadly. Using our passive DNS data source, we can observe cache poisoning. What we really observe are changes in the answers that are returned for certain domains, but after consulting with various experts, we believe the only behavior these changes indicate is a successful cache poisoning attack.

The mechanism used to poison the answers is not clear. We see only responses, not queries, and figuring out the mechanism requires visibility into the queries. This limited visibility is one reason to disclose what we've found so that others can look for the root cause.

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.

Let's take a step back and look at what happens when an organization is trying to send mail to Gmail, Yahoo, or Outlook.com. Figure 1 diagrams the usual path at a high level of abstraction. The organization's mail server does a DNS lookup for the IP address of the destination MX, gets an answer, and sends the message along. This path is an oversimplification; with mail there may be a few exchanges such as this before the message reaches its final destination.

Figure 1: A usual mail handling path following a usual DNS answer

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.

Figure 2: A mail handling path hijacked via DNS cache poisoning

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.

Our method for finding this type of hijack is simple enough. We look for two different name servers providing different A records for the same domain. It's then a simple matter of filtering out content distribution networks, which usually have consistent network features like ASN, TTL, and an even distribution of changes. The only real trick is having the Internet-wide visibility in passive DNS to see when two different servers provide two different answers. This need for Internet-wide visibility is why we find data sharing and collaboration in the network security space so important.

Officially, using DNSSEC properly should prevent this issue. End-to-end mail security solutions, or even just signing mail cryptographically, would also help. However, neither of these is deployed widely enough to be an immediate solution. To that end, we're providing a list of IP addresses that we have observed in the rdata of an A record that is a poisonous, or injected, A record for another mail server.

Many of these IP addresses are hosted in shared hosting environments and appear suspicious. Some of them are google IP addresses that were oddly used as the IP for mail-handling domains in the .vn or other TLDs. This list is not an outright blocklist, but it is a place to begin some investigations for mail received from a place you were not expecting.

List of IP addresses

This work is related to other work we're doing, such as detecting malicious name servers in pDNS, domain name take down, and blocklisting. However, this other work likely won't help the cache poisoning situation on its own; we've previously discussed why these defenses fall short. Until we learn more about the scope of the problem, we cannot recommend what the appropriate response should be. If you can share any data that might be helpful, please get in touch.