There was (and still is) misconception regarding that screen. That screen is for authenticating on the network. I believe you could also just close the dialog. It’s not for authenticating a local user account. Failing to authenticate you just couldn’t access network shares.
We very much for sure used this trick (and others) to go around network authentication back in college days: we had individual network accounts and only the admin had a local account. Poor fella ended giving up cleaning our mIRC and Starcraft installs.
I recall being able to just cancel that dialog back in the day. There was a group policy to require network authentication added at some point, but I don't know when.
This one makes sense to me, if someone has access to the console during boot, there's not much sense in preventing them from logging in. At that point they could just pull the drive and mount it in a different computer and replace passwd and shadow.
If you want to prevent this you need full disk encryption
Just full disk encryption does not solve the problem fundamentally. Malicious user with physical access could just install keylogger into bootloader which would log the password on the next boot.
To protect from that threat you need secure boot which verifies checksums from BIOS to kernel.
Full disk encryption alone suffices against device theft, presuming the device is turned off. More complicated threat models like an evil-maid attack are much harder to defend against.
Secure boot, and temper-evident device seals, form the outline of a solution. As far as I know though, these are still far from foolproof. Really I would say defending from an evil maid attack is still an open problem.
Something very similar holds for theft of devices that are still on.
I didn't know that one back then but there was another one, where you could remove a file(or rename it) from C:/Windows(I don't remember which one it was, but 10 year old me definitely knew, but somehow I think it was C:/Windows/passwd) from DOS. Then you type in any password and it let you in and then you just swap the file with the old one once you are done. Sigh the number of times my classmates asked me to use it on our math teacher's computer in order to copy the tests...
That's not exactly the same, because it's essentially modifying the operating system files to bypass the security checks, whereas this article and the gif are basically loopholes in the OS that gives you access.
Well technically that is possible in any OS. You can mount the drive elsewhere or to a live cd, change root password. That is the recommended way to recover from lost root password (assuming FS is not encrypted - which was the case you were talking about)
Let us assume one can’t easily modify the filesystem or special boot options are not available
Don't forget hypercard, that let us run whatever we wanted on Macs.
On windows though, we discovered that if you use the save or open dialogs you can just browse wherever, right click, and run the exe.
It sounds like that was a bit before your time, security was even more laughable then. Oddly, the network was set up perfectly, at least according to the standards of the time.
You could bypass the screensaver lock this way. If the C: drive was shared over the network (and more often than not it was!) you could just rename c:\windows\scrnsave.exe and the process would crash.
Compared to today, when I see Win9x & WinXP I feel a strange bit of innocence and how simple it was back then, both for individual developers & industry as a whole. (kinda difficult to articulate what I want to say)
May be its not the Windows but 90s & early 2000s ... don't know.
Absolutely - I'd like to know why exactly MS decided to make the classic theme unaccessible.
On early Windows 10 versions, you were able to re-enable it by stopping the window manager from creating the modern theme resources, I'm not sure if that still works but it leads me to think that they did it for brand reasons. Classic theme is distinctly "old" and they probably wanted to get rid of that conception.
Also, you could drop into the Visual Basic editor from any office program: the File > Open dialog would happily launch any executable under Novell lol.
I'll be that guy and mention that Windows 9x had no local security and this was considered NOTABUG. You could also press F8 to drop to DOS and run something like win.exe /nonetwork.
Android FRP is also bypassed by various tricks like this. (usually involving starting Talkback, going into help, there clicking on YouTube video, clicking something to open browser...etc)
Heh! Memories! RM Networks ~1998/1999 when I was in School... You would login and then you got their interface popup saying you were over your space allowance and clear files or you can't login...
I did this exact same trick (passed network login though) to get out of it! Although, mine was to go to c:\windows, type . then right click explorer.exe and click open!
For me, it was boredom and cheapness. Once my trial copy of Win2k ran out and it confronted me with it, I tried hitting ctrl+alt+del. To my surprise, it worked. So from there I was just able to launch explorer.exe.
I was a kid then. Kids these days are finding these sorts of "exploits" in phones and whatnot all the time.
You have to understand the data at a structural level and how it flows through the application. Then you can identify entry points to access that data using non-traditional methods that the developers may not have considered when implementing security features.
Microsoft's fix seems to have only fixed the sticky-keys dialog [1], apparently by just removing the link to the settings when you are in a lockscreen. So if you manage to find another way to launch the settings from a lockscreen everything else should still work as described.
Form a security standpoint I don't understand why Microsoft would even 'launch' any app (that's not necessary for login) while lock screen is on. The lock screen should be completely decoupled. It would be like trying to enter a URL in a browser while the browser app is closed which is basically impossible (I'm not talking about adding it as a cmd param).
That would be even worse than the current state of things.
Accessibility services are necessarily kernel services, since they tie deeply into considerations of what the OS should/shouldn’t allow the user to do at any point.
Giving the login application its own copy of those services, would mean giving the login application (⇒ applications in general) the ability to tie as deeply into the OS as the accessibility services themselves do. Avoiding that is the whole reason accessibility was made an OS-level feature in the first place!
> Giving the login application its own copy of these services...
It’s much easier to have a lock/login screen that ties closely with the rest if the OS, but that’s not an actual requirement. As an extreme example Windows could split things so you have the login screen and the rest of windows as effectively two completely different VM’s that get swapped between.
I am not saying that’s a good idea, but Microsoft is building the OS from the ground up they have a lot of options.
IIRC, in this case it's the kernel accessibility API that's spawning these client processes from kernel-space, due to events the kernel is observing directly, rather than events being reported to the kernel from a userspace process — which is precisely how these accessibility helper UX processes get to be privileged in a way that regular userland processes aren't.
What’s funny is we used to replace each other’s sticky keys program if we left our computer unlocked. Hours of entertainment while they try to figure out how you keep getting back in. Lock your machine. And if it’s windows, apparently, don’t have USB ports. It’s been a known “problem” forever (When you remake the sticky keys program you can unlock the machine by pressing SHIFT 5 times :)
Yeah, if the attacker has the right to replace arbitrary system executables, we're not really talking about privilege escalation any more. The solution is not to give people root access to your machine.
Not sure what the "don't have USB ports" aside was about: plugging in arbitrary USB peripherals shouldn't give you that kind of access, though they certainly are an attack vector.
USB has been a classic attack vector for local attacks forever. I have used them on red team social engineering engagements for a long time. An few innocuous auto run usb thrown into a few machines will be all you would need to compromise an internal network easily. The pint is you can harden physical security and a big part of that is disabling usb (physically if possible)
True. We tend to use things like inline keystroke loggers on keyboards these days for socials engineering gigs. You can also just convince people to run your stuff by giving it intriguing names (e.g. Q4 layoffs). Excel sheet, exe... etc :)
It's not as big a deal, but not without impact. You only need a local privilege escalation to go from a user with no rights to a fully open system. And systems are much harder to secure against code running on them with access to all those juicy kernel facing unprivileged APIs...
Windows has special protocol schemes specifically for opening various settings pages. I feel like an accessibility feature will probably make it possible to launch such a URL. Maybe the camera app's QR code integration (if any) can launch URLs if accessible via the lockscreen.
That reminds me of one of the old tricks for resetting the password on a Windows machine, which involves renaming cmd.exe to the name of the binary that gets run (can't remember the exact name at the moment) when you chose the "Ease of Access" option. It certainly gives you easy access!
> which involves renaming cmd.exe to the name of the binary that gets run (can't remember the exact name at the moment) when you chose the "Ease of Access" option.
utilman.exe I abused this back in the early days of disclosure
Audio captchas don't really solve the underlying problem. Yes, they make things easier for english-speaking blind people with no hearing problems, but that's about it.
From an accessibility perspective, the only solution that makes sense is pervasive surveillance to determine if you're human or not.
A lock needs not be unbreakable. It only needs to be more expensive to break than the value of the things it protects.
So captchas should only be hard enough to make complicated setups involving ML models or pipelines to Mechanical Turk not worth it. Pervasive surveillance is an overkill for this particular purpose.
I'm not really talking about this from an a11y standpoint, but audio CAPTCHA's are so much easier than "choose the fire hydrant" hell.
I actually remember reading a post saying that an accessible CAPTCHA is hard. To make it accessible, you have to make it machine-readable, which defeats the point...
This is not a BitLocker bypass. It's a Windows login screen bypass. The BitLocker login is before Windows ever boots. This describes a system where the user has ALREADY bypassed the BitLocker login and has advanced on to the Windows login screen.
EDIT: i get it now, it plays a small part in the exploit chain because it doesn't correctly verify what it sets permissions on when automounting usb drives.
There are two approaches to full disk encryption. The first one is the traditional approach: The encryption is applied independently from the operating system. The key is controlled by the user. The system cannot even boot without the correct key because the underlying hard drive is inaccessible. The disadvantage is the need of entering (very long) keys manually on boot.
The second approach, which is popular on phones and tablets, is to use disk encryption transparently, usually with hardware assistance. On boot, the key is automatically filled in by hardware (TPM for BitLocker) when some conditions are met, no passphrase is asked. In this case, the disk encryption employed is not really a "true" encryption [0], instead, it's an extension of operating system's authentication mechanism. BitLocker's sole purpose is to prevent anyone from bypassing the login screen by pulling out the hard drive, rewriting the password, and putting the hard drive back in. It's also why smartphones can be reasonably secure even with a 4-digit PIN.
This authentication exploit bypasses the login screen despite BitLocker, so it's technically a BitLocker bypass, although it doesn't break any crypto.
BitLocker can be configured to use either the first approach or the second approach. The second approach is used on many systems by default. As the exploit has shown, if you have serious security requirements, using the first approach is more secure (but do remember to shut down the computer often).
[0] For example, in case of TPM, the BitLocker key can also be physically extracted on boot using a logic analyzer to monitor the communication between the host and TPM... Nevertheless, if you can put a security coprocessor into the CPU itself, it can be reasonably secure since key extraction is really difficult, some smartphone's encryption (e.g. iPhone) uses this method.
> This authentication exploit bypasses the login screen despite BitLocker, so it's technically a BitLocker bypass
No. No, it is not. Let me give a similar example: lets say the drive requires a PIN and i ask the user to enter the PIN, then i still get to the starting conditions of this article.
Technically i could argue it now includes a social engineering variant of a bitlocker bypass, but it should be very obvious there is no actual bypass, only an "assume it is open" precondition. The article has an "assume the device is configured in a way that i can walk right past bitlocker to the lockscreen" and then calls it "Bypassing BitLocker in 6 easy steps". No, just no. Not technically, not theoretically, just no.
Not to be unfair to the author, the lockscreen bypass is clever and teaches a lot about defensive coding. It is a good finding. But the article gets dragged down by the sensationalist title, because the content is not what it says it is.
Thanks for just saving me a few hours of trying to decrypt an old hard drive with a corrupted Bitlocker that doesn't take the password anymore.
The title indeed reads like it can break/bypass Bitlocker encryption, but it actually doesn't do that at all.
As far as I know Bitlocker encryption can still not be cracked/hacked/decrypted/bypassed without the proper credentials (password/PIN/USB key/48-digit recovery key).
Apple devices (both Mac and iOS) use something in between those two approaches. To oversimplify a bit, they store a record on disk that contains the full-disk encryption key, encrypted with the user account password on macOS, or passcode on iOS. So the password serves as both an OS authentication mechanism and the equivalent of a BitLocker password.
As a result, it's not vulnerable to this type of attack: even if you get code execution on the login screen, you can't decrypt the user's data without their password. (If there are multiple users, any user's password will work.)
Traditionally, this meant that if you enabled FileVault on Mac, the first login screen you'd see when booting was actually part of the EFI firmware rather than the OS itself. It couldn't boot the OS until it knew some user's password in order to decrypt the main partition. On iOS, and on macOS as of Big Sur, the immutable OS is separated from user data, so the login screen is part of the OS proper.
Caveats:
- On macOS, this only protects the first login screen. Once you log in, the key stays in memory until the system shuts down, even if you log out or change users. On iOS, some files are like that, but other files are encrypted under a different key which is thrown away whenever the device is locked. [1] Hopefully that comes to macOS in the future.
- If you're using a weak password, such as the default six-digit passcodes on iOS (there's an option to use a stronger password), it would be trivial to brute force the password, so security effectively degrades to what you call the second approach. The security coprocessor will limit the maximum number of attempts, so attacks like this one won't work, but if you compromise the coprocessor then it's game over. And people have.
About terminology: in security engineering and cryptography, encryption methods and key management are considered different things[1]. Here in both cases the encryption method is equally secure. But the security of the system depends on of the key management method (or keying, for short).
Encryption is necessary, but not sufficient, to have secure .
[1] And then there's integrity, replay protection, nonreprudiation, forward security.. etc other properties.
Heavy bitlocker user here, and up until now assumed the first approach is what's going on; how do I verify which system is used, and switch to the former in a few words?
Do you need to type a disk encryption password into a Bitlocker-branded screen before Windows boots? Or alternatively are you required to insert a specific USB stick with a key file?
If so, you are using one of the more secure configurations. If not, you are using the less secure (TPM-only) configuration.
> how do I verify which system is used, and switch to the former in a few words?
Check whether you are using pre-boot authentication. BitLocker offers true encryption only if pre-boot authentication is used. Here's a tutorial: https://www.howtogeek.com/262720/how-to-enable-a-pre-boot-bi... More information on BitLocker's implementation details and its threat model can be found in Microsoft's documentation [0].
> On computers with a compatible TPM, operating system drives that are BitLocker-protected can be unlocked in four ways:
> TPM-only. Using TPM-only validation does not require any interaction with the user to unlock and provide access to the drive. If the TPM validation succeeds, the user sign in experience is the same as a standard logon.
> TPM with startup key. In addition to the protection that the TPM-only provides, part of the encryption key is stored on a USB flash drive, referred to as a startup key. Data on the encrypted volume cannot be accessed without the startup key.
> TPM with PIN. In addition to the protection that the TPM provides, BitLocker requires that the user enter a PIN. Data on the encrypted volume cannot be accessed without entering the PIN.
> TPM with startup key and PIN. In addition to the core component protection that the TPM-only provides, part of the encryption key is stored on a USB flash drive, and a PIN is required to authenticate the user to the TPM.
TPM-only is the default option, it's better than no security, but arguably insecure (depending on your threat model). TPM with PIN or startup key offers true encryption, they are not vulnerable to this category of attacks. But clearly, using a user-supplied key or PIN has its own disadvantage (which is why TPM-only mode was invented in the first place).
> On the other hand, Pre-boot authentication prompts can be inconvenient to users. In addition, users who forget their PIN or lose their startup key are denied access to their data until they can contact their organization’s support team to obtain a recovery key. Pre-boot authentication can also make it more difficult to update unattended desktops and remotely administered servers because a PIN needs to be entered when a computer reboots or resumes from hibernation.
If you have auto-unlock on your system disk, then by the time you get to the login prompt the key from TPM was already read and used to decrypt your disk. Any sort of auto-unlock is inherently less secure.
Two months ago, Microsoft announced the Pluton security processor and that future AMD, Intel, Qualcomm CPUs will have it. It seems to be for this exact purpose:
> These sophisticated attack techniques target the communication channel between the CPU and TPM, which is typically a bus interface. (...) The Pluton design removes the potential for that communication channel to be attacked by building security directly into the CPU.
Agreed, it is wrong to describe this as a Bitlocker bypass. From what I can see it is actually a Windows lock screen bypass and also privilege escalation vulnerability.
Also this bypasses the protection offered by Bitlocker (in the typical ‘keys are stored in the TPM’ setup) as it grants access to the system from the login screen without entering a password.
So if you steal a laptop you can get at the drive contents using this trick.
There's less need to jump through all these hoops if you have physical access to a PC with enabled USB ports. For example: you could boot from the USB device and access the local storage if it's not encrypted.
EDIT: I meant to say "if you have physical access without Bitlocker enabled". Bitlocker is protecting the contents of the storage, if you can bypass the lockscreen on a Bitlocker protected computer you've evaded this protection.
But this article is about bypassing Bitlocker, so that's not relevant. Also, if a system is unencrypted there are a multitude of ways to easily read the contents. That goes for any device or operating system.
I wonder if this was left on purpose for law enforcement or corporate spies and if there are more vulnerabilities like this. Seems like it's better to just stay with good old TC.
There are so many gotchas in computer security. Isn't there a way to verify that a simple algorithm can have only prespecified valid final states (aka {authenticated && allowed login}, {not authenticated && disallowed login})?
Use a strongly (or stronger-) types language. In C++, use switch blocks instead of if statements, combined with enums (or better yet, enum class) to get exhaustibility checking (warnings at least) from the compiler.
More correctly, model the entire thing as a state machine and use strong typing to prevent inadvertent or undesirable code flow changes that bypass the points of entry you are intended to use. But none of that helps here because they purposely added something that escapes the normal control flow for accessibility reasons, and instead of designing it as a part of the locked-down system, they used an escape to load the regular, unauthenticated accessibility apps for reuse.
But that is the whole point, they managed to get the system to an undesireable final state {create new user}. The narrator should be part of the validation.
I have only encountered BitLocker on military computers. There BitLocker login occurs before Windows boots, like at the BIOS key entry, and has no options for forgot password.
This is similar to what modern-day smartphones do: they encrypt your data so that it cannot be taken at rest, but assuming that you can hijack the OS you can still read it. Also, BitLocker does have a much more stronger mode where you are actually required to enter a PIN before you reach the regular lock screen that is physically uncrackable*. In other words, this is the state if you have a) done nothing and your device is eligible for automatic encryption or b) you actively selected "TPM Only" despite clear warnings that it will be weaker than PIN.
* Unless you get an Evil Maid attack [0], like adding a physical keylogger to the keyboard bus.
If the device is decrypted but on lock screen (like with TPM) there are more options, the main one is reading memory via DMA [1] on an ExpressCard slot (eg the wifi card). Also swapping out the memory to do a cold boot attack [2] is possible.
Actually, attacks using Thunderbolt PCIe capabilities are too much realistic that it is no longer funny (and it is not just a security bug, its a real feature).
It's measured boot with the TPM getting measurements of the system state during all steps up to the Windows Boot Manager. (and including the Windows Boot Manager configuration data)
If all the measurements match, the TPM releases the volume encryption key and the system can boot.
If you boot from an external volume and then modify the boot configuration or the OS loader, or reflash the UEFI firmware, the measurements won't match and the TPM won't give the key.
Of course, if the login prompt, which runs way afterwards is buggy, drive encryption in Windows won't save you there.
An advantage of this system is that when you reboot, all your services can run before you input your password, and you can login remotely. That's an absolute must for a lot of business use cases.
> If the application has a manifest, then any .local files are ignored.
I suppose this does not hold true for the .local folder named that, apparently? I had not seen it documented before that it looks in that specially crafted dll subfolder (presumably using information from the manifest) to load a dll that is specified in one.
The easiest way to see this is a tool like procmon - you can see every file that anyone tries to access or open. By taking a log of procmon while plugging in a USB device, I'm sure you can find a few things that shouldn't be being accessed...
Even when microsoft fixes all their issues, I can bet a bunch of 3rd party apps touch files on external media, and to exploit a locked computer, any third party app running on a users desktop is sufficient too!
I checked--if you have turned 5x-shift sticky keys off, you don't get that window when locked, defeating this exploit. So that would be a good workaround. Many users turn it off!
