Serious RPC Flaw Could Expose Microsoft DNS Servers to Remote Exploits

This morning, the US-CERT team of the Department of Homeland Security acknowledged Microsoft's advisory this morning, stating that it's investigating instances where Windows servers running the DNS service can be tricked into running any code remotely in a local system context, with the same privileges as the DNS service itself.

As an indication of how seriously Microsoft takes this threat, in a special advisory issued this morning, it instructs customers to use their Registry Editors to set a bit in their DNS parameters for servers running the DNS service, effectively disabling DNS bindings to remote procedure calls (RPC) in favor of local procedure calls only (LPC). From there, the company further suggests that admins use their firewalls to block all RPC traffic, which could extend from ports 1024 to 5000.

Essentially, Microsoft is telling admins to shut off the pipes completely for all traffic that would otherwise enable them to manage DNS servers from remote locations. As the company acknowledges, remote management tools will not function while LPC protocol is favored and RPC ports are blocked by a firewall, though remote management through Terminal Services is still possible.

An engineer with SANS Internet Storm Center who has examined the exploit believes it may not actually be related to DNS at all, since some of its code matches the signature of the infamous Blaster worm of 2004, which had the effect of slowing down many corporate networks to a crawl.

But security engineer David Maynor of Errata Security disagrees. In a blog post this morning, Maynor suggests that comparing the code signature of one exploit to that of another isn't a proper way to judge its identity. The matching code signature in question, Maynor pointed out, is an RPC binding request - the type of request that any DNS host would place to another DNS host, asking it for the rights to make RPC calls. Essentially, it's part of the handshaking procedure that would eventually enable a remote management tool to have access to a DNS server from a more convenient location. Both the Blaster worm and this new exploit would place the same call, which would look the same on a binary scan - that doesn't mean they're the same exploit, he contends.

"If you look at a lot of traffic you will notice that this is pretty standard for the beginning of a DCERPC request," Maynor writes, "and there are tons of reasons you would see this legitimately."

Maynor also suggested that Microsoft should perhaps be a little more forthcoming about the nature of the problem, withhold less information from the public for the sake of ferreting out the perpetrator like a police investigator would, and perhaps instead direct the warning more specifically at the institutions where the perceived threats may have been targeted.

An initial read suggests this threat may not be related to a proof-of-concept circulated among the self-proclaimed Internet underground, entitled "Exploiting Microsoft DNS Dynamic Updates for Fun and Profit." That POC, produced last month, appears to exploit vulnerabilities in Active Directory that can make DNS records point to non-genuine addresses. In such a fashion, comments in the POC's code suggest, Windows systems could be directed to download and even install remote binaries using the same triggers employed for automatic updates and patches.

Today’s threat, Microsoft said, impacts Windows Server 2003 Service Pack 1 and Service Pack 2 (just released), and Windows 2000 Service Pack 4. However, servers which use IPsec to encrypt traffic may not be impacted. Microsoft’s security advisory made a point of saying Vista is unaffected by this problem, although presently, Vista isn’t deployed in many business environments as a server anyway, especially where admins await the release of Longhorn.