Administrator account VS. SYSTEM account
I've encountered one trojan who ran already as Administrator and tried to run privilege escalation exploit against himself, so he can run as SYSTEM.
This is what made me write this post :
Let's say there are 2 programs vulnerable to remote-code-execution bug.
1. One is running as SYSTEM
2. One is running as Administrator.
Little pre-post-information regarding exploitation : If you run your exploit against a process which runs as Administrator, Your payload will run as Administrator. If you run it against SYSTEM account your payload will run as SYSTEM account.
Which one you would want to exploit more?
95% of security people, will say : "the SYSTEM one, off-course SYSTEM is much stronger than admin, it's the strongest user in the OS".
I'd say : it doesn't matter and I might slightly want to run as Admin instead of System. Why? This is what this blog-post is all about.
First of all, Admin leads to SYSTEM, in relatively easy to use API. It's legally authorized by the OS, and Admin has the rights to impersonate as SYSTEM. Meaning admin can execute his payloads as SYSTEM.
Do you remember the AT (c:\windows\system32\at.exe) command? Its object is to run things through the Scheduler Service (as SYSTEM). But wait, how can it run things as SYSTEM? Does it work for every user in the OS? even the non-administrative users? No.
AT command only works for administrative users (Local Admin, Domain admins, or SYSTEM account himself). So it means that any administrative user can run command as SYSTEM. Let's see what AT.exe does :
Quick reverse engineering will show us which function AT uses.
This is what made me write this post :
Let's say there are 2 programs vulnerable to remote-code-execution bug.
1. One is running as SYSTEM
2. One is running as Administrator.
Little pre-post-information regarding exploitation : If you run your exploit against a process which runs as Administrator, Your payload will run as Administrator. If you run it against SYSTEM account your payload will run as SYSTEM account.
Which one you would want to exploit more?
95% of security people, will say : "the SYSTEM one, off-course SYSTEM is much stronger than admin, it's the strongest user in the OS".
I'd say : it doesn't matter and I might slightly want to run as Admin instead of System. Why? This is what this blog-post is all about.
First of all, Admin leads to SYSTEM, in relatively easy to use API. It's legally authorized by the OS, and Admin has the rights to impersonate as SYSTEM. Meaning admin can execute his payloads as SYSTEM.
Do you remember the AT (c:\windows\system32\at.exe) command? Its object is to run things through the Scheduler Service (as SYSTEM). But wait, how can it run things as SYSTEM? Does it work for every user in the OS? even the non-administrative users? No.
AT command only works for administrative users (Local Admin, Domain admins, or SYSTEM account himself). So it means that any administrative user can run command as SYSTEM. Let's see what AT.exe does :
Quick reverse engineering will show us which function AT uses.
The function AT uses to register in the scheduler service would be : NetScheduleJobAdd.
Does it mean we can add jobs our self to run on localhost (127.0.0.1) as SYSTEM? Yes (if you have rights, which any local/domain Administrator has).
Didn't check it on the schtasks.exe, but it's probably same thing or other function, but the point is, Admin leads the way to SYSTEM.
When you think about it, you need SYSTEM account in several occasions only, but when do you need administrator account?
Well, Did it occur to you that you have hacked to a SYSTEM account in a pentest and wanted to get more information regarding the user who runs this computer shares, the user folder mappings and stuff like that?
If it did, than you know it would be best to use Impersonation to Admin *EVEN* if you're already running as SYSTEM ("Downgrading your privileges") account and run a thread or another process as Admin.
If you would do : net use/subst/other commands as SYSTEM you wouldn't see the same results the Admin gets for the same commands (because of session separation).
Also, You'd be able to view remote shares as Admin (if the user running this computer has remote shares he sees), you'll be able to view them and have the same rights to them on a remote computer (without knowing/changing the Admin's password)! As SYSTEM you wouldn't have it. At all. bummer.
There are very few times when I really need the SYSTEM account so I guess I'll want to be Admin-user in the first place and execute my shell again under SYSTEM account (only if needed), instead of running SYSTEM account and execute my shell as Admin if I needed.
How do I createprocess under SYSTEM if I run as admin? Just get the Systemtoken, and impersonate to it.
What is impersonation?
Impersonation is the ability of a thread to
execute using different security information than
the process that owns the thread
– Threads impersonate to run code under another user
account, ACL checks are done against the
impersonated users
– Impersonation can only be done by processes
with the following privilege:
-...(SeImpersonatePrivilege)
–When a thread impersonates it has an associated
impersonation token
An access token is an object that describes the
security context of a process or thread
– It includes the identity and privileges of the user
account associated with the process or thread
– They can be Primary or Impersonation tokens
• Primary ones are those that are assigned to
processes
• Impersonation ones are those that can be get
when impersonation occurs
– Four impersonation levels: SecurityAnonymous,
SecurityIdentity, SecurityImpersonation,
SecurityDelegation
Windows XP & 2003
– An APC can be submitted to a thread
• QueueUserAPC() can be called with
ImpersonateSelf() as parameter
• Thread starts to impersonate service account
• Impersonation token is get by OpenThreadToken()
• Token is used to access the process
• Token handles are brute forced in target process
until SYSTEM token is found
• SYSTEM token is used to run code
If a user can impersonate then game is over (my remark : every Admin user can impersonate to SYSTEM, which is the point of this post).
• User can execute code as SYSTEM [my remark] which means ADMIN can *always* execute code as SYSTEM.
Impersonate/token information is taken from : http://www.argeniss.com/research/TokenKidnapping.pdf
I hope you understand now why SYSTEM isn't really stronger than Admin. And the next time someone tries to run privilege escalation if he's an Admin already, just explain to him that he doesn't have to do so to become system and he can use legit API to run as SYSTEM.
Source:imthezuk
Category Article Vulnerability
