News from Microsoft: DNS 0day being exploited in the wild

http://blogs.technet.com/msrc/archive/2007/04/12/microsoft-security-advisory-935964-posted.aspx

It seems not long ago I use to observe many an argument about if 0day is ever really used in real world attacks. No one really has those fights anymore; I guess the pundits are weary from all the numerous 0day attacks that have popped up in the last few years. I don’t care to go and dig up links to naysayer’s but I am sure the usual suspects like Lindstrom have pie all over their face on the “0day isn’t really used in attack” predictions.

Back to this new bug, it’s in server code so workstation type installations like Windows XP SP2 and Windows 2000 Pro are not affected. Microsoft, of course, doesn’t give details on the flaw or even what people should look for in a potential attack scenario. The only real clue to this is that it involves RPC and that its not vulnerable over port 53. I can hear the sound of people starting IDA all over the world, I know I am. A bit more of a clue to the problem is given in the “Suggested Action” section: creating a registry key can disable the functionality that allows an anonymous remote attack to trigger a stack based overflow. I personally think Microsoft gave out way to much detail here, but time will tell.

The one thing wish Microsoft would tell you is what sector or client profile is being targeted. No sense for people in a University to get all paranoid if the targets have only been Military installations so far. Of course its never a bad thing if everyone is more cautious.

Errata will have an HEV on this for customers pretty soon.

UPDATE: Running DNS.exe through something like Dave Aitel's UNMIDL or using the Tenable IDA plug-in mIDA (pictured below), there isn't a lot of places a bug could be. The SANs ISC diary initially said it was the DCOM exploit over a new port. The arrived at this conclusion because they claimed that the packets matched a Blaster exploit. One of the byte strings they said matched was this: 05 00 0B 03 10 00 00 00 I found this laughable because if you have spent anytime wrangling packets you know exactly what that is. It’s the beginning of a DCERPC BIND request. The 05 is the major version, the 00 is the minor version, 0B is the request type (in this case it’s a BIND, 03 is the flags, and 0x10000000 is data representation (if its little endian or big endian). If you look at a lot of traffic you will notice that this is pretty standard for the beginning of a DCERPC request, and there are tons of reasons you would see this legitimately.

BTW, since this is a RPC based attack you will see plenty of ways to evade most IPSs when they release signatures for this. Based on the ease of finding this you should see publicly available exploits pretty quickly. The question is will the patch be out quickly enough to make this a non-issue for attackers.

UPDATE 2 PER ROB:

One possible signature for intrusion detection would be to simply trigger on the GUID of {50abc2a4-574d-40b3-9d66-ee4fd5fba076}. In a protocol-analysis system, like Proventia, you could simply add that to the blacklisted GUIDs. In a pattern-match system, you can enter something like:

alert tcp any any -> any 1024: (msg:"DNS DCE-RPC exploit emergency rule"; content:"a4 c2 ab 50 4d 57 b3 40 9d 66 ee 4f d5 fb a0 76"; sid:9999; )

Note that the exploit, and its evasions, are a bit more complicated than just this, so you shouldn't rely upon the above pattern signature catching everything.