Microsoft (Belatedly) Admits to Windows Server 2008 Token Kidnapping
[[ UPDATE: Here are the slides from Cerrudo's HiTB talk (.pdf) that prompted Microsoft's advisory. At the company's request, Cerrudo has opted not to release exploit code. ]]
Last month, when I wrote about hacker Cesar Cerrudo's (left) plans to punch holes in the security model of Microsoft's brand-new Windows Server 2008, Redmond officials pinged me to stress that his presentation "describes design issues and does not describe a new vulnerability."
Imagine my surprise this morning to see this Microsoft pre-patch security advisory confirming "new public reports of a vulnerability which could allow elevation of privilege from authenticated user to LocalSystem" on Windows XP SP2 and all supported versions and editions of Windows Server 2003, Windows Vista and Windows Server 2008.
The language from Cerrudo's talk -- which was presented at the Hack in the Box conference this week -- and Microsoft's advisory sounded very much the same, so I contacted Microsoft again to verify that it's indeed the same issue.
The response, via e-mail (it's become really hard to get someone from the MSRC on the phone):
Yes. The vulnerability addressed in Security Advisory 951306 is the same vulnerability discussed by Cesar Cerrudo at Hack-in-the-Box.
Microsoft's initial investigation was based on information Cesar Cerrudo provided at the time and led the company to conclude this was not a vulnerability. However, Microsoft continued working with Cerrudo and received additional details after they were presented publicly at Hack-in-the-Box. Based on the additional information, Microsoft was able to determine that this is a vulnerability.
Microsoft is working with Cerrudo to investigate further into this vulnerability to ensure the protection of customers.
Two takeaways -- good and bad -- when it comes to Microsoft's responsiveness to security issues.
The bad first: Cerrudo publicly warned about this on March 24, 2008, and, based on Microsoft's earlier response, it's clear they had some advance information on the issue. The attempt to downplay the risk as "design issues" and "not a vulnerability" suggested that this was not something that would be fixed until a future service pack. Not good enough. Microsoft's emergence as a trend-setter on software security was built on a genuine effort to get to the bottom of every flaw warning, so I'm left to wonder why it took Cerrudo going public at a security conference for Microsoft to recognize that this is indeed a serious security vulnerability.
Last month, Microsoft claimed that Cerrudo's presentation simply described methods to elevate from a NetworkService (NS) account to a LocalSystem (SY) account. NetworkService (NS) and LocalService (LS) accounts are trusted accounts, and should be treated as Administrator equivalents.
The presentation does not describe methods for an attacker to gain access to these trusted accounts.
When did the bar for a security vulnerability depend on the bug finder's description of attack methods? Isn't that the job of the SWI team? Isn't that a key part of the SDL (Security Development Lifecycle) that helped to position Windows Server 2008 as -- Microsoft's words -- "the most secure Windows Server to date"?
Now, the good: Better late than never. The last time I wrote about Microsoft downplaying the severity of a bug and pushing off a patch until a future service pack, the story turned into a big embarrassment. After more than a year of sitting on the flaw report, Microsoft waited until the public release of exploit code to determine that this was something that needed fixing urgently.
This time around, the company is responding much faster by actually talking to Cerrudo after his HiTB presentation and making the determination that a formal security advisory is necessary. This time around, Microsoft will issue a patch with fixes. Win-win for everyone.
Which brings us to the nitty-gritty of today's advisory, via Symantec's DeepSight threat monitoring system:
Specifically, specially crafted code running in the context of the NetworkService or LocalService may gain access to resources in processes that run with the same privileges (NetworkService or LocalService) but can elevate their privileges to LocalSystem. This results in any process that runs as the NetworkService or LocalService being able to gain elevated privileges.
Successful exploits require specially crafted code to run in an authenticated context. This can be achieved by using one of the following reported vectors:
1. ISAPI filters and extensions or fully trusted ASP.Net code in IIS.
2. SQL Server with users that have administrative privileges to load and run code.
3. Any process with SeImpersonatePrivilege that loads and runs user-provided code, by acquiring a NetworkService token from the Microsoft Distributed Transaction Coordinator (MSDTC) service.
Other attack vectors may also be possible.
In the absence of a patch, affected users should pay special attention to the Suggested Actions > Workarounds section of Microsoft's advisory.