Windows 7 ‘Startup Repair’ Authentication Bypass

Long time no see ....

So, you know those 'how to hack your school computer' videos you sometimes come across on YouTube? You know the ones; they usually show some kid replacing the Windows sticky keys binary with a cmd.exe and then calling it a hack when he gets a shell to pop up on the login screen by pressing shift five times - even though you need to be an admin to do that in the first place! *sighs*. Well here's another way of using a similar technique except... It doesn't require admin privileges so it is actually useful in certain situations. Even better, almost every windows 7 host is vulnerable to this.

Firstly, I take no credit at all for this, as this issue has been around and known about for many years now, but I've decided to write it up here because a) I've not written anything on this blog for years and b) There's actually not as much information about this issue on the internet as you might think.

It's a trick I find handy when doing build reviews and the client has locked down the BIOS to prevent bootable media. Side-loading the disk is an option of course, but it's not something many would bother with during a standard test - and ripping the back off a client's workstation is probably not the most realistic way of demonstrating an insider threat. It's also yet another reason why someone with physical access (without Full Disk Encryption) has already won.

Basically, this only works on Windows 7 afaik  update:Windows 7 and 10, and it serves as a way to gain full privileges on a system without needing to know the password. It involves forcing the windows “Error Recovery” menu and then taking advantage of a 'breakout' within the privacy statement at the end of the startup repair wizard. This allows access to Notepad and Windows Explorer which can then be used to replace the sticky keys binaries and if all goes well, give yourself a system shell at the login screen.

You get the idea, so let's get started....

Windows 7 has two methods to recover the system should it have any problems booting. There’s the “Repair Your Computer” option you can see within the F8 advanced boot options menu:

And then there’s the “Startup Repair” option you get when Windows thinks it has a problem starting:

The wizards both look very similar and both let you repair the startup files or recover your computer; however, there’s one crucial difference: "Startup Repair" doesn’t require the local administrator password to run, and this is the one we're going to abuse.

To get to the “error recovery” menu we need to fool the host into thinking it has a problem starting. The safest way to do this is to boot up the machine and repeatedly press F8 until you see the boot options screen. From here choose “start windows normally” then immediately press ctrl-alt-del to restart. The target will then reboot into the correct options screen above and you will be greeted with the “Launch Startup Repair” option. Once you have chosen this, you will see a prompt giving you a choice to use the System Restore wizard. We don't want this so click cancel:

Windows will then launch into the startup repair wizard to look for reasons why it couldn’t boot. This can take around 5-10 minutes so be patient.

If the attack was successful you will see the following screen, if not then you will have to start over:

Click to expand the problem details dialog and navigate to the bottom where you will see a link to a text file:

 

Clicking on this will open Notepad. From here use the File->Open menu to get to Windows Explorer:

Navigate to the Windows\System32 folder and remember to choose ‘All Files’ under type. Here you will find the stick keys binary:

Rename this to sethc.old and then create a copy of cmd.exe and rename it to sethc (do not add in the extension as windows is already hiding this and the attack won’t work)

Once done you can now cancel out of the wizard and reboot the host. Once the login screen is loaded you can now press the shift key 5 times and enjoy your shiny system shell:

Recommendations

To remediate this, the following commands need to be entered into an administrative command prompt:

bcdedit /set {default} recoveryenabled No

bcdedit /set {default} bootstatuspolicy ignoreallfailures

I haven't found any registry or Group Policy settings that could be used to apply the same fix across multiple systems, so you might have to have it deployed via a batch file and a login script.

Once done, the fix can be verified using the 'bcdedit /enum all' command:

Although I have never known this trick to cause any problems, on really temperamental systems you could just as easily validate whether the host is vulnerable by checking the above settings have been applied.