As you can see from the April 2009 release summary, we addressed the Token Kidnapping issue with bulletin MS09-012. This issue allowed an attacker to gain full control of a server if the attacker can first run malicious code on the server as a lesser privileged user.
This issue was originally presented by Cesar Cerrudo in March of 2008 at Hack in the Box (Dubai) 2008. In April of 2008, we released an advisory to inform customers of actions they could take to protect themselves. We also updated the advisory in October of 2008, alerting customers to the availability of proof-of-concept code that demonstrates how to attack systems using token kidnapping techniques. Today we’ve released an update that protects from these issues without having to deploy workarounds. This release has been a long time in the making, so I wanted to take a moment and provide some insight into what it took to resolve this issue for customers.
First, what is Token Kidnapping? This is an elevation of privilege vulnerability that could allow an attacker to go from authenticated user to LocalSystem privileges. An attacker can escalate their privileges on a system if they can control the SeImpersonatePrivilege token. An attacker would need to be executing code in the context of a Windows service to use this exploit. For a more detailed look at the issue, refer to the SRD blog found here.
This case presented some interesting challenges in preparing the update to address the issue. First, there are two updates included in this bulletin. The first update addresses service isolation, while the second addresses processes running as service accounts. In order to secure these items, we took the work we did in Windows Vista to provide additional service hardening and implemented it in older operating systems like Windows XP, and Windows Server 2003. These changes are low-level and deeply engrained in the OS. When making these types of changes, many of the applications that have been written in the 5 to 10 years since the OS was released could be impacted as we are changing infrastructure. Typically, we only change code to this degree in a service pack release to ensure it receives the proper level of testing.
However, given the security risk, and even though we provided workarounds, we wanted to secure customers automatically. So we made the changes, and then did extensive testing to ensure this update is high-quality and did not impact existing implementations. For this bulletin, we ran over different test scenarios. We also needed to ensure we were not breaking 3rd-party applications by introducing this change. As a result, application compatibility tests were also run. In addition to this testing, we selected over 1,000 systems within Microsoft to test the update before we released, and some key customers signed NDAs to do even more testing in their lab environments to make sure we didn’t break Line-of-Business application scenarios. One thing we did notice is that some 3rd-party applications may need to be updated to receive the same security benefits provides by this update. To facilitate this, the update also provides an infrastructure to 3rd-parties to isolate and secure their services. In Windows XP and Windows Server 2003, all processes running under the context of a single account will have full control over each other. This update provides 3rd-parties the ability to isolate and secure their services that hold SYSTEM token and run under the NetworkService or LocalService accounts. For more information on the usage of this registry key, see Microsoft Knowledge Base Article 956572.
While this update took some time to complete, our hope is that the majority of customers are protected either through the guidance we released a year ago or the update we released today. It is never an easy process to bring infrastructure from a newer OS to an older OS, but we considered this an important enough issue to do so. As you would expect, it wasn’t always an easy road, so I would like to thank all of the folks internally and externally that helped bring this update to the worldwide community. Specifically, I’d like to thank the following people who were key contributors in bringing this update to the world:
- Cesar Cerrudo, Argeniss Information Security
- Bruce Dang, MSRC Engineering
- Nick Finco, MSRC Engineering
- Anoop KV, Windows Serviceability
- Vikas Mittal, Windows Serviceability
And special thanks go out to all of the many developers and testers who help made this release possible.
Links to related articles:
Service isolation explanation, SRD blog entry, Jonathan Ness, October, 2008