BitLocker Lockscreen Bypass
secret.club
secret.club
The error dialog in the gif when Cancel is pressed does say "You cannot use Windows unless your login name is validated by the network."
Just messed around until I found that accidentally, and I was able to run commands.
It would have been around 18 years ago, something like that.
If you want to prevent this you need full disk encryption
To protect from that threat you need secure boot which verifies checksums from BIOS to kernel.
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.
Let us assume one can’t easily modify the filesystem or special boot options are not available
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.
Fun times!
May be its not the Windows but 90s & early 2000s ... don't know.
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.
Good times playing Age of Empires and Half Life on school computers over LAN using that!
We played Quake mostly!
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!
I was a kid then. Kids these days are finding these sorts of "exploits" in phones and whatnot all the time.
That, or get lucky by clicking around a lot.
1: https://msrc.microsoft.com/update-guide/en-us/vulnerability/...
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!
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.
It's a known problem forever because there's literally no solution. You can very well patch lsass.exe to add a backdoor, for instance.
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.
autoruns have been disabled for USBs since windows xp SP3
Without that, this vulnerability seems to only let you create local unprivileged user accounts which isn't such a big deal.
This part in particular seems like it would be incredibly amusing right before the account gets added;
> It is easy to see when the loop is running because the Narrator will move its focus box and say “access denied” every second.
This truly is Hollywood style hacking made real.
utilman.exe I abused this back in the early days of disclosure
From an accessibility perspective, the only solution that makes sense is pervasive surveillance to determine if you're human or not.
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 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...
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.
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.
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.
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).
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.
[1] https://support.apple.com/guide/security/data-protection-cla...
Encryption is necessary, but not sufficient, to have secure .
[1] And then there's integrity, replay protection, nonreprudiation, forward security.. etc other properties.
Shameless plug: Mandos solves this problem on Debian (and derivatives): https://www.recompile.se/mandos
Thanks for the heads-up!
If so, you are using one of the more secure configurations. If not, you are using the less secure (TPM-only) configuration.
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.
[0] https://docs.microsoft.com/en-us/windows/security/informatio...
M1 powered Macs do this too. Does Intel or AMD make any chips with a TPM built in?
> 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.
https://www.microsoft.com/security/blog/2020/11/17/meet-the-...
So if you steal a laptop you can get at the drive contents using this trick.
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.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\NgcPin
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.
Much more in depth info: https://news.ycombinator.com/item?id=25810639
* Unless you have cracked AES
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.
[0] https://en.wikipedia.org/wiki/Evil_maid_attack
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.
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.
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!