Details of privilege escalation hole in Windows

April 21, 2008 – 6:33 AM

In a security alert last week, Microsoft reported a vulnerability which allows local users and users signed on with access to an Internet Information Server (IIS) or MS SQL server to escalate their privileges. Server operators such as hosting providers who allow user code to be executed, for example on IIS or SQL servers, were rated as particularly vulnerable by Microsoft.

Cesar Cerrudo of security service provider Argeniss discovered the vulnerability and presented initial details at the HITBSecConf2008 security conference.

The vulnerability is due to a process running as a service being able to adopt the security token of another process. Windows uses this token to record the privileges of a process, for example the user account in which the process is running. One of the privileges in this security token, SeImpersonatePrivilege, allows a process to execute a thread at a different security level than its parent process.

Under Windows XP and Server 2003, services can run in the Local Service, Network Service or Local System user accounts, but only Local System allows unrestricted system access. The services are not able to directly access each other. According to Cerrudo, however, services in both operating systems have the right to modify the access restrictions in the service’s Access Control Lists (ACLs) (WRITE_DAC), allowing all the services to adopt the security tokens of other services.

As an example, Cerrudo presented the Microsoft Distributed Transaction Coordinator (MSDTC) service, in which a service can obtain the security token which grants impersonation privileges to Network Service by calling DtcGetTransactionManagerEx(). This token allows the process to access the threads of the Remote Procedure Call System Services (RPCSS) service. These threads can use their security token to obtain Local System privileges.

Microsoft put tighter security on these services under Windows Vista and Server 2008, where the services run at least privilege level, security tokens are write-protected and every service has its own security ID. According to Cerrudo’s presentation, however, the services may distribute work across threads from “Thread Pools”, which can in turn access other threads running within the same user account. This allows attackers to bypass the service’s security ID. In addition, only some of the services’ security tokens are write-protected.

Cerrudo explains that in Windows Vista and Server 2008, services like WMI (WmiPrvSE.exe) are unprotected and have the right to access Local System. A crafted service would need to use WMI functions, patch the CloseHandle and OpenThreadToken functions and then test all the token handles until the Local System token is found.

Cerrudo has a program that demonstrate how a DLL from an ASP.NET web page is injected into the RPCSS service running in the Network Service account, and how the service then injects the DLL into the IIS service running at SYSTEM privilege level. Cerrudo only plans to release the code once Microsoft has patched the hole. It remains unclear, however, when Microsoft will do so.

Source: Heise Security