Hardware Hacking to Bypass Bios Passwords | Hacker News Reader

Hardware Hacking to Bypass Bios Passwords

blog.cybercx.co.nz

38 pointscptwin27 comments

I never got the impression that BIOS passwords were there to protect against attacks against adversaries who had full physical control of the machine to the extent they had the case open, more like a casual layer or maybe if the machine was physically separate from the terminal IO. After all, at that point someone could just take your hard drive anyway right?

It was my understanding that the BIOS password was just one of many security layers that would ideally be in place in a protected environment, said layers being pretty effective when working in concert.

My gripe is the eBay sellers and liquidators who want to sell a BIOS-locked laptop at full price. If a seller can't handle removing/resetting this password, then they shouldn't be selling it, or at the very least, list it as a $5 parts machine.

The BIOS password is a pretty meaningful protection - if it can be easily subverted it's possible to disable security features (such as IOMMU configuration for Thunderbolt devices in the boot environment) that allow an attacker to compromise the boot process. But I agree that there's no universe in which people should be selling devices that require unknown passwords as if they're generically usable.

This.

We are talking about having physical access to the machine for long enough to partially dissasemble it and physically manipulate the mother board. There are a lot of attacks that enables, and almost no one even claims to defend against them.

Put another way, a modern computer can be thought if as a network of relativity simple devices, of which the eeprom is one. Normally we assume that an attacker does not have access to this network. If the attacker does have access to this network, the game is lost. Everything about the network is unencrypted.

> After all, at that point someone could just take your hard drive anyway right?

With full-disk encryption, taking the hard drive is not that useful. Firmware passwords are one link in securing the boot chain; secure boot is meaningless if attacker can just modify firmware or its config. So the password should offer protection against evil maid style attacks.

I'm not sure why this would be the case. Secret keys never leave security processors or data drives. The BIOS does very little here.

From firmware config you can potentially enroll new keys, or just disable sb completely, both which enable injecting malicious code in the boot chain

When changing security processors the secure boot drive requires the entry of the secret key again.

If a user enters the secret key on a compromised system then the game would be up. You would need to wait until the user decided to change the security processor to intercept quietly.

Pretty disappointing that simply shorting two pins at the right time is sufficient to bypass security on a modern machine by a reputable vendor.

This eeprom, being security relevant, should be signed by the TPM, read into RAM, and if the signature check fails then the machine should consider itself stolen.

The only recovery method should be to replace the EEPROM contents with another valid image, also signed by the TPM. And that image should be available from the manufacturer for anyone able to show they are the device owner.

Signing with the TPM doesn't work super well, given that the TPM's inherent keys can't be used for signing as a privacy protection mechanism. You'd need to store an encrypted key in the image that could be used for signing purposes, but what stops an attacker from simply wiring up the TPM directly, generating a new key pair, and storing that instead? This is a legitimately difficult problem to solve well.

> but what stops an attacker from simply wiring up the TPM directly, generating a new key pair, and storing that instead

Simply?

Did you just equate resetting a bios password with wiring up a TPM and generating a new key pair?

The situation we're discussing already involves taking the machine apart to short the security eeprom during boot. Once you've accepted physical attacks as part of your threat model it seems reasonable to say that any mitigations you're designing should be resilient to physical attacks as well.

TPM is nonsense, i can trivially replace the processor/TPM module w/ whatever I wish.

If it was used to encrypt a disk, then what does replacing TPM accomplish exactly?

if the disk is encrypted, then the bios password does nothing at all. The access to the BIOS is a separate issue entirely.

Why are we even discussing TPM if it is not being used for its main purpose?

You can kind of do that, although the process is a bit inverted.

BIOS settings are "measured" into the TPM, into a set of "platform configuration registers" (PCRs). The TPM itself takes no position on what the "correct" value of the PCRs is; however, it is possible to bind data against the PCRs. For instance, you can bind your disk encryption keys against the PCRs. Then, if the eeprom changes, the PCRs will be different, and the TPM will refuse to give you the disk encryption key.

The hardware itself is still valuable in the sense that a common thief cares about, but all of your data is protected, and you are not any more risk of using a compromised system then if the attacket simply swapped the unit for one that looks similar.

> The hardware itself is still valuable in the sense that a common thief cares about

Anti theft protection needs to make the hardware unusable when triggered sadly... Apples iCloud lock effectively does this - locked iDevices sell on the black market for only about 20% of what an unlocked device sells for - and that 20% represents the values of the fraction of components that are not serial number locked.

>modern machine

10 year old, last lenove gen where this was possible

I feel like the obvious "How can we prevent this?" solution is "Don't fail open if your SPI transactions fail"? The most straightforward implementation of this would be for the firmware to read from the security EEPROM to obtain a hashed password of some sort and then verify that the entered password satisfies that, and if that read fails simply refuse to either enter the firmware or boot depending on config - that's sufficient to deal with the screwdriver attack. However, that still allows an attacker to replace the security EEPROM with something that simply provides a known hash, so the next level would be to encrypt the stored hash with the TPM (which will use an encryption key that's specific to the motherboard in question) which prevents that attack. At which point the attacker removes the TPM from the board, puts their own board on those lines, and sends back whatever they want and then they still win.

This is a legitimately hard problem to solve! Unless firmware starts using authenticated sessions with TPMs (in which the traffic over the easy to sniff bus is encrypted), swapping out the TPM is going to be a plausible vector for someone with physical access to the machine. Moving to fTPMs (in which the TPM stack runs as a software component on a segregated chip somewhere else on the device, such as the Intel Management Engine or the AMD Platform Security Processor) or an on-die TPM (such as Microsoft's Pluton) makes it massively more difficult to carry out this kind of attack.

tl;dr - unless you're introducing strong cryptography into things, trying to make security happen over unauthenticated buses is probably not going to work well for you

Once it's in the hands of someone adversarial, physically, there's no way to completely stop this.

Completely stop what? If you encrypt your drive, then all these attacks fall into a category of 'continuing using a device after someone tampered with it'.

If you're that paranoid, then you can buy anti-tamper stickers. I'm not joking BTW, I think some of those are pretty damn impressive.

I always found it amusing the Dell Latitude models and probably overs had a list of permanent bios passwords you can find online that would override any user set password.

Great security there.

So - what is the BIOS password really protecting against - other than deterring employees from playing with company laptops?

Note: If I own the laptop and don't have the password, I'm at the mercy of the vendor. And does the vendor want me to use my old hardware, or buy a new one?!

That’s exactly what it’s stopping - users who don’t own the computer from tampering with settings.

My kids inherited an iPad from an aunt who passed away without writing down her password. It sits on a shelf in their bedroom as a constant reminder to never buy Apple products.

Reply on news.ycombinator.com