The first step is to actually encrypt your drives. Far too few people and places even do this step.

Either use the OS-provided solution (Like LUKS, FileVault, or BitLocker), or use a cross-OS solution like Veracrypt <https://veracrypt.fr/>.

Secondly, to avoid the problem in this article, you should have an external password necessary to unlock the drive; not a TPM. This is, of course, not what most people do, since typing in passwords is tedious.

However, if you mostly need to boot up the laptop when connected to a specific network (e.g. on company premises), and it’s acceptable to require a manually typed password when the laptop is not present at that location, and if you use a Debian-based OS, there is a solution! Shameless plug: https://www.recompile.se/mandos

"All BIOS settings were locked with a password"

This is trivial to override for every laptop I've ever had, with sites like https://bios-pw.org/ You have to read carefully, like doing "<ctrl><enter>" and not just "<enter>", but it's worked many times for me.

Source code is here: https://github.com/bacher09/pwgen-for-bios

I do see that Lenovo (brand of laptop in the article) isn't on their list, though many others are.

There will always be a way in a network. The question is can we eliminate the network?

Now that computers in a LAN/WAN barely 'talk' to each other, and the apps are rarely on the same network as the users' computers, is there enough value in networking the computers relative to the risk of creating a valuable target for attackers?

Consider for example what the business case for attackers would look like if their target was an island of one.

Of course networks have benefits such as simpler ways for IT or MSPs to manage devices and updates, shared auth structures, directories and policies, etc. If we look at all those benefits, and consider the alternatives, are they worth the risk of a network in today's topologies with today's threat vectors?

Nicely done! This should be a good reminder to everyone who utilizes a pre-logon VPN to treat that environment as if it were already compromised. I've set up a ton of these, and never in my wildest nightmares would I give the pre-logon user access to anything they could use to move laterally in the org.

For those who aren't familiar with this, (for Palo Alto at least) there is a specific user assigned to pre-logon tunnels, and that user is supposed to be locked down - tight. Once a user authenticates fully to AD/okta/whatever, then the userID on the tunnel is swapped for the correct one, and your permissions become what they should be. Worth nothing that this is set up with firewall rules based on LDAP/AD user groups/UserIDs, so it's easy to configure, but probably easy to make mistakes.

That TPM hack was really impressive engineering. But I kept scrolling through to figure out what the next step was and it turns out the VPN software establishes a tunnel before authentication as a "feature".

So while the TPM hack was very impressive, this article only gives me a sense of safety for our own corporate laptops.

Things that would mitigate this to some extent:

1) Requiring an additional factor for disk encryption in addition to the TPM data. You want the TPM to be involved in order to be able to detect whether the boot environment has been modified and refuse to hand over the key in that case, but this case is an example of why automatically handing over the FDE key at boot isn't ideal

2) The use of parameter encryption. TPMs support the establishment of sessions that include key exchange, and can then encrypt responses sent to the OS. This isn't ideal - verifying that you're communicating with a real TPM is somewhat convoluted at this point, so someone with physical access can interpose the TPM and MITM the key exchange. This is a substantially more invasive attack, though. I'm surprised that Windows isn't doing this by default, which makes me suspect that there may be some corner cases that make this more difficult than I imagine.

3) Storing the VPN credentials in hardware. Once the attackers had access to the filesystem, they could simply copy the credentials. If the VPN key were actually generated on the TPM then this could be avoided. In order to get on the VPN, the attackers would have had to modify the filesystem in order to let them put the disk back in the original machine and boot it. This would mean they'd need to retain access to the machine for as long as they wanted VPN access, which increases the chances that the machine's absence would be noted and its credentials revoked.

4) Requiring user auth before any amount of VPN access is granted. It's a lot easier to manage systems if they join the VPN without requiring that a user authenticate to the remote endpoint, but this is kind of a failure of the VPN model - once you're on the VPN, you've got access to everything on the VPN that doesn't require auth, and there's probably (for one reason or another) a lot of that.

As mentioned elsewhere in the comments, using an fTPM (ie, one that's running on the Management Engine or in the Platform Security Processor) would avoid this (there's no convenient low speed bus for you to probe in that case), but I'm kind of reluctant to argue that the tradeoff is worth it.

Good job describing the breakin to the laptop, but I was disappointed when I read that after bootup it auto-connects to the corporate network, nothing like Okta or Yubikey or something else needed as an authentication step. That made things too easy and seems like bad security practice.

The 'stolen laptop' attack vector, as well as 'evil maid' attacks are my general security nightmare in professional environments.

Users are told how the security works, but OpSec is _difficult_. Which means it'll only take that one time the user is lazy and an attacker gets lucky.

Really good article. It's interesting that TPM communicate is over SPI and also unencrypted. Goes to show you're only as strong as the weakest link.

The "CMOS" on the same bus as the TPM was Macronix Serial Multi I/O (MXSMIO™) Flash

https://www.mxic.com.tw/en-us/products/NOR-Flash/Serial-NOR-...

Why they used that (clever) sticky-keys trick instead of cracking password in the SAM database (the local admin password), sorry if my question is dumb.

I'm honestly surprised it was this hard to hack. Seems to me without a bitlocker password the hard drive automatically decrypts at boot, rendering the encryption completely irrelevant. The low hanging fruit should be finding a way through the windows login.

Ah, very clever. Targeting the TPM to bypass FDE. Looks like having a disk encryption password is key. I used to have my boot partition encrypted with the same password as my primary user and it looks like even that would have thwarted this.

Something like half of the comments are recommending using a password for the FDE key instead of the TPM. I thought that it wasn't normally recommended to use a hand-entered key directly, since they wouldn't be expected to have enough entropy for FDE. The better solution would be to store it on a TPM behind a password, where the password check happens inside the TPM, and it can destroy the FDE key after too many wrong attempts. And uh, not send the password unencrypted to the OS over an interface that can be tapped with electrical leads on the motherboard.

This sort of thing is a reminder that your internal network should be kept as clean and secure as possible. Perimeters (physical or virtual) are nice but they're only a first line of defense.

So many people have this mental model of a castle with a moat and inside the network it's unpassworded database servers and control panels, the same default password everywhere, etc.

You can do real damage even without this level of sophistication or physical access: my state's largest hospital system had a month-long computer outage because of a ransomware attack. It was traced back to an employee opening a malicious email attachment on a hospital-owned laptop while they were on vacation.

It brought down the medical records systems and cost the hospital between $40 million and $50 million (mostly in lost revenue because they basically had to cancel non-emergency visits and procedures across multiple locations for a month). Quite an expensive email!

https://vtdigger.org/2021/07/21/malware-on-employees-company...

A fantastic and thorough write up of taking a company laptop and breaking into a corp network. They even used a few methods and tools I hadn't heard of before. A fun read for the security folks. (Or anyone security adjacent)

It always bothered me that companies issue developers laptops. Why not desktops? Sure, it enables the free-wheeling, hot-desking, impromptu meeting culture that exists in most software development teams, but is that a good thing?

undefined

I'm assuming (or hoping) that access to this "internal network" doesn't automagically mean access to services on this network? Surely you require authentication for pretty much everything?

Two things that I took away from this:

1) Physical access = Pwned

2) Determined attacker = Pwned

undefined

If you want your story to be read, you should chose contrasting colors instead of light grey against a white page. Why am I even having to say it?

So would it be more secure to enter in the bitlocker passphrase at boot rather than rely on tpm?

>Trojaned PDFs

Excuse me, but what? What code executes when reading a pdf?

The plain text SPI seems to be guilty. Could fTPM help?

Any idea how hard would the equivalent be on a mac?

Company networks still exist?