MS15-127 - notes from limited examination

I'm on the road this week with a Rendition Infosec client so I haven't really had time to get too deep into MS15-127.  But I have a few notes I think can be moderately useful in understanding the scope of the vulnerability.

This post explains how to disable recursion entirely, but not explicitly for DNAME records.  The relevant information from the post is pasted below. If you want to disable recursion on the server, us the '1' value.

dnscmd <ServerName> /Config /NoRecursion {1|0}

I was originally fearful that Windows Server 2003 would be vulnerable with no patch available, but it does not appear that 2003 supports DNAME records.  In fact, this KB corrects errors with DNAME processing without really adding support.  I haven't looked at the code for dns.exe, but I think we're safe there.

So back to the vulnerable servers.  Where do the code changes lie?  Well, running the application through bindiff, we see very few changed functions.

The changed functions certainly seem to imply that DNAME records are to blame.

Answer_PerformDNAMESubstitution function changes

Above are some example changes in Answer_PerformDNAMESubstitution - notice the calls to lock and unlock the database that have been added.  This seems to be a common theme with the patch. 

processCacheUpdateQueryResponse changes

The changes to processCacheUpdateQueryResponse look very similar. The database is locked, then _Recurse_CacheMessageResourceRecords is called.  Note that sometimes Microsoft adds extra changes to a patch just to throw off reverse engineers.  But this looks pretty solid.  My point here is that while it appears that both DNAME caching and recursion are required to exploit this, it's possible that one of these is a decoy.

processRootNsQueryResponse

Here are more changes, these from processRootNsQueryResponse.  Again, we see the use of _Dbase_LockEx and _Dbase_UnlockEx in the code.

Gnz_ProcessCacheUpdateQueryResponse

Above is a portion of the changes in Gnz_ProcessCacheUpdateQueryResponse - this function again adds the lock and unlock code.

I know there are a lot of people working feverishly to get a consistent exploit trigger in DNS.exe.  This of course is the first step in getting a working exploit.  I know that Greg Linares has a crash in dns.exe as well, though I don't know that it is reliable or the conditions around it.

I usually have some recommendations in my posts, so I'll try to part with a few here. If you aren't using recursion on your DNS servers, turn it off.  Of course, patch.  For future architecture decisions, I think this shows why we should not put DNS and AD on the same server.  A bug in DNS can lead to complete compromise of your DC.  As for detection, I need to look in some of my network logs to understand how common DNAME record responses are.  I don't think they are common, and if so, they may offer a detection method.  I would also suggest limiting outbound communications from your DNS/AD/*any* server - that way even if you are exploited you make the bad guy's job that much harder.