Message-ID: <256303967.20060517104610@gentlesecurity.com>
Date: Wed, 17 May 2006 10:46:10 +0200
From: "Brian L. Walche" <gsw@...tlesecurity.com>
To: "David Litchfield" <davidl@...software.com>,
	bugtraq@...urityfocus.com
Subject: Re[2]: The Weakness of Windows Impersonation Model



Just one important note regarding Database Security Brief:
http://www.databasesecurity.com/dbsec/db-sec-tokens.pdf
"Why should I never logon to a Windows database server if I've got
admin privileges?"

We describe a little different problem for MS SQL. MS SQL gets
privileged context on its own from MSDTC. So it doesn't matter if
administrator was logged into database or not.

MS SQL service's default state after its start is sufficient. A
suggested policy to refrain admin logons will not protect for MSSQL.

Additionally, to exploit this usually you no need a "sleeper" that
waits for privileged client to logon. Impersonating processes often
keep their impersonation tokens for a while. In order to exploit an
attacker needs just search for token handles. The list of handles can
be retrieved through Windows native API.


Brian L. Walche,
http://www.gentlesecurity.com

> Hi Brian,
> I wrote a paper on this subject last year, "Snagging Security Tokens to
> Elevate Privileges"
> (http://www.databasesecurity.com/dbsec-briefs.htm) after 
> Tim Mullen and thrashed out a few details at Blackhat last year over a few
> White Russians. The paper discusses the problem in the context of database
> servers and examines the LogonUser() and AcceptSecurityContext() functions.
> I believe Longhorn/Vista will address many of issues that currently affect
> impersonation.
> Cheers,
> David Litchfield
> http://www.databasesecurity.com/
> http://www.ngssoftware.com/



> ----- Original Message ----- 
> From: "Brian L. Walche" <gsw@...tlesecurity.com>
> To: <bugtraq@...urityfocus.com>
> Sent: Tuesday, May 16, 2006 7:25 PM
> Subject: The Weakness of Windows Impersonation Model


> The Weakness of Windows Impersonation Model
> <http://www.gentlesecurity.com/04302006.html>

> Summary

> 1. Network Service account’s 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’s 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 – “Impersonate a client after authentication”. Therefore,
> since Windows XP only LocalSystem, Administrators and services have
> this privilege by default [4] and can impersonate to client’s
> 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’s 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’s evaluation 
> procedure.

> M. Howard and D. LeBlanc partly admit the risk of Network/Local
> Service [4], quotation: “Like 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.”
> 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’s 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. “Writing Secure Code”, Second Edition.


> Vendor Status

> The issue reported to Microsoft on April 30, 2006.


> Copyright 2005-2006 © 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.

Powered by blists - more mailing lists