First instance of new DNS exploit reported
Connecting state and local government leaders
An AT&T DNS server may have been compromised with malicious code that exploits a vulnerability reported earlier this moth in the Domain Name System.
Reports are coming in that an AT&T Domain Name System (DNS) server may have been compromised with malicious code that exploits a vulnerability reported earlier this month. This apparently is the first instance of the exploit in the wild.'The attackers had replaced the cache entry for www.google.com with a web page that loaded advertisements hidden inside an iframe,' wrote H.D. Moore, director of security research at BreakingPoint Systems Inc. in his . 'This attack affected anyone in the Austin, Texas, region using that AT&T Internet Services (previously SBC) DNS server.'The attack reportedly began Tuesday, and was noticed by BreakingPoint workers, some of whose Internet traffic was being redirected.'The attack itself was not malicious, did not load malware and, from an operational standpoint, had zero impact,' Moore wrote in his blog.But it did serve to underscore the importance of installing patches for this vulnerability, which were released July 8. 'The lesson: Even if your own DNS servers are patched, make sure none of those systems use an upstream DNS that has not,' Moore wrote. 'Since we contacted the ISP [Internet service provider], this particular DNS server was taken offline.'DNS is a hierarchical system that translates written names, such as those in URLs and e-mail addresses, into IP addresses. Dan Kaminsky, director of penetration testing for IOActive Inc., discovered the bug about six months ago and helped to coordinate an industry response that resulted in the multivendor patch release. Kaminsky has not released details of the vulnerability, but some specifics have leaked out in the last three weeks and some proof-of-concept exploits have appeared.Web poisoning exploits already known to exist but, because the new vulnerability is in the basic design of the protocol itself, it is potentially more dangerous because almost all DNS servers are vulnerable until patched. Redirected Web site requests could make it difficult, if not impossible, to trust Web-based data and transactions.Although details of the vulnerability have not been released, Kaminsky said it involves a weakness in the transaction ID used in DNS queries. Currently, replies to a DNS query have to contain the proper transaction ID, which is chosen randomly from 65,000 values.'For undisclosed reasons, 65,000 is just not enough,' Kaminsky said. 'We need more randomization.'That is being obtained from a source port ID, another random identifier in the packet. After patching, replies to DNS queries will require not only the proper transaction ID but also the proper source port ID. 'We are making a system that was somewhat random more random,' Kaminsky said.'The use of randomized source ports can be used to gain approximately 16 additional bits of randomness in the data that an attacker must guess,' US-CERT said in its bulletin.The first exploit was not as bad as it could have been, according to Moore. '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 [click-through advertisement] revenue generator for the folks who launched it,' he wrote.In describing the attack, Moore wrote that the affected 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, the other going out the T1 as backup.'According to Moore, when employees began noting problems on Tuesday, '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. Requesting the main Web page from the 'poison' www.google.com server returned a very different response from the real Google server. This server was returning four iframes, one of which showed a fake version of the Google web site, the other three loaded automated ad-clickers from three other compromised servers.'
NEXT STORY: Experimental networking testbed gets bandwidth