Token Abuse
2008-04-14 © MWR InfoSecurity Page 10 of 29
Security Implications of Windows Access Tokens – A Penetration Tester’s Guide
5 Token Abuse
During the normal operation of a system, there will be tokens of some variety present
depending on the function of the server and its current usage environment. If the system is
compromised then it may be possible to achieve some form of privilege escalation by
utilising these tokens, depending on the level of access that has been obtained to the system.
Such escalation would normally be divided into two main forms: Domain Privilege Escalation
and Local Privilege Escalation.
5.1 Domain Privilege Escalation
Domain Privilege Escalation refers to the ability to use a Delegate token to access other
systems, which may otherwise be secure from direct attack. This is possible because Delegate
tokens contain authentication credentials and so can be used to access external systems for
which those credentials are valid.
In order to perform this type of attack, it is usually necessary to have administrative privileges
on the compromised system. This is because impersonating a token requires the
“SeImpersonate” privilege, as of Windows XP SP2, Windows 2003 and Windows 2000 SP4;
additionally, Delegate tokens are normally the result of interactive logins and so
administrative access is required in order to access the tokens present in all user processes on
the system. Other privileges may also be required (such as “SeAssignPrimaryTokenPrivilege”
and “SeCreateTokenPrivilege”) depending on the specific post-exploitation task performed.
There are, however, some exceptions to this. For example, if an attacker were to compromise
a service account that was trusted for delegation then they may be able to perform this attack,
since services are normally given the “SeImpersonate” privilege. Additionally, on systems
before “SeImpersonate” was introduced it may be possible to perform this attack from a low
privileged user account under certain circumstances.
A good example of a use case for this type of attack would be as part of compromising a
critical database server. If an attacker were unable to compromise the database server directly
then they could turn their attention to the DBA’s workstation, since their user account will
often have legitimate access to the database servers themselves. If they successfully
compromised the workstation then they could use the tokens present to access the database
server.
5.2 Local Privilege Escalation
Under some circumstances, tokens can enable local privilege escalation. This is most likely to
occur if an attacker has compromised a low privileged service. Services that allow clients to
connect via Windows authentication will normally gain access to an Impersonate token for
the client. This would normally be used by the thread serving the client to impersonate the
client’s security context. If the connecting client was an administrator then the attacker could
use this token to escalate their privileges on the system to gain administrative access.
A good example of this would be if an attacker had compromised an instance of Microsoft
SQL Server running as a low privileged service account. If a DBA, who was a local
administrator of the system, connected to SQL Server via Windows authentication then the
attacker could use his token to gain administrative control of the server [8]. This is because
his token would be kept within SQL Server’s process address space.