Bugtraq mailing list archives
Re: Re[2]: The Weakness of Windows Impersonation Model
From: Cesar <cesarc56 () yahoo com>
Date: Tue, 30 May 2006 17:06:15 -0700 (PDT)
Actually, I would say: "a process running as a service can impersonate almost any other running processes user accounts since you can force processes conect to your service using LPC. Cesar. --- "Brian L. Walche" <gsw () gentlesecurity com> wrote:
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.comHi Brian, I wrote a paper on this subject last year,"Snagging Security Tokens toElevate Privileges" (http://www.databasesecurity.com/dbsec-briefs.htm)afterTim Mullen and thrashed out a few details atBlackhat last year over a fewWhite Russians. The paper discusses the problem inthe context of databaseservers and examines the LogonUser() andAcceptSecurityContext() functions.I believe Longhorn/Vista will address many ofissues that currently affectimpersonation. Cheers, David Litchfield http://www.databasesecurity.com/ http://www.ngssoftware.com/----- Original Message ----- From: "Brian L. Walche" <gsw () gentlesecurity com> To: <bugtraq () securityfocus com> Sent: Tuesday, May 16, 2006 7:25 PM Subject: The Weakness of Windows ImpersonationModelThe Weakness of Windows Impersonation Model <http://www.gentlesecurity.com/04302006.html>Summary1. Network Service accounts context is elevatedto LocalSystem.2. A context of MS SQL service running as uniqueuser account iselevated up to LocalSystem. 3. Any services context could be elevated toLocalSystemThere is an immanent risk to run network servicesas privilegedaccount, e.g. LocalSystem or Administrator. Thethreat is widelyaccepted and recognized. However, most are notaware that nearly thesame risk is present for a service configured torun on behalf ofnon-privileged account such as Network Service,Local Service orunique user.Technical DetailsSecurity implications of impersonation are notnew, but are not widelyrecognized and understood. By definition,impersonation allows aserver application to replace (impersonate) itssecurity context(credentials) by context of client. In general,impersonation assumesa server reduces its privileges but it alsoimposes a threat ofunauthorized privilege elevation.The attack scenario is well known and understood.An attackerterminates, pauses or crashes a privileged serverapplication andstarts its own one with the same interface. Itreceives requests fromprivileged client and impersonate. There werenumber of attacksreported that have used this approach with namedpipes [1, 2, 3].However, the scope is not limited to named pipes.Any communicationchannel that supports impersonation can behijacked for privilegeelevation purposes, including LPC, RPC, DDE, COM,etc. Named pipeinterfaces are merely less opaque and easier todiscover and exploit.Provided threat of impersonation led to creatingof a separateprivilege Impersonate a client afterauthentication. Therefore,since Windows XP only LocalSystem, Administratorsand services havethis privilege by default [4] and can impersonateto clientscredentials. Regular users are not able to exploitimpersonationanymore, but services (special processes managedby Service ControlManager) still can. The risk of services run asLocalSystem andAdministrators is recognized, however the threatof other accountsused to run services is underestimated. NetworkService, Local Serviceand even unique user accounts used to run aservice still allowprivilege elevation for intruder who successfullyattacked a service.There are two attack scenarios: 1) If a service does not impersonate highlyprivileged clients then anattacker who breaks into such service can simulatecommunicationinterface used by privileged services. 2) If a service happen to impersonate highlyprivileged clients thenattackers task is easier, he needs just catch upprivileged clientcontext during impersonation.Windows XP and Windows 2003 use Network Serviceaccount to runcritical services such as Remote Procedure Call(RPC), whichimpersonate privileged clients. As result, thesecond attack scenariois possible to elevate a Network Service contextto LocalSystem.Additionally, Microsoft SQL Server 2000 servicecontext is elevatedfrom unique user to LocalSystem. GentleSecurityprovides demo toolsexercising the privilege elevation as part ofGeSWalls evaluationprocedure.M. Howard and D. LeBlanc partly admit the risk ofNetwork/LocalService [4], quotation: Like LocalSystem, it hasthe benefit ofchanging its own password (because it is basicallya stripped-downversion of the LocalSystem account). One drawbackto using thisaccount is the fact that several services use thisaccount. If yourservice gets breached, other services might alsobe breached.However, impersonation threat is not mentioned.Besides this note, wedid not find any warning about using theseaccounts.ConclusionsIt must be clearly admitted and well understoodthat under certaincircumstances any service account context can beused by attacker toelevate privileges. Therefore, actual move fromLocalSystem to NetworkService, Local Service and unique user accountsdoes not mitigate the
=== message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Current thread:
- The Weakness of Windows Impersonation Model Brian L. Walche (May 16)
- Re: The Weakness of Windows Impersonation Model David Litchfield (May 17)
- Re[2]: The Weakness of Windows Impersonation Model Brian L. Walche (May 17)
- Re[2]: The Weakness of Windows Impersonation Model Brian L. Walche (May 17)
- Re: Re[2]: The Weakness of Windows Impersonation Model Cesar (May 31)
- Re: The Weakness of Windows Impersonation Model David Litchfield (May 17)