Details of privilege escalation hole in WindowsApril 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.
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
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
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