The Weakness of Windows Impersonation Model
 

Summary

1. Network Service account=92s context is elevated to LocalSystem.
2. A context of MS SQL service running as unique user account is
elevated up to LocalSystem.
3. Any service=92s context could be elevated to LocalSystem

There is an immanent risk to run network services as privileged
account, e.g. LocalSystem or Administrator. The threat is widely
accepted and recognized. However, most are not aware that nearly the
same risk is present for a service configured to run on behalf of
non-privileged account such as Network Service, Local Service or
unique user.


Technical Details

Security implications of impersonation are not new, but are not widely
recognized and understood. By definition, impersonation allows a
server application to replace (impersonate) its security context
(credentials) by context of client. In general, impersonation assumes
a server reduces its privileges but it also imposes a threat of
unauthorized privilege elevation.

The attack scenario is well known and understood. An attacker
terminates, pauses or crashes a privileged server application and
starts its own one with the same interface. It receives requests from
privileged client and impersonate. There were number of attacks
reported that have used this approach with named pipes [1, 2, 3].
However, the scope is not limited to named pipes. Any communication
channel that supports impersonation can be hijacked for privilege
elevation purposes, including LPC, RPC, DDE, COM, etc. Named pipe
interfaces are merely less opaque and easier to discover and exploit.

Provided threat of impersonation led to creating of a separate
privilege =96 =93Impersonate a client after authentication=94. Therefore,
since Windows XP only LocalSystem, Administrators and services have
this privilege by default [4] and can impersonate to client=92s
credentials. Regular users are not able to exploit impersonation
anymore, but services (special processes managed by Service Control
Manager) still can. The risk of services run as LocalSystem and
Administrators is recognized, however the threat of other accounts
used to run services is underestimated. Network Service, Local Service
and even unique user accounts used to run a service still allow
privilege elevation for intruder who successfully attacked a service.

There are two attack scenarios:
1) If a service does not impersonate highly privileged clients then an
attacker who breaks into such service can simulate communication
interface used by privileged services.
2) If a service happen to impersonate highly privileged clients then
attacker=92s task is easier, he needs just catch up privileged client
context during impersonation.

Windows XP and Windows 2003 use Network Service account to run
critical services such as Remote Procedure Call (RPC), which
impersonate privileged clients. As result, the second attack scenario
is possible to elevate a Network Service context to LocalSystem.
Additionally, Microsoft SQL Server 2000 service context is elevated
from unique user to LocalSystem. GentleSecurity provides demo tools
exercising the privilege elevation as part of GeSWall=92s evaluation procedure.

M. Howard and D. LeBlanc partly admit the risk of Network/Local
Service [4], quotation: =93Like LocalSystem, it has the benefit of
changing its own password (because it is basically a stripped-down
version of the LocalSystem account). One drawback to using this
account is the fact that several services use this account. If your
service gets breached, other services might also be breached.=94
However, impersonation threat is not mentioned. Besides this note, we
did not find any warning about using these accounts.


Conclusions

It must be clearly admitted and well understood that under certain
circumstances any service account context can be used by attacker to
elevate privileges. Therefore, actual move from LocalSystem to Network
Service, Local Service and unique user accounts does not mitigate the
risk in general. Unprivileged accounts for services do not reduce
privileges and the attack surface as advertised. A service implies the
threat of using high privileges, regardless account used.


Solution

GesWall=92s access control policy prevents privilege elevation attacks
as well as isolates privileged services precluding intrusions into the
rest of system.

Credits

Special thanks to 3APA3A for the help in the issue research.


References

[1] @Stake. Named Pipe Filename Local Privilege Escalation. 
http://www.securiteam.com/windowsntfocus/5BP012KAKI.html 
[2]  Maceo. Named Pipe Filename Local Privilege Escalation Exploit.
http://www.securityfocus.com/archive/1/329197 
[3]  Georgi Guninski. Elevation of privileges with debug registers on
Win2K. http://www.guninski.com/dr07.html 
[4]  M. Howard, D. LeBlanc. =93Writing Secure Code=94, Second Edition.


Vendor Status

The issue reported to Microsoft on April 30, 2006.


Copyright 2005-2006 =A9 GentleSecurity S.a.r.l.
http://www.gentlesecurity.com 
Permission granted to redistribute this paper unedited in electronic
form. No part of this paper may be reproduced, transmitted, or
translated in any form except electronic without the prior written
permission of GentleSecurity.
Information in this paper may change without notice and does not
represent a commitment on the part of GentleSecurity.