Escalating from Administrator to SYSTEM
Running code in the context of SYSTEM is desirable to perform certain tasks. While running as an administrator, it is possible - by design - to be able to run arbitrary code in the context of SYSTEM. There are numerous means by which this "privilege escalation" can be accomplished; I will document a few in later posts, but first I'll provide some background.
By administrator, I mean any context which includes the BUILTIN\Administrators group (S-1-5-44) group. Furthemore, this group SID should be enabled and should not be deny-only. Programmatically, see the documentation for GetTokenInformation, TOKEN_GROUPS, and SE_GROUP_ENABLED and SE_GROUP_USE_FOR_DENY_ONLY on MSDN.
Additionally, I mean a user context which includes the privileges assigned to the administrators local group as part of a default Windows install. Most notably, I mean the SeIncreaseQuotaPrivilege, SeTakeOwnershipPrivilege, SeRestorePrivilege, SeDebugPrivilege and SeImpersonatePrivilege. For more information, see the documenation for GetTokenInformation, TOKEN_PRIVILEGES on MSDN, Default User Accounts and Groups on TechNet, and the "NT Defined Privileges" section in winnt.h.
If you are not familiar with some or all of the concepts above, you'll find that the normal case is that any member of the Administrators group will work just fine. For example, if you log in using the "500" account (by default, named administrator) you'll be able to "escalate" to SYSTEM using the techniques described.
There are numerous examples of what can be easily done in the context of SYSTEM that is much more difficult to do (and impossible to do while avoiding race conditions) while running in a non-SYSTEM administrative context. An example is reading the famed SAM and SECURITY keys in the registry.
Another example is to easily gain certain privileges which are not, by default, assigned to administrators but are assigned to SYSTEM, such as the SeTcbPrivilege and the SeAssignPrimaryTokenPrivilege. While an administrator can assign these privileges to any account, they do not take effect (are not reflected in the tokens of processes running in the relevent user context) until a new logon session is created. Take a look at LsaAddAccountRights and "How to Manage User Privileges Programmatially in Windows NT" in the KB.
Understanding how to move from Administrator to SYSTEM, and, more importantly, why this works is a great way to understand the Windows security model, especially concepts such as security descriptors, DACLs, SIDs, ACEs, groups, privileges, logon sessions, and tokens. Over the next few posts, I'll provide more details (and, in some cases, code) to help you do this.
By administrator, I mean any context which includes the BUILTIN\Administrators group (S-1-5-44) group. Furthemore, this group SID should be enabled and should not be deny-only. Programmatically, see the documentation for GetTokenInformation, TOKEN_GROUPS, and SE_GROUP_ENABLED and SE_GROUP_USE_FOR_DENY_ONLY on MSDN.
Additionally, I mean a user context which includes the privileges assigned to the administrators local group as part of a default Windows install. Most notably, I mean the SeIncreaseQuotaPrivilege, SeTakeOwnershipPrivilege, SeRestorePrivilege, SeDebugPrivilege and SeImpersonatePrivilege. For more information, see the documenation for GetTokenInformation, TOKEN_PRIVILEGES on MSDN, Default User Accounts and Groups on TechNet, and the "NT Defined Privileges" section in winnt.h.
If you are not familiar with some or all of the concepts above, you'll find that the normal case is that any member of the Administrators group will work just fine. For example, if you log in using the "500" account (by default, named administrator) you'll be able to "escalate" to SYSTEM using the techniques described.
There are numerous examples of what can be easily done in the context of SYSTEM that is much more difficult to do (and impossible to do while avoiding race conditions) while running in a non-SYSTEM administrative context. An example is reading the famed SAM and SECURITY keys in the registry.
Another example is to easily gain certain privileges which are not, by default, assigned to administrators but are assigned to SYSTEM, such as the SeTcbPrivilege and the SeAssignPrimaryTokenPrivilege. While an administrator can assign these privileges to any account, they do not take effect (are not reflected in the tokens of processes running in the relevent user context) until a new logon session is created. Take a look at LsaAddAccountRights and "How to Manage User Privileges Programmatially in Windows NT" in the KB.
Understanding how to move from Administrator to SYSTEM, and, more importantly, why this works is a great way to understand the Windows security model, especially concepts such as security descriptors, DACLs, SIDs, ACEs, groups, privileges, logon sessions, and tokens. Over the next few posts, I'll provide more details (and, in some cases, code) to help you do this.
posted by sdl529 @ 7:28 PM
0 Comments:
Post a Comment
<< Home