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@xxxxxxxxxxxxxxxxxx> 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.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@xxxxxxxxxxxxxxxxxx> > > To: <bugtraq@xxxxxxxxxxxxxxxxx> > > 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 > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
