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.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@gentlesecurity.com>
> > To: <bugtraq@securityfocus.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
>
=== message truncated ===


__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com