I don't know whether this works in newer versions of Windows, but it was extremely simple to elevate your priveleges on almost any Windows 7 machine. I've done this dozens of times.
I haven't used Windows for years now, so the details are a bit fuzzy, but it essentially worked like this:
Start the machine. During boot(when you see the orb splashscreen), turn off power or hold down the power button for a few seconds.
The next time you boot up the machine, windows will say it failed to boot and offer to go into startup repair. Do that, wait for some time, and click through until eventually you see a bug report that you can open up in notepad.
Once you are in notepad, open up the "open file" dialog. From there, navigate to "C:\Windows\System32" and replace "sethc.exe" with "cmd.exe". Now, reboot normally.
Once you reach the login screen, spam left shift until you get a command prompt with admin privileges. Now, you can create new users, change the password and privileges of existing users, or even start up explorer.exe and use the computer normally as admin, bypassing the login screen entirely.
This works because "sethc.exe" is the executable responsible for Sticky Keys, which is activated by pressing shift repeatedly. Instead of sethc.exe, now cmd.exe would be run instead.
You're kidding, right? You can drop in any executable in place of sticky keys? And it runs with Administrator privileges? How does Microsoft own the enterprise and government spaces with glaring lack of basic security like this? :/
You have to get used to the fact that any physical contact with an unencrypted hard disk, whether it's locked in a computer or not, means that this person now has r/w access to all that data.
The grandparent technique does not rely on physical access to the raw hardware - only mouse, keyboard, and power switch (intended human interface endpoints). The computer case could be behind a concrete bunker with the only communication being cables for the mouse, keyboard, power switch, and video out, and no ports, and this would work.
The Windows security model is intended to protect administrator-account access given these parameters.
.. and so far it has AFAIK never succeeded to protect from all these attacks. That's what I meant with 'locked inside a computer'. It also doesn't matter because in the real world you don't have that bunker in between.
you'd either have it in a bunker with a remote terminal, or you'd get in the bunker after security clearance. making up weird scenario to prove a point is a fool errand, security needs compromise and threat modeling, it's not a blanket meant to protect for every type of attack ever.
I think we should continue to resist accepting this as normal, especially when it's not true for iPhones. We should get used to at-rest encryption. (It seems that part of the current exploit under discussion bypasses Bitlocker?)
As a kid I did this with magnify.exe to get around account time restrictions (hi, Dad). Enabling magnifier from the accessibility dialog on the login screen would pop open a command prompt running under the SYSTEM account. Punching in "explorer.exe" would get you a desktop.
I can't remember where I saw it, but here's how you teach your kids to start scripting:
Step 1: put a note on the fridge saying "The new WiFi password is one of the 10 random keys in the text file on this USB drive [taped to note]".
Step 2: wait a few days, repeat Step 1 with 10 replaced by 10 000 and also leave them an intro to Python (or $favorite_lang) book. Bonus points if you make the USB drive boot Linux straight to a Python REPL.
I had to learn lock-picking first to have access to the mighty computer room, first. After a while I discovered that I could kick the door open easily. Then they realized the door was wobbly and replaced the entire frame. That's how I learned brute-forcing was not a viable long-term strategy.
Yes, I was doing it for years since Win98. There even was Linux distro dedicated for it called logmein that has something like 35MB. I still have .img of it, if you would like to test it. The distro was no longer supported since Vista, but still worked on win7.
You can also drop (almost) any executable in place of explorer.exe, it's the basis of Windows Server "Core".
It has both good and bad sides, and the same (basic) thing is exploitable on linux. You can replace `cat` with another executable and change the PATH so that the new `cat` comes first.
/tmp/cat
PATH=/tmp:$PATH
edit: I'm aware that this does not give root privilege (though it could, through some SUID hack or cowroot or anything really), but it is the same basic "flaw". (again, though it isn't really a flaw)
I think the Linux equivalent would be more like interrupting the boot process at the GRUB menu, then adding "init=/bin/sh" onto the kernel command line, so Linux boots into a root shell.
Not really. In any Linux system I've seen,if you can change PATH you can already execute your /tmp/cat directly. And generally PATH and LD_LIBRARY_PATH are not passed through suid or sudo.
Oh, so essentially the same bug that existed since windows 98? Where you could, on the login screen, click the little question mark, which would open windows help, then you could click on "open file", navigate to C:\windows and just double click on explorer.exe, which would log you in without a password?
Windows 98 was not intended to offer meaningful local security. The password prompt was used to collect the username/password to use to connect to network resources. (And also, perhaps confusingly, the password prompt was overloaded to select the local user profile, if such feature was enabled - but entering a new username would create a new account, so being a barrier to using the computer was never the point.)
Windows 98 wasn't a true multi-user operating system anyway, security was a simulation. Only the NT line was multiuser at the time (and later XP through 10).
The Windows 98 issue was a bug. The example given involving Windows 7 and renaming executables is NOT a bug. If you give someone unrestricted access to the hardware, they have unrestricted access to the hardware. Working as intended.
You want someone not to be able to mess with a Windows installation? Activate Bitlocker.
That's why this Windows 10 issue IS a bug. Because it bypasses Bitlocker and allows a normal user to escalate to local admin. The Windows 7 issue is NOT a bug because it allows no such escalation (since no security was ever stopping local HDD access anyway).
I haven't used Windows for years now, so the details are a bit fuzzy, but it essentially worked like this:
Start the machine. During boot(when you see the orb splashscreen), turn off power or hold down the power button for a few seconds.
The next time you boot up the machine, windows will say it failed to boot and offer to go into startup repair. Do that, wait for some time, and click through until eventually you see a bug report that you can open up in notepad.
Once you are in notepad, open up the "open file" dialog. From there, navigate to "C:\Windows\System32" and replace "sethc.exe" with "cmd.exe". Now, reboot normally.
Once you reach the login screen, spam left shift until you get a command prompt with admin privileges. Now, you can create new users, change the password and privileges of existing users, or even start up explorer.exe and use the computer normally as admin, bypassing the login screen entirely.
This works because "sethc.exe" is the executable responsible for Sticky Keys, which is activated by pressing shift repeatedly. Instead of sethc.exe, now cmd.exe would be run instead.