WARNING – POSSIBLE IMMATURE CURSING AHEAD. OK *ACTUAL* IMMATURE CURSING, WTF…

Well, apparently it was a real popular thing to give away a couple of 0day exploits, so more 0day is being given away! Again this is from the good old days at BindView when your buddy SN was on the RAZOR team.

[private]
There should be two like last time, so I will give away the first one real quick. I found this from a TODO list of mine from August of 2003. It simply reads “buffer overflow in netware smb authentication” and a few lines down says “large user name in nw smb auth, dos only?” That is all I have to go on. If I were really inspired I guess I could get out my box of drink coasters, erm sorry my box of old software no one ever uses, set up a NetWare server in a VM circa 2003 and start whacking away. But since I don’t want to terrorize Novell’s four remaining customers, I will let bygones be bygones.

No that one is rather lame, so here is a better one…

Todd Sabin. You know him, you love him. PWDump2 was his baby and laid the groundwork for numerous other hash dumping routines. He is a mad coder and knows Windows stuff like nobody’s business. If you’ve ever used Wireshark and looked at Windows DCE RPC decoded, you are looking at Todd’s handywork. Interesting Todd fact – instead of using some reverse engineering tool that performed a disassembly a la IDA Pro, Todd wrote his own. In LISP. The fucker is nuts.

Well Todd found a number of security issues while he was working at BindView, all properly reported to Microsoft. However Microsoft didn’t always issue a patch or fix Todd’s issues. This is one of those issues that Microsoft eventually patched but didn’t tell anybody about.

The bug, reported to Microsoft in the summer of 2004, impacted NT, 2000, XP, and 2003 versions of Windows. It seems a remote attacker could hijack RPC session handles and use them with no further authentication. Use an admin’s RPC session handle and you could have some fun with altering all kinds of things like user account permissions, registry keys, etc. You get the idea. Bad stuff.

RPC servers use something called “context handles” to represent handles to objects. So if an admin wants to change something, they get the context handle for that object they want changed, the RPC server impersonates the requester and checks permissions. The permissions are recorded with the handle, and later in the conversation permissions for the handle are checked as it does its thing. So you can see where this is headed.

Ironic part – on page 271-272 of “Writing Secure Code” (1st edition, written by very bright MS employees) it states in the section “Don’t Rely on Context Handles for Access Checks” to well, not rely on context handles for access checks, which is exactly what this flaw is all about.

So here are the steps to be evil:

  • Sniff the network between the victim machine and the administrator, waiting for the administrator to do something to an object the attacker wants to do themselves. Social engineering could help speed this up.
  • When the admin performs the RPC bind, the attacker performs a bind with the same association group as the admin.
  • When the admin does the RPC call to open the handle, the attacker spoofs a TCP reset against the admin’s machine to prevent the handle from being closed, and records the context handle the admin had requested to use against that object in an evil fashion.
  • Game over, man, game over!

Sweet, huh? Yeah I know, I think Todd fucking rocks too.

Oh sure you say, TCP connection hijacking could do the same thing. Well SMB signing defeats those types of attacks, but not this one. Bitchin’. The final sweetness is that all the attacker needs is minimally anonymous access.

So this sounds serious. It was, Microsoft said it was very serious to them. However (there always seems to be a however) this would require a massive amount of code changes — tons of subsystems would have to be touched. So Microsoft decided not to go the individual patch route. Like last time, Microsoft knew BindView RAZOR did not release vuln info unless it had patch info from the vendor.

I asked Todd about this recently and he told me Microsoft apparently did patch things, but no one was told about this. Todd’s guess was it went into XP SP2, some service pack for 2003, and probably some rollup patch for 2000. So XP and 2003 are good, 2000 possibly good, and NT is more than likely as fucked as the people who are still running a non-supported OS. You’ve gotta love those silent patches!

Ok, in Microsoft’s defense here, it probably did impact a ton of various servers and subsystems, and quite frankly there could have been other interesting examples of similar misplaced trust issues to be found in these same subsystems that Microsoft didn’t want people finding. So they fixed it and did not tell anyone (shame on you MS), but they at least shoved it into service packs which they knew would get loaded up for security reasons. Plus, all the reverse engineers are less likely to do binary diff analysis against pieces from a service pack than an individual patch, since there would be multiple security and even non-security updates to the various components, and it would be really fucked up to start looking for needles in that haystack. Granted, they now have at least one idea on where to look…

If you run into Todd somewhere, buy him a beer. He deserves it.

-SN
[/private]