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