Patched DNS servers randomize the UDP source port number, however, that will not eliminate the flaw; it will only increase the time required to poison the cache. Poisoning unpatched systems would take a period seconds, however, poisoning patched systems would take a period of hours.

Unlike the previously released tools that work on poisioning uncached “NS” and “A” records, this tool can overwrite any A record by using a CNAME response. 

The tool uses a static TTL of 0x7BEDABED in all spoofed replies, which should be sufficient to create an IDS/IPS signature to protect against the script kiddies out there.

cname_rr = (struct cname_RR *) (payload + sizeof(struct dns_hdr) + hostname->size + sizeof(struct query_RR));
cname_rr->name = htons(0xC00C);
cname_rr->type = htons(0×0005);
cname_rr->clss = htons(0×0001);
cname_rr->ttl = htonl(0x7BEDABED);
cname_rr->length = htons(entryname->size);

According to VNCERT, the country’s National Computer Emergency Response Team:

“It’s believed the hackers broke in through a hole in DNS to control the administration,”
-VNCERT Technical Branch Chief –  Do Ngoc Duy Trac.

The good news is that PA Vietnam has been able to restore 90% of the websites that lost connectivity as a result of this attack by shifting to a different DNS.

This attack is definitely not related to the recent DNS vulnerability as there was a switch in domain name registrars; archived whois records for PAVietnam.com can be found here. A quick glance at the whois records and it is transferred over from Enom to OnlineNIC.

Was this really yet another DNS hole or just an insider attack? Feel free to post your views.

The above two modules require you run Metasploit Framework from the “trunk” development branch which is currently only supported on the Linux platform.

Here’s more from the official blog:

The first flaw is that since DNS (over UDP) is connectionless, it can easily be spoofed. The original primary mitigation against this was to make use of a 16-bit transaction ID which is used to correlate requests and replies that the attacker would have to guess in order to correctly spoof a reply packet. This makes spoofing harder, but not an insurmountable task; you just need to be able to send a whole lot of packets to eventually get one right at match the transaction ID chosen for the request packet.

The second flaw was that additional records would be inserted into the cache which were included in replies from another nameserver. This is core protocol functionality, however the original problem was somewhat mitigated by creating the in-bailiwick constraints that essentially limits the domain space for additional records that could be sent in the replies to hostnames from a given domain. Sounds reasonable; this prevents nameservers from doing malicious things to records in domains that they weren’t queried for or aren’t authoritative for, while still allowing nameservers who are authoritative for a domain to update the records they need to.

When you combine the attacks for these two flaws however, and introduce nameserver query recursion, an attacker can essentially cause the target nameserver to make as many queries as the attacker wants while also pretending to be the authoritative nameserver and spoofing the responses, achieving the birthday attack against the transaction ID and successfully updating the nameserver record for a domain to point to a malicious nameserver address. You can also use this trick to inject cache entries for individual hostname records as long as those hostnames are both not already cached, and also in-bailiwick.

Update - both the above mentioned Metasploit modules have been updated for improved reliability (and effectiveness!). Support for FreeBSD, NetBSD, BSDi and Mac OS X has been added. Here’s more from the official blog:

The bailiwicked modules (host and domain) were updated today to include the ability to predict the time window between the outgoing request from the target nameserver and the response from the real nameserver(s). This measurement is used to tune the number of spoofed replies sent by the exploit. The result is a big increase in exploit reliability, especially when the target domain has a ton of nameservers (Yahoo has eight) or changes its responsiveness during the test (BIND tends to slow down when it has a full cache). The new self-tuning code is activated with the XIDS option is set to ’0′, which is now the default. FreeBSD and Mac OS X support are still in the works, but should be functional sometime this weekend. The timing analysis feature can also be access through a new command (‘racer’). In the examples below, the first command tests the timing between the nameserver at 192.168.0.2 and the metasploit.com DNS servers. The second command tests the timing between the nameserver 4.2.2.3 (a public DNS server) and the metasploit.com DNS servers. You can see by the results that the timing differences are significant:

msf auxiliary(bailiwicked_host) > racer 192.168.0.2 metasploit.com
[*] race calc: 50 queries | min/max/avg time: 0.05/0.23/0.09 | min/max/avg replies: 6/121/49

msf auxiliary(bailiwicked_host) > racer 4.2.2.3 metasploit.com
[*] race calc: 50 queries | min/max/avg time: 0.02/0.17/0.05 | min/max/avg replies: 1/29/6

In the first case (192.168.0.2), the average number of queries we can send before the real server replies is around 49, which means about 80 fake responses. In the second example, the average is only 6, which means about 12 fake responses. To be conservative, these modules take the average, multiple it by 1.5, then divide it by the number of nameservers. This leads to a fairly accurate timing estimate and quicker attacks.

Update (July 29 – 11AM +4GMT) – I just saw a demo of ISR-evilgrade by Infobyte Security Research, a toolkit that works in conjunction with the above mentioned Metasploit exploit modules, to exploit software products that carry out automatic updates of the binaries over insecure channels, using MITM techniques (Hint: DNS!).

The first release of the toolkit contains exploits for Sun Java, Winzip, Winamp, Mac OS X, OpenOffice, iTunes, Linkedin Toolbar, DAP, Notepad++, and Speedbit.

It is interesting to note that Mac OS X does not have a patch for the DNS vulnerability as of this writing.