 |
| Follow me on twitter! |
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.
Have a great week!
Posts
9 comments:
Good article, thank you!
it totally depends on what you're planning to do next once you have ownership of the machine, no? if you plan on treating the box as your client machine for you to manually perform tasks with then administrator will be more useful to you. if you just need a slice of the processor for a bit, perhaps localsystem would be a little quieter on a box that ur admins seldom auth to. it's all context sir...context.
he said that you can still run things as SYSTEM when breaking in as admin, so it doesn't conflict with his saying. Also, on which occasion you would want to run something as SYSTEM to make it more quite?! What makes you think someone will be less suspicious of a process running as SYSTEM instead of Admin.
On which occasions a SYSTEM is actually required for after-pwnning process?! can you think of any?
tasklist /v have you ever used it? ever been on a box that only has services on it? unix basics my friend. welcome.
also, ever needed anything from HKLM/Security before?
http://msdn.microsoft.com/en-us/library/ms684190(VS.85).aspx
and actually, there's even an msdn article on it for you.
no doubt you've read it already, but it's just shocking that the differences between the usefulness of both accounts regarding various situations is not apparent to you.
good luck in your future endeavors.
Hey there!
Thanks for your input guys,
"tasklist /v have you ever used it? ever been on a box that only has services on it? unix basics my friend. welcome."
tasklist /v? yes, you can use it as admin as-well. It might not write all the details, but if you're desperate to view ALL verbose details you can use the API to run commands as built in in your trojan with SYSTEM token, or use AT command to run it and see the output.
example :
at (time) cmd /c tasklist /v ^> c:\out.txt
should do the work just fine (if you want to enumerate the windows titles of ALL programs).
What is wrong with a computer with only services on it? As administrator you can run services and register them using the SCM (services-control-manager), you don't actually need to elevate permissions for it, admin is enough in this case.
Unix basics? sorry, I didn't understand that.
The whole post is on Windows. I (hope) know the *nix basics and Linux is my primary OS (for the last 8 years) but I just don't think I understood what you mean, I'd be happy if you could have explained. :(.
HKLM/Security? That's a good point actually. Yet again, reg export in AT can be very useful in this case (or running reg.exe with SYSTEM token).
example :
at (time) reg save HKLM\Security c:\sec.bin
regarding the msdn post, there's nothing relating to this blog-post...
I think you've understood the post wrong, so please re-read it to get my point, or here's my short summary :
The whole thing I was trying to say in this post is that Administrator is not "less strong" than SYSTEM, since you can elevate back and fourth from Admin to SYSTEM relatively easy, and you should pick the account which is better for you in most cases. That's my whole point in this blog post. You can still see people saying : "SYSTEM is much more stronger than admin" which is a mistake IMO, you can hack to a box as admin and still register your payload as SYSTEM if you want to look more hidden.
Thanks for your points. Feel free to contact me any time if you got any questions or you still didn't fully understood me.
itz2000 [_@_] gmail . com
this is long dead, but tasklist /v and unix basics was attempting to be synonymous with the unix habit of doing a 'w' or 'ps' to list all pid's with owners. if you're sitting on a mailserver because you just popped something, and your exp failed (so you broke something on the server). then an admin logs in and then checks the process list..
you mentioned you were "inspired" by a trojan, typically trojans intend to setup, and then eventually idle. if there's 1 idling process on your server, owned by an administrator account, the avg admin that knows how to use pslist will think "what the fuck?" when he sees it. stay professional, hacker. :D
Hello there,
Yes, I agree with your post, in that case you (as attacker) wouldn't want to look different, and would register your trojan like other computer's processes. no need to look different on purpose, so that's a good point.
Yes, That was a lame trojan who had copied code from somewhere else and tried to run privilege escalation even if he was Admin already. Running that would be good if you got 100% working, stable, attack. But he didn't. That's why in that trojan's case it would have been better if the trojan would have checked which user he's currently running as and only if he has no privileges than run his code.
Thanks for your thoughts,
Zuk.
Post a Comment