13 comments:

Hi, I've been following your blog for a long now. I love to learn this subtle things that can pwn you.

However, 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.

Utilman.exe can be launched via Ctrl + U or the Accessibility button on Vista+'s logon screen.

One 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 :)

Windows 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.

The 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.

Good 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.

@Mario VilasAre 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.