"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
