DNS Attacks in the Wild - Austin

Via Metasploit Blog -

In a recent conversation with Robert McMillan (IDG), I described a in-the-wild attack against one of AT&T's DNS cache servers, specifically one that was configured as an upstream forwarder for an internal DNS machine at BreakingPoint Systems. The attackers had replaced the cache entry for www.google.com with a web page that loaded advertisements hidden inside an iframe. This attack affected anyone in the Austin, Texas region using that AT&T Internet Services (previously SBC) DNS server. The attack itself was not malicious, did not load malware, and from an operational standpoint, had zero impact. I contacted the ISP, worked with our IT folks to switch forwarding services, and wrote a cache auditing tool. I found the "wild" attack interesting, so in a conversation with Robert McMillan, I brought up the incident and forwarded the associated logs and notes. Shortly after our conversation, Mr. McMillan published an article with a sensationalist title, that while containing most of the facts, attributed a quote to me that I simply did not say. Specifically, `"It's funny," he said. "I got owned."

Most of the facts of the article are correct. I have no problem detailing the attack, how it worked, and how we detected and resolved it. I am careful about the wording, because I want to be clear that while this type of attack can be serious, in this case it was a five minute annoyance that was designed as a revenue generator for the folks who launched it (click-through advertisement revenue). No systems were been compromised, no data was stolen, and most importantly, the target of the attack was the ISP, not the company that I work for. Stating that my company was "compromised" leads the reader to believe that there was some sort of security breach, which is reinforced by the fabricated quote. Mr. McMillan has since published a correction, but by the time this trickles down to all of the IDG publications, the damage will have been done. At this time (09:00 CST), the correction is posted, but the articles themselves have not been updated.

To add some content to my whining, I have included further details on the actual attack. The DNS server in question was dns1.austtx.sbcglobal.net (151.164.20.201). This system accepted recursive requests from anywhere (not just subscribers) and is the default DNS server for anyone who purchased SBC Internet Services (in our case, a T1 line that was our primary until our fiber was run). Internally, we use two DNS servers, one going out the fiber, other going out the T1 as backup. Early Tuesday morning, some of the friends and family members of BreakingPoint employees noticed that the iGoogle web page was returning a 404 from their home internet connections. Once our folks got to the office, they noticed that every once in a while, they could also reproduce it from within our network. Digging into it, we discovered that one of our internal DNS servers was still using SBC/AT&T as an upstream forwarder and that this server was returning the wrong results for www.google.com.

[...]

We changed the upstream forwarder for our internal DNS to point to a patched server (the ubiquitous BBN 4.2.2.x systems (OpenDNS has issues[1]), contacted the ISP, and wrote a cache validator that does not require host access to the DNS server (see the previous post for more information on that). The lesson -- even if your own DNS servers are patched, make sure none of those systems use an upstream DNS that has not. Since we contacted the ISP, this particular DNS server was taken offline. I found a list of regional SBC DNS servers and prodded them with the porttest.dns-oarc.net service. The end result was that of the 19 servers still online, 12 of them are still using static source ports, and each of these can be reached by anyone on the Internet. I wonder if they are waiting on ISC to fix BIND's performance problems.

-------------------------

Moral of the Story - Everyone in Austin using this SBC/ATT DNS server was the victim of a click-thru ad'er trying to make some money. It easily could have been malicious, but it wasn't....this time.

Breaking Point wasn't hacked. The issue was caused by ATT/SBC's slow patching response. This might have happened in Austin, but with the huge number of DNS servers still not patched...it is bound to happen again somewhere else. And it will continue to happen for a long long time.