It's very simple really; just don't run any external programs. Better still would be to limit the permissions of each specific executable (like iOS does), but that's not how Windows was designed...
This is one reason why we use BitLocker with TPM unlock on all of our student PCs. If the system is booted in an usual way like this, the disk won't unlock. We had issues our first year with a student who booted a Linux DVD and reset the local administrator password and another instance where the student removed the hard drive to do the same (after we'd locked our BIOS settings). Encrypting the drives has 100% prevented these problems, and makes us feel better about sending failed drives to vendors without wiping them.
If you have physical access to the harddrive and can turn it on or off legitimately, then can you not just image the harddrive to a backup (While its running) then modify whatever files you want and restore the new modified backup back to the harddrive? Sounds to me like you would be off to the races then.
Bottom line is, if you let people have physical access to the machine, they can always own it.
> an you not just image the harddrive to a backup (While its running)
The disk contents are fully encrypted, and Windows will only boot when the system is in an untampered state (via TPM unlock). A student would have to compromise Windows in a way that escalates their privileges. From there they could turn BitLocker off if they liked. This is far from impossible, but we also use AppLocker to prevent students from running any software that has not be explicitly approved--so they would have to compromise some software which is already installed. I won't delude myself and say it's impossible to compromise all of this, but for my goal of keeping 13-18 year-olds from resetting the local admin password it is quite sufficient.
TPM is a chip on the motherboard that stores the keys for the encrypted hard-drive. You can't move the hard disk to another machine or use a backup to go elsewhere because it won't have the correct key on the TPM to decrypt the hard drive.
If you have physical access, just reset the bios and reinstall windows on the box from scratch. If the bios cannot be reset ( is such a thing possible ) then remove, clip, or melt the tpm chip in order to force the system to forget it's tpm info?
It's not that the TPM chip is "enforcing" the encryption, it actually contains the "password" to it. So if you remove, clip, or melt the TPM chip the hard drives' data is forever lost, as that key is now destroyed.
The discussion was whether students could force the machine ( a laptop they could take home with them ) into a state where they could use it to cheat during tests.
TPM chips generally provide the following:
1. An encrypted store that can only be accessed by an authorized portion of code ( such as booting an encrypted drive ). Checks are done to ensure the code being run is signed.
2. Secure RNG ( random number generation )
3. Various other public/private key stuff
Typically you can enable/disable TPM from the BIOS. ( whether it is a physically removeable TPM chip or not )
Obviously removing/destroying the TPM chip will cause a loss of data, but that is irrelevant if you don't care about that data and are willing to reinstall the OS.
It isn't hard to install a clean OS on a wiped drive. Even supposing somehow you couldn't reset the BIOS to shut off the TPM and force a normal clean drive boot process, I was speculating if removing/destroying the TPM would revert to booting normally.
Note there was a lot of anger when TPMs were initially introduced, because they could effectively be used to force a system to only ever boot a signed OS. ( removing the ability to run Linux ) This is my curiosity; if on normal systems this can be forced or not.
>If you have physical access to the harddrive and can turn it on or off legitimately, then can you not just image the harddrive to a backup (While its running)
How would one complete an image level backup of an encrypted hard drive without admin rights?
What exactly are you suggesting? Those dumb case keys everyone now has? Or security screws? CCTV likely won't help as you cannot realistically get 100% coverage of every lab on site. So while it might stop someone walking out with a tower (or ID them), it wouldn't stop anyone doing this...
Honestly software security is the optimal solution. It solves a whole host of threat models (alternative boot media, repair tool, HDD removal, stolen machines, HDD warranty data leaks, lost laptops, etc). All physical security does with that in place is stop someone stealing your internal components, but it is expensive to do well and relatively easy to defeat with just a screwdriver or paperclip (and "unlimited" time).
Because they use it to circumvent restrictions on our network and devices. Our early years we had some students do this. They used proxy software, installed games, cheated on tests, etc. It was a giant mess and made staff question the effectiveness of our laptop program. I don't doubt that some students would use admin access responsibly, it's the other 90% of kids that won't that are the problem.
If you have physical access to the PC, why not just boot up Ubuntu, and replace the files that need replacing? No need to rely on a feature in Windows that can be disabled.
If full-disk encryption isn't used, there's really not much the underlying OS can do to prevent this.
Lots of work/school computer has a password locked BIOS which prevents you from booting from anything else. If they also have a physical lock on the computer, or if it's a laptop that you can't open or doesn't have a bios reset functionality, or you're worried about getting caught opening the computer, you're effectively locked out.
This exploit does actually open possibilities where there were few/none before. Also I imagine it's easier for some people to execute.
Some devices make this very difficult. Well, not very difficult - just more time consuming. I was trying to unlock a BIOS password on a Toshiba Satellite maybe 3 years ago, none of the default or "backdoor" passwords would work. However, you were able to reset it by using a jumper to complete a specific part of the circuit.. Not for the faint hearted, however if a thief steals the laptop, they'll have no problem opening it up in their own time.
I'm glad they've made this harder, as most thieves are deterred by the technical aspects of breaking in to wipe a computer.
Don't even get me started on the passwords to unlock HDD's, the ones you set on the BIOS... One day I will write how I unlocked the Toshiba(TSSTCorp) HDD I had forgotten the password for on my laptop.
I had to buy a new HDD, because I didn't have a spare one at the time, but I did it in less than 5 minutes, unscrewing and screwing the laptop covers and HDD's included. They weren't even the same brand. I bought a Samsung to unlock the Hitachi.
It's not very hard to build a keylogger using basic pic chips and install them into a keyboard. The same could be done against a dumb terminal. For bonus points, put a bluetooth module / picoduino inside so that you can read out people's keystrokes without touching it again.
Also time, our university did something like this on their library computers. It meant waiting 5min after someone logged out for it to do a system restore before the next person could log in. Which seemed like forever when you're rushing to print a paper.
It doesn't need fixing, it is working as intended.
If you can alter one system file then you can alter all system files. So even if this got "fixed," then another program would be replaced, a service, or the login screen itself.
The only actual fix is to protect the Windows installation itself, this can be accomplished through full disk encryption (e.g. Bitlocker) in combination with uEFI secure boot.
To be honest I roll my eyes when people post "exploits" like this. It just shows that people have no core understanding of computer security from the ground on up.
As an aside this exact exploit would work perfectly on a Linux (e.g. Ubunutu) system that didn't implement full disk encryption.
The clever part is getting the startup repair command prompt with no additional tools. Its similar to the old windows login bypasses (https://i.imgur.com/fqjnKh.jpg) in that it gives on more tool to use for pentesting.
This trick is widely used by hackers to maintain persistent access to large enterprise networks. You can RDP around and press Shift 5 times to pop up the cmd.exe on machines you've modified. No malware needed.
Performing this modification DOES NOT require rebooting the computer into startup repair if you have admin access (which is typical after you get hacked). There is a process that watches system32 for modifications and resets them, but if you script it and change the files fast enough it won't notice.
The utility of this trick is really insane. Would you realize that a hacker had backdoor access to your computer via RDP if the only thing that was modified was cmd.exe and sethc.exe swapping places?
Surely the thing you'd notice so you could lock them out is admin passwords being changed? Not that this fixes the root of the problem, it would just make you aware that you had a problem.
I found out about this method last week and it's my new favorite after having to fix up a couple of weird situations caused by someone joining their laptop to the school domain, and someone locking themself out of their only admin account.
I was quite surprised to find that the command shell ran with admin privs from before the login process, since I was unable to elevate in any other way (including by trying system restore back before joining, or trying to get into safe mode).
This is the de facto standard for local lost-admin-password resets since Windows NT was released, although back in the day the trick was to change the login screen saver to the command interpreter. The imgur album is a nice touch, I guess, but if you do a web search for "windows lost admin password" (or similar), you'll get some variation on these instructions.
I had to do this once to change the password of a machine's account (the machine's previous user had left the company). Of course, I used an Ubuntu live DVD to do the file renaming. It's the cleanest method, since it allows you to use Window's own routines to change the password, instead of an external program which might miss updating something.
But the interesting part of this post is the trick to do the file renaming without having to boot from any external media. This bypasses any security preventing the use of external media. Even if a user has access only to the keyboard, mouse, and power button (or can cut the power by pulling the cable), he can use this trick to do the file renaming and gain local admin access.
It isn't exactly novel. Using the Windows Recovery Environment (however you get there) is exactly how this has been accomplished since the introduction of WinRE in Vista.
I remember someone (not me, oh no...) used one for NT4 with inadequate policies to get Admin access.
Create a batch file with the content:
net localgroup administrators NewUser /add
...then stick this into the 'StartUp' directory for All Users. Break something. Call support. They log in as Administrator, running your batch file in the process.
NewUser would be created with Admin rights. You wouldn't promote your own login, of course.
BIOS password lock, and physical lock on computer and/or an environment where it is hard to open the computer without being detected (work/school) makes other options hard.
This exploit you could even pull off on a school lab computer while the teacher is in the room. If he comes over while you're working, inconspicuously power off the machine.
You can't stop a guy who knows what he's doing, but you can stop Josie from the next desk snooping around in HR's file. Also, it causes a breach, which depending on where you live might be needed to show intent.
Same reason we put locks on our doors. If someone is really serious, he or she can (destructively) break in. But a locked door will prevent someone from casually getting in.
You can do this with a phone or tablet (Android). That's essentially how many root exploits are accomplished, boot into the default recovery (typically hold volume up during power on), run a script, and recovery replaces key files which are used later to provide you with root.
This is less common NOW, but back in the Android 2.xx days it was the defacto way of getting root.
This is a vulnerability. This attack does not require physical access. Do you really think that startup repair mode is required to swap the position of cmd.exe and sethc.exe?
No, it's not, because sethc.exe resides in %systemroot%\system32 - an area that is protected by ACLs, only allowing regular users read access. Going into startup repair mode grants system-level access to files there. Without repair mode, users cannot swap these files.
The Repair Tool requires unrestricted physical access, it is running as administrator. The same way that a Live CD could.
> Do you really think that startup repair mode is required to swap the position of cmd.exe and sethc.exe?
A Live CD/DVD would work just as well. As would a USB-based OS. You could also (although it would require more work) use network boot to run your own code.
There's no vulnerability, this is unfixable, you just have to secure the system using full disk encryption and secure boot.
And then you can't set it back (since you don't know what it is), so the owner of the machine would immediately know you were there. They wouldn't be able to log in.
I think it's now two decades since I first found how to overwrite BIOS passwords from MS-DOS QBasic in order to break into school computers. Somehow reassuring that kids are still doing the same thing.
The comments about bitlocker and TPM are a good reminder that he who controls the boot sequence controls the computer / phone / car / IoT toaster.
that's how I got in trouble for hacking in high school; used our pascal IDE (in DOS) to make a perfect replica of our fancy ASCII login. It would capture your username and password, and then spit you back out to the real prompt. I only got caught because I kept all my stolen logins in my home dir, in passwords.txt.
I talked the teacher into canceling all of my detentions in return for showing him how to secure his bootdisks. Man, kids today would just get expelled or go to jail. I'm glad I grew up when I did.
I graduated from HS 9 years ago and I almost got suspended from all computer access, ended up getting some detentions, and various other punishments just for using Firefox. (Would have hated to see what the naive principal would have dished out if I wasn't one of the top students in my class)
That's the truth. I went to s particularly safe middle school, so when we had a random weapons sweep with metal detectors, only 3 students got caught. I was one of them; I had my little 1" swiss army knife, one girl had a steel nail file with a sharp point, and a mexican kid had a 3" folding buck knife.
Me and the girl were white honor students, and we were let off with a stern warning, and our "weapons" were handed to our parents. The mexican kid with poor english skills got sent to an alternative school (the kind for disciplinary risk kids).
Yes because the recovery menu won't be accessible than (which is needed to replace the sticky key executable)
The settings can be changed with bcdedit:
bcdedit /set {default} recoveryenabled No
bcdedit /set {default} bootstatuspolicy ignoreallfailures
Additionally booting from USB/... should be disabled in the BIOS/UEFI options and also access to that should be password secured.
Further more because the person has physical access, the computer should be locked away so that the harddrive can't be accessed. Also all cables should be secured so that no sniffer can be plugged in between. This also especially includes the USB ports on the monitor if those are enabled.
Just this one method, yeah. But unless you encrypt your harddrive you're not going to really get security when someone has physical access to your device.
There are other things you can do though. FDE, encrypted bootloader, BIOS passwords (on boot if important enough), removal of DVD Drive/USB ports as an option. Security isn't binary, it's about layers and compromises based on use case.
NOT TESTED: I imagine that as long as you don't have a startup disk, it would. If you have a startup disk, you could likely kick off the repair from the disk.
To paraphrase another comment from imgur: If the hacker has physical access to the machine, it's now their machine.
No, if I exploit your computer and have admin rights, I can use this technique to enable persistent access to it over RDP. This is a common technique that hackers use in enterprise networks.
Meh. If someone has admin on a machine then they can re-establish access in a number of ways (e.g. their own VNC service, their own Powershell instance bound to a port, malware, etc).
Binding sticky keys to CMD is one of the worst ways as it can be detected easily (either via people trying to use Magnifier and getting CMD, hitting shift 5x times, etc), it can be fixed by Windows updates even by accident (and will be fixed via SFC), and could allow other competing "hackers" to access the machine.
I've never seen anyone use this trick in reality and I've certainly never read about "hackers" using it. They typically like to use a tiny single-file VNC server with a hardcoded user/password.
Is there a good software (preferably open) to remotely kill/erase your data on a Windows machine. Not all versions have bitlocker. Truecrypt's future is unpredictable.
Any "secure eraser" - those programs that rewrite the contents of a file before deletion - does the job. Despite what is claimed (even by those programs and their developers), just 1 pass zeroing out the data is enough to securely delete information from a HDD.
Usually they reference a government document that says that physical destruction of the media is the only correct method to erase TOP SECRET (and above) data, but that is mostly paranoid burocracy.
If you're using a SDD however, you have to deal with firmware wear-leveling, garbage collection and the drive having a lot of GBs hidden from everyone, even the OS. There are some proposed techniques to force an unavailable block back into the available pool and then reading long-deleted data. Afaik, there's little you can do in this scenario, even full disk encryption might not help you with the old data blocks that are still waiting to be zeroed by the GC.
Then again, like you said, FDE is probably the easiest way. TrueCrypt was vulnerable to some on-memory-key attacks, but for data killing its more than enough. There are some projects that have forked TCs code, and there also the old version available thats still fully functional.
If you have a linux box handy, you can probe your ATA-compatible drives with:
root# hdparm -I /dev/X
look for:
Security:
Master password revision code = 65534
supported
enabled
not locked
not frozen
not expired: security count
supported: enhanced erase
Security level high
2min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.
"Enhanced Security Erase Unit" should get all of the sectors that have been previously used even on a SSD with wear leveling.
Of course, you still have to trust that the vendor has correctly implemented it. I have no idea what best practices are in that regard. If anybody here has a better idea, I'd love to hear (Is FIPS certification a good sign? If the drive implements encryption and can therefore do a secure erase by dropping the keys can it be trusted? Can drive vendors generally trusted to not use ECB mode? etc.)
Anyone who hates annoyance will already have disabled the stickykeys shortcut.
A more reliable way if you're somewhat prepared is to just use a live linux system and NTPasswd. Any distro that can be installed to a flash drive should have it available.
Had to do something similar at work a couple months ago when a Windows computer somehow ended up without a single account with administrator privileges but I replaced magnifier.exe with cmd (for some reason I even switched them around) and then opened the supercharged "magnifier" on the login screen. I also didn't use "Startup repair" but a Ubuntu Live CD.
I then got called away from the computer before I could switch magnifier and cmd back to normal and somebody started using the computer again, with hilarious consequences
Actually, someone linked to something like it in the comments: https://i.imgur.com/n9Th4q5.jpg
I can't imagine how difficult it must be to secure a login system with so much added surface due to accessibility and dumb users.