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.
> I used to have my boot partition encrypted with the same password as my primary user
You say that as if it's not a good idea, but in the absence of external factors (password being used elsewhere or a hash stored somewhere e.g. for corporate SSO), using the same password shouldn't really diminish the security of your setup.
You're more frequently entering the primary user password (screen unlocking, logins, sudo...) so there are substantially more opportunities to observe it either visually like over the shoulder or from camera footage, or through a compromised machine fully online.
Generally the FDE is unlocked in an offline and minimally functional state, and being a one-time entry @boot kind of thing it's far more practical to secure with things like a temporarily connected crypto hardware dug out of your bag or somesuch.
There's clearly some value in making them different.
That's how the original "unhackable" Xbox was broken. The encrypted firmware was decrypted by hardware in the south-bridge but sent unencrypted to the RAM via the open hyper transport bus. So someone hooked a fast logic analyzer to the bus and read the firmware during boot.
Well, the encrypted second stage firmware was decoded in software by a plaintext ROM stored in the southbridge that contained the keys. That 512 byte southbridge ROM also didn't do quality asymmetric crypto, so by dumping the RC4 key (and in later revisions the TEA hash digest) they were able to decrypt the main firmware in flash and replace it with arbitrary code.
With today's consoles, it's sort of assumed that the attackers will get read access to the first stage boot loader, so they use public keys to validate any stages not originating from the CPU die itself. Then attackers can't replace follow on stages even with read access to the first stage.
It depends. My expectation is that the TPM holds a key that's used for FDE, and if you have a password that password is used to get that key. So the password will only increase security if it's used to encrypt the TPM's key, but if it's just used to authenticate to the TPM, it wouldn't.
Someone more familiar with TPM 2.0 could likely answer this authoritatively, but my assumption is that it's the latter.
Properly leveraging TPM 2.0 features would likely be the best way to solve this problem.
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.
Well, only insofar that you trust that your own corporate laptops don't contain sensitive data on the disk.
I am really happy to know my laptop isn't vulnerable to this (luks-based system), but I am very concerned with the potential (in)security of my collegues' laptops due to common use of corporate laptop hardware for software development and technical customer support.
True we have only started using password managers in the last 6 years or so. But what I meant was that a proper VPN with forced MFA setup and strict ACL makes most of those credentials useless.
It should be noted that if you were able to compromise the OS login credentials you also have access to most browser password managers, and as a feature many 3rd party managers also let you unlock with the user password… so in this case those are compromised too.
Firefox uses a master password for its password store and stores them in own encrypted sqlite database. Chrome stores them using system keyring, which is ok in linux, not so fine in windows.
> this article only gives me a sense of safety for our own corporate laptops
Because you don’t use any “enterprise-grade” commercial security solutions on them, no tele-support, no lights out remote management, no antivirus or anti malware, no firewall, no VPN, no nothing?
Because if you have any of that, you almost certainly have holes like this one.
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
> [...] it appears that OpenZFS encryption is far stronger than LUKS or VeraCrypt encryption.
> LUKS and VeraCrypt use the XTS mode of encryption, which is not authenticated, and is vulnerable to some limited recovery of information when an attacker can have access to the encrypted data at different times. On the other hand OpenZFS encryption is authenticated and at the state of the art. Also, you should take care to disable compression when encrypting with OpenZFS.
OP said the other way around. We all know encrypted data does not compress well, but why would you need to disable compression when encrypting? Compressed data should actually be a smaller dataset hence encrypting it should be even faster.
In general, if the size is then visible after encryption, you can tell that the data, whatever is was, compressed well. This is information leakage, and can, IIUC, be exploited to surprising degrees.
This doesn't make any sense. Here you have a disk. It's compressed or not, doesn't matter, the size stays the same. Then you use BitLocker on it. Again, compressed or not, after BitLocker encrypts it, the size is still the same. Your point?
Like I said, “if the size is visible after encryption”. I don’t know if this is a huge issue with block device encryption in general, but then again, OpenZFS isn’t really only a block-device-level driver, is it? I would not be surprised to hear that OpenZFS somehow encrypts on some higher level than the whole block device.
Compress then encrypt opens up one important vulnerability: if an attacker can control a part of what you're encrypting (which they perhaps can on an average laptop drive, think a cookie in a webbrowser), and they can observe the size of the message after it has been compressed and encrypted, then with repeated attempts they can guess part of your secret and wait until the compression algorithm succeeds in matching part of their data with your secret.
TBH, with whole-disk encryption I would not worry too much about this attack (the threat model is almost always theft where repeated observations of the cryptext after being modified by someone with the key are not practical), but it was core to a lot of vulnerabilities that basically forced TLS-level compression to be almost universally disabled.
An attacker could inject known plaintext to an unknown source and observe the size of the ciphertext. If the size doesn’t change much, it means the chosen plaintext is correlated with the source. Several variants exist.
Paul Le Roux probably isnt satoshi, but he is a very interesting person. The article series "The mastermind" goes into some depth about what he was up to:
My corp laptop auto-locks the screen (if that's what you mean), but can also be unlocked by biometrics, but only if it's already on. (And only for a limited time; I think after a week, the password is required again.) If the laptop is booting fresh, the password is required.
I always switch off the biometric access of any machine, so you can save yourself the hassle of cutting off my thumb or trying to unlock a device when I am asleep.
I guess you could hope for their decency to cut off bits only after they've killed you. Combine that with their possible (probable?) stupidity to assume you have biometrics enabled, and they might kill you without even asking for any password, so you'd die secure in the knowledge that they'll never crack your data.
In other words, you didn't report a touchpad malfunction that was interfering with obvious and clearly stated security policies, and allowed the malfunction to interfere with your work for days/weeks/months without seeking assistance from IT?
This is not a good look, but if that's how you want to play the game of lying to your employer, fine with me!
What do you mean by process ID? A PID seems like a useless bit of information. Now an app bundle or process executable checksum... Seems more useful. But couldn't you build the app from source and add a but of random data into the executable?
Yes it's better to have a hardware fix, like a USB stick that moves the cursor regularly or sends a key press, or even just put your mouse on top of a watch that has hands.
Oh boy, I see the potential for very weird bug reports that will be fun to debug when you forget that that thing is active (or another user is using the computer).
I just 3D printed a little clip that holds the scroll lock key down. Or, there’s always the mechanical or electronic mouse jigglers you can buy off of Amazon.
Windows Powertoys has an Awake applet that does the same thing nowadays. Same thing as in, has the same effect of keeping the machine awake, that is; dunno how it does it, if it's simulating a keypress or something else.
As someone currently fighting with IT because of their 64 character password and a Global Policy for a 5 minute timeout, I would be so happy to have 10 minutes.
Perhaps the mouse jiggler IS the answer. Not to solve your own plight as a result of the policy by using one, but to illustrate what lengths people are going to in order to mitigate the undesirable effects of the policy.
Depending on the desk, a downward facing bass speaker and a raspberry pi+webcam that detects your presence could do the job while maintaining an airgap (assuming you're using a mouse, not a trackpad).
The naive approach is to look at device ID, but article already talks about copying identification data, and the rest of USB descriptor is trivially copyable as well.
Is the system going to have a rule like "mouse moves same amount of pixels with equally spaced pauses"? But what if they randomize motion commands and intervals between them?
Probably they are lot more advanced then they used to be, but yeah, checking for device ID / Process ID in combination with binary (.exe) and location.
Typically these Programs are portable (no installation required, just run the .exe.) and on a corporate machine there are not many places to store it (typically within your user profile).
Programs like "Process Explorer" and "Process Monitor" will give a great amount of detail on processes which can be used for detection.
The linked device is a hardware mouse jiggler, not software. USB devices are easy to imitate, so such a jiggler could be programmed to look like, for example, last year's most popular wireless mouse.
64 character password... no. I get it for password cracking purposes but they should make it hard to ever move to that stage in the first place.
If they are stuck on that policy, they should give you a smart card/yubikey heck even a fingerprint reader (You can't rotate these :-p ) to unlock your device.
You will just end up copying and pasting it around. I'd rather avoid that as there's many ways to copy out your clipboard with Javascript or a malware payload that somehow got onto your host.
I don't understand these insanely long password requirements. How are they more secure than say a strong 8-char password?
Even with a 12 password policy I see most people just using 'MyP@ssword2021', so I guess with 64 characters most people will just use 'MyPassword(012..9){6}'
> you should have an external password necessary to unlock the drive; not a TPM.
i thought the whole point of hardware oracles like TPMs was to avoid loading a PSK into RAM, making removable RAM sticks simple non-destructive attack vectors.
I.e. it's not uncommon for you password to be used to decrypt an encryption key which then lives in RAM and is used to decrypt data. So as long as you "just" have a TPM then it's not preventing that attack wrt. full disk encryption. For it to do so you need either a secure module on you hard-drive (and trust that module) or need to pipe all disk I/O through the TPM (and hope it's fast enough). Through there are (should be?) some hybrid models.
Anyway you can combine both a TPM and a external password (in different ways depending on how the encryption is done).
One additional common reason against using a TPM for full disk encryption is if you want to make data recoverable even if you TPM (motherboard/cpu) fires itself.
I would say for most companies the benefits of requiring a password (or better HSK + PIN) for boot instead of only a TPM are outweighing the risk of a RAM removal attacks. Especially if combined with intrusion detection and short times between suspend and full (non hybrid) hibernation.
Out of curiosity and to ameliorate my ignorance -- does LUKS on Linux keep the keys in the processor's SME all the time? How easy is it to just encrypt everything in ram?
> How easy is it to just encrypt everything in ram?
It's a feature of modern server CPUs which have a AES-128 encryption engine directly embedded in the memory controller (and combine that feature with virtualization, i.e. different encryption keys for different VM).
> does LUKS on Linux keep the keys in the processor's SME all the time?
The LUKS mater key is kept in the Linux Kernel Keyring and while I'm 90% sure that at least when accessing a encrypted partition it's in RAM.
I also would guess that the large majority (all?) of on-the-fly disk encryption software suites/libraries have this problem.
The only way not to have this problems would be to pipe all disk (data) I/O through a fast encryption engine connected to the TPM. And as far as I know this is not part of the TPM feature set(1) (the fast, high throughput part). But then DRM has kinda similar requirements, so maybe I'm wrong.
Through IMHO most companies and people in most situations don't have to worry about RAM extraction attacks as they are way to complicated and brittle, especially if combined with e.g. case intrusion detection and suspend-to-disk automatically after some time. Through as far as I remember it played a role in some "police extracts chats from locked iPhone" cases.
(1): TPM is besides some features around attestation and early boot mainly a from of Hardware Key Store, so e.g. if you use it to sign a blob you don't pipe the blob through the TPM but you (cryptographically secure) hash the blob and then only sign the few bytes long hash by passing it through the TPM. Similar encryption is normally done by doing a AES encryption of a blob and then encrypt the few bytes long AES key using the TPM. But again, I'm not a expert in that area and thinks might have changed, but I guess they haven't (I would be surprised).
TPMs aren't fast enough to do disk encryption at anywhere near the speed of modern storage, so a TPM-based FDE key is simply something that the TPM decrypts and hands back to the OS.
If you know of tpm 2.0 features that have the disk encryption and decryption occurring in the TPM chip itself then please enlighten me. I have not heard of that.
Using a tpm without such features in order to improve a disk encryption setup to the same or above that of a password is difficult and full of problems, and there are some distinct drawbacks. There is a reason why Microsoft bitlocker is primarily intended to protect a users home directory after they have provided a password. If the pin to the tpm is in clear text on the disk, and all the tpm is doing is converting that pin to a password to unlock the disk, the benefits are generally small.
I find it interesting that because they used SPI sniffer, CPU memory encryption features would not have prevented the attack. Looks like all communications between PC components need to be encrypted
actually tpm 2.0 can build a secure communication channel to send the key to the cpu and thus makes that a unlikely attack. of course there are many more attack vectors, but this possible one can be prevented with a correct communication channel.
https://trustedcomputinggroup.org/wp-content/uploads/TSS_ESA...
macOS FileVault is also a good option for whole-drive encryption, as the hardware then requires the external password in order to unlock the drive to continue booting.
> 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.
Back when I worked at MS, a PW was required on boot to deencrypt the drive.
I am honestly shocked that isn't the default for bitlocker. But then again it does require people to have a unique bitlocker PW, and if they ever forget it, everything on the machine is gone for good. (Which I've actually been bitten by, oops!)
I don't recall whether or not it's the default, but Bitlocker can do this on domain-joined machines-- they get automatically backed up into Active Directory where they can be retrieved from the computer account's properties (or there's a tool in RSAT that can find them).
> But then again it does require people to have a unique bitlocker PW, and if they ever forget it, everything on the machine is gone for good. (Which I've actually been bitten by, oops!)
I am not sure if it was the same system, but at a company I worked for we also had a boot password for bitlocker. People would sometimes forget it or bitlocker would somehow corrupt itself. IT was usually able to fix it though. I believe they were able to print out some kind of longer master password that could be used to unlock the machine.
That would probably be the recovery password, which is a long string of gobblydigook. In corporate environment, the recovery password is backed up to the user's Azure AD account and logged by the configuration manager (like InTune, probably 3rd party ones too).
Commonly machines will be configured (via Group Policy) to store their Bitlocker recovery keys in Active Directory (where they are readable by only privileged users).
(It would be nice if MSFT would do with Bitlocker recovery keys what they do with EFS recovery keys, and encrypt them with a public key. At that point popping Active Directory wouldn't be enough to get Bitlocker recovery keys-- you'd need a private key that, hopefully, was stored offline or in an HSM.)
It isn't, and you are misparsing the sentence in the article (it is saying the configuration as it was is the default, but describes it through what it's not, which makes the sentence a bit confusing) - look at the linked Microsoft documentation for confirmation.
Even though it decreases security substantially, they can still use lots of fancy words in the technical description, and only someone with knowledge in the field will understand how most of it is BS.
Bitlocker actually has multiple keys. There's one key to encrypt your data. There's a volume master key that encrypts the data encryption key. And then there are zero or more key protectors for the volume master key. One of those can be the TPM (or TPM with PIN), one can be a long password, one can be a recovery key (IIRC 48 decimal digits), and I believe there are other options as well. Each one is independently capable of decrypting the volume master key, which in turn decrypts the data encryption key, which in turn decrypts the data.
So ideally you'd just get your recovery key and store it someplace well protected like a safe or a password manager.
i think passphrases are better for any situation where you might be typing them in multiple times a day.
since you can use all lowercase letters, it makes it much quicker than having to press the shift key for capitals or symbols, and you can make up for the lack of those characters by using a longer words/passphrase
on top of that i usually spend a bit of time choosing words that are quicker to type. like words that have letters that alternative between each hand seem to be quicker than typing a word that's only on one side of the keyboard. avoiding words that have double letters for the same reason. making sure the end of one word and the start of the next are typed with different hands. choosing words where most of the letters go in the direction of your pinky to your index finger if possible
This is a whole other topic, but if you are choosing what words to use, the words are no longer random, and your password (sorry, “passphrase”) is no longer as secure as mere word counts might lead you to believe.
If you insist on choosing words, you must compensate for this by choosing more words; i.e. having a longer passphrase. Exactly how many bits of entropy you lose by manually choosing words is hard to say without knowing your exact criteria for choosing, but it can be calculated exactly if these are known.
Pick 5 random words from the top 10,000 most common English words, and you have just a bit more entropy than a password composed of 8 random printable ASCII characters.
Is there a brute force list out there that tires all the words (from diceware lists) that people are more likely to choose, and in the orders that they would choose them, etc, first? Its does seem very hard to quantify how much you lose by cycling through passphrases until you get one that feels like you could remember it.
Personally I just make very long passphrases, and memorize them to tunes of songs. Its good typing practice everytime I boot up. Three times wrong and you have to restart.
yea that's definitely something to keep in mind. i usually try to use a few different word generators and also throw in a random character somewhere or spell a word in my own way just to make it a bit less predictable
We're already at the point where any phrase from any book ever written is probably insufficiently secure. (Mixing phrases from multiple books might work.)
We've got a few parameters to work from here:
- By a Google Books estimate from some years back, there were roughly 140 million books ever published. That's been going up by ~1--5 million a year for the past decade or so (only about 300k are "traditionally" published). See Bowker.
- If we limit ourselves to a reasonable canon -- the 100, or 1,000, or 10,000 most-frequently-read books, that number goes down a lot. (Twenty years ago when I had this conversation at work with a user, I said "a phrase from Alice in Wonderland isn't obscure enough. They'd chosen lines from "Jabberwocky", and no I'd not run a cracker.)
- A typical book runs about 250 pages, at about 500 words per page, and about 10 words per sentence. That's about 125,000 words, or 12,500 sentences, per book. Even assuming no sentence ever repeats (they do), that's "only" about 1.7 billion sentences in all published books. For the top 10k, it's only 125 million, the top thousand and 100 are 12.5 and 1.3 million respectively.
Computationally and cryptographically, those are small keyspaces.
Oh: and many of those books are scanned and OCRed. ZLibrary (from which LibGen and other sources pull) has over 8 million books (http://zlibraryexau2g3p.onion/) --- approaching that of a substantial university library collection (The University of California library system has 40.8 million print volumes across 10 campuses and 100 libraries, with 4.3 million digitised in HathiTrust: https://libraries.universityofcalifornia.edu/about/facts-and...).
Randomly-gathered words (EFF Diceware or xcdpass, see https://www.eff.org/dice or https://pypi.org/project/xkcdpass/) are robust --- we don't just combine words at random typically. And as mentioned, joining phrases from different books should be reasonably memorable (combinatorics work in the defender's favour).
That's what I do: LUKS and a (complicated) password needed to decrypt the drive.
Now TFA says it took 30 minutes and that's within the timeframe of an "evil maid attack".
If we take the same 30 minutes, then it's doable to: dupe the SSD and install a physical keylogger between the laptop's keyboard and the laptop's mobo, put back the laptop in place while looking like nothing happened. Then on the next login, when the person enter his password to decrypt the SSD, have the physical keylooger emit (radio?) the password.
Some may say it's science fiction but in TFA in 30 minutes they opened the laptop and hooked an analyzer to the TPM.
I guess what I mean to say is: it's hard to be safe in the face of an evil maid who has 30 minutes of access to your machine.
> 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.
TPM is fine, but you need to set a PIN to unlock the TPM. If you have a TPM without a PIN, somebody can just swipe the whole machine. PIN guesses are rate-limited by the hardware itself, so the PIN can generally be faster and easier to enter than a complex passphrase without compromising security.
IMO: TPM+reasonably random PIN offers comparable security to a strong password without a TPM, and better security than a weak password without a TPM. I prefer TPM+PIN since it's easier to enter 5-6 digits at boot versus a big complicated passphrase, but it's personal preference. TPM without a PIN is pretty useless though.
You could get almost the same benefits and none of the drawbacks of a TPM by using a password hash function with enough complexity to inherently limit the number of checks possible per second.
I can't think of a key derivation function which would reliably make, say, a 6 digit PIN tough to crack while also not painfully impacting user experience waiting for the machine to unlock at boot. For a 6 digit PIN it's only 10 million iterations to exhaust all possible options, and the attacker gets to parallelize their guesses if they're willing to throw hardware or cloud resources at it.
Totally! And for a user that knows the importance of a secure password, that's fine. But the average user in an organization picks terrible passwords. A random 5 or 6 digit PIN generated by the IT department (to avoid the user picking their daughter's birthday) used to lock a TPM is generally easy to remember and secure, especially if a lockout policy is set on the TPM.
I agree that for the user who would pick a secure passphrase, it's comparable security either way and thus really comes down to preference. I like tapping a quick PIN on the numpad rather than typing out a passphrase, but I can definitely see the advantages to the passphrase approach: you don't have to depend on a piece of hardware specific to the machine, and the attack surface for a potential backdoor is a lot smaller, especially if you're using FOSS full disk encryption software like Veracrypt.
Pins vs passwords are not something I have seen much discussion on in the software security space. The only general criticism I have heard of pins is that people tend to pick dates when asked to use a random 4-6 digit sequence, which makes them often trivial to guess. Personally I have always leaned towards the now classic xkcd method of combining 3 random words, which can often lead towards funny and memorable passwords with great length. The only major drawback is that they take long time to type, is a pain with touch keyboards, and are prone to miss clicks in low light conditions.
The biggest issue I have with TPM is that it's overly sensitive to the device configuration. Plug in an extra mouse at boot and I'm locked out of BitLocker (it asks for the recovery key). That's too dangerous for my data, at least for my personal use. VeraCrypt works better in that aspect.
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)
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.
Coworkers of mine did a recruiting trip to <untrusted country> and were told by corporate: do not bring your laptops. We'll provide you with laptops when you get there to use for the week. Any laptop you bring stays there because we don't trust that you didn't leave it alone in a hotel room at some point. And if that happens, we presume it's compromised.
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!
Agreed - I don't like the way we've shifted responsibility to the hapless employee away from whoever wrote, purchased and approved the vulnerable piece of software that actually was exploited here.
I disagree. The expensive choice was deciding not to hire skilled security engineers and not giving them political capital to do their jobs. The root cause of the attack is dysfunction in the organization.
Many companies actually have guys like this, but they work in internal IT and are chronically understaffed. Security isn't on the mind of people when they complain about a misbehaving printer.
Fake mail with infected attachment is still the usual way for ransomware if it isn't an inside job or a weakly protected service account from another compromised partner.
Best defense is working backups with regular snapshots. Patient data would still be exposed and I think the only way to mitigate this is collecting the lowest amount of data possible.
Ideally patient data is encrypted in a way that the patient himself would need to provide the password to access the information as just-in-time decryption.
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.
Many newer models of laptops, especially those being deployed in the enterprise have the ability to reset the BIOS locked out as well, to prevent explicitly the attacks suggested in the OP.
Most enterprise machines (Lenovo Think, HP Pro/Elite and Dell OptiPlex/Vostro) will have a hardened BIOS that you can't reset unless you have proof of purchase of the machine.
For HP this is not true. In college I rescued 2 HP EliteBooks from the e-waste bin and both had locked BIOSes. It was as simple as buying a cheap SPI programmer (I got a CH341A-based one) and dumping the BIOS chip, then unlocking the dump with a tool called HPUnlocker, and reflashing it.
Didn't even need to solder because the programmer came with a chip clip. These were EliteBook 840 G2s, but modern EliteBooks are still vulnerable to this.
At least for Lenovo/IBM, that's what they want you to think; but anyone with knowledge of the third-party repair industry knows that isn't true at all:
That is very old information and not up to date (newest laptop in that list is 14 years old). Resetting a BIOS password for newer models requires a bit of voodoo (booting up with what looks like a debug BIOS to retrieve info from somewhere else in the system).
Interesting. I've always assumed that resetting BIOS settings, including the password, is as easy as removing the battery regardless of how modern the machine is.
I believe it's still that way for low-end machines. For higher end ones, there's some range of security-by-obscurity to actually secure. And a bunch of tools to circumvent, ranging from open source (like the one I referenced), hardware assisted, to pay-per-unlock services.
Some high end machines also have specific solder points you can ground out during boot, but it's not shorting a battery, it's setting a GPIO state.
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.
Using a password with a per-filesystem salt and a modern key derivation function will be just fine here - the key derivation is expensive enough that brute forcing the key isn't practical, even assuming relatively weak passwords.
The way I understand full disk encryption (with LUKS at least) is that the device generates a random key which does the data encryption/decryption and the user entered password is used exclusively to encrypt that key. This allows encrypting the key with thousands of iterations (the number is picked in a way that it takes a few seconds on the currently used CPU). That way you can use a very slow encryption algorithm (meaning it's very slow to brute force) to get the actual key, which can then be used for fast encryption of the actual data.
This approach also allows changing passwords or using multiple passwords without rewriting the entire drive, since just the key has to be re-encrypted
Ah yeah that makes more sense. I suppose managing FDE key via TPM is theoretically / ideally more secure, but has a lot more attack surface. Probably not many TPM implementations have been attacked enough publicly for anyone to be confident they're actually more secure than a regular password with good modern KDF.
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.
Yes, this is a (rare) case where fTPM has better security properties.
For context: fTPM refers to a software-based implementation of a TPM running in an execution environment the OS has no direct access to. On Intel hardware, this is on the Management Engine - depending on the specific CPU range, this will either be on the CPU package or in the motherboard chipset. On AMD systems, it's running in the Platform Security Processor, a separate ARM core that's on the CPU package. For ARM systems, it's generally running on the main execution cores but in the TrustZone environment. In all these scenarios the TPM code is running in the same environment as a bunch of other code that exposes some additional attack surface, so seems less appealing than a discrete TPM. On the other hand, the sort of attack described here is probably impractical unless you have much higher end equipment.
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.
Pin + Yubikey. Not certain whether you can use a Yubikey without a pin, but I think it's important to specify: something you have plus something you know.
The reason: the newer yubikeys don't ever leave the usb port. Mine is almost impossible to remove. And if this attack is based on a stolen laptop then chances are the yubikey comes with it.
Yubikey is not something popular in enterprises. At least not the ones I worked for. I only heard about it because Google uses it (or something similar).
My company uses Okta Verify. So when the bad guy tries to connect the hacked laptop to the corporate network VPN, the person who was assigned that laptop gets a "Login attempt, is that you?" message on their cell phone (if the push method is used) or is prompted for the 6-digit code, and it doesn't connect until confirmation is received. Unless someone can defeat it somehow.
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.
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?
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?
I've been saying for about 10 years now: make your network public, and use actual authentication on things that need access control. Visitors using your wifi? No problem, since your wifi is just another part of the internet as far as your threat model is concerned.
Yes! I concur wholeheartedly, and I regret that I have but one upvote to give. To contribute something, here is RFC 3724, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture":
That’s really the whole idea behind BeyondCorp (Google’s model) and numerous other Software Defined Perimeter and Identity Aware Proxy architectures.
There is actually a pretty big shift in corporate networks going on right now, originally driven by IaaS and SaaS adoption (if your applications and data don’t live in your own data center, what is your ‘private network’ doing for you?). This change has been massively accelerated by WFH/COVID in the past 18 months.
Yes i know... i was just surprised it was referred to as the "CMOS"
my curiosity got the better of me and i looked it up and thought other people might be curious too, and I thought it might save people time if I gave the details
But the connection only make "easier" to connect to much larger pins, a determined attacker would be able to connect to the SPI bus even on the teeny-tiny TPM cheap directly, it's only a matter of having some more sophisticated hardware, risking doing a chip-off, etc.
Only as an example (and not actually usable in this case unless a chip-off is done), there is what I call a cross-breed between an octopus and a acupuncturist:
The code in a PDF reader executes when reading a PDF. So, things like evince, Preview.app and their dependencies. These things may have bugs that can be vectors of attack.
(Not sure if your question meant code inside a PDF? If so, you'll find that PDFs can contain JavaScript which is executed when opened.)
Ugh, didn't know about that. Do you know if there exist any tools that can strip PDFs from all this bs? Also, I assume most readers are actually sane enough not to run any pdf scripts?
212 comments
[ 3.1 ms ] story [ 255 ms ] threadYou say that as if it's not a good idea, but in the absence of external factors (password being used elsewhere or a hash stored somewhere e.g. for corporate SSO), using the same password shouldn't really diminish the security of your setup.
Generally the FDE is unlocked in an offline and minimally functional state, and being a one-time entry @boot kind of thing it's far more practical to secure with things like a temporarily connected crypto hardware dug out of your bag or somesuch.
There's clearly some value in making them different.
With today's consoles, it's sort of assumed that the attackers will get read access to the first stage boot loader, so they use public keys to validate any stages not originating from the CPU die itself. Then attackers can't replace follow on stages even with read access to the first stage.
Someone more familiar with TPM 2.0 could likely answer this authoritatively, but my assumption is that it's the latter.
Properly leveraging TPM 2.0 features would likely be the best way to solve this problem.
So while the TPM hack was very impressive, this article only gives me a sense of safety for our own corporate laptops.
I am really happy to know my laptop isn't vulnerable to this (luks-based system), but I am very concerned with the potential (in)security of my collegues' laptops due to common use of corporate laptop hardware for software development and technical customer support.
Keep in mind that it was a sanitized laptop with no actual data on it, built for the test.
A random employee's laptop? Probably has all sorts of goodies. Don't get complacent.
Like a PASSWORDS.txt file on the desktop which said employee uses as a password manager.
Or my personal super advanced, high security method - keep it in the 'drafts' folder.
So just fire it up, and access the passwords. The on disk encryption is pretty redundant.
Because you don’t use any “enterprise-grade” commercial security solutions on them, no tele-support, no lights out remote management, no antivirus or anti malware, no firewall, no VPN, no nothing?
Because if you have any of that, you almost certainly have holes like this one.
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
https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_...
> [...] it appears that OpenZFS encryption is far stronger than LUKS or VeraCrypt encryption.
> LUKS and VeraCrypt use the XTS mode of encryption, which is not authenticated, and is vulnerable to some limited recovery of information when an attacker can have access to the encrypted data at different times. On the other hand OpenZFS encryption is authenticated and at the state of the art. Also, you should take care to disable compression when encrypting with OpenZFS.
This is new to me, why?
Random binary data doesn't compress very well, sometimes even negatively.
TBH, with whole-disk encryption I would not worry too much about this attack (the threat model is almost always theft where repeated observations of the cryptext after being modified by someone with the key are not practical), but it was core to a lot of vulnerabilities that basically forced TLS-level compression to be almost universally disabled.
There have been what’s called “compression oracle” attacks on SSL with compress then encrypt scheme, see CRIME
https://en.m.wikipedia.org/wiki/Oracle_attack
An attacker could inject known plaintext to an unknown source and observe the size of the ciphertext. If the size doesn’t change much, it means the chosen plaintext is correlated with the source. Several variants exist.
Compression is often not recommended in VPNs.
https://magazine.atavist.com/category/Mastermind/ Recommended reading!
https://blog.elcomsoft.com/2021/06/breaking-veracrypt-obtain...
Disk encryption is generally in XTS mode, and not authenticated. That’s not limited to veracrypt.
There are several different products on the market, and a variety of ways that native solutions like Bitlocker can be configured.
Is that an unreasonable burden on people?
I wouldn't call it a burden.
I always switch off the biometric access of any machine, so you can save yourself the hassle of cutting off my thumb or trying to unlock a device when I am asleep.
Though Idunno how happy that'll make you.
The idea is that basically very few keyboards have an F15, let alone applications that rely on the F15 key.
This is not a good look, but if that's how you want to play the game of lying to your employer, fine with me!
If you want to lock your PC you need to lock it.
I feel like since I'm on the security team, I should find a non-exploit method to actually resolve the policy failure.
...and now I have a project for this weekend.
The naive approach is to look at device ID, but article already talks about copying identification data, and the rest of USB descriptor is trivially copyable as well.
Is the system going to have a rule like "mouse moves same amount of pixels with equally spaced pauses"? But what if they randomize motion commands and intervals between them?
https://docs.microsoft.com/en-us/sysinternals/downloads/proc...
https://docs.microsoft.com/en-us/sysinternals/downloads/proc...
There is no device ID, process ID or binary to match.
If they are stuck on that policy, they should give you a smart card/yubikey heck even a fingerprint reader (You can't rotate these :-p ) to unlock your device.
You will just end up copying and pasting it around. I'd rather avoid that as there's many ways to copy out your clipboard with Javascript or a malware payload that somehow got onto your host.
Even with a 12 password policy I see most people just using 'MyP@ssword2021', so I guess with 64 characters most people will just use 'MyPassword(012..9){6}'
https://www.my1login.com/resources/password-strength-test/
Along with this:
https://www.random.org/strings/
and I discovered that apparently, a 7 character password of random chars that includes a 0 (zero) is really hard to crack!
I wont be doing that though for my own passwords but it was interesting none-the-less.
I hope they also have a 30 day password expiry policy as well. Dont want users to get too comfortable with their password.
I currently work from home.
Habits are important. I also put on my parking break every time I turn off my car!
So, IMHO, not an unreasonable burden!
i thought the whole point of hardware oracles like TPMs was to avoid loading a PSK into RAM, making removable RAM sticks simple non-destructive attack vectors.
I.e. it's not uncommon for you password to be used to decrypt an encryption key which then lives in RAM and is used to decrypt data. So as long as you "just" have a TPM then it's not preventing that attack wrt. full disk encryption. For it to do so you need either a secure module on you hard-drive (and trust that module) or need to pipe all disk I/O through the TPM (and hope it's fast enough). Through there are (should be?) some hybrid models.
Anyway you can combine both a TPM and a external password (in different ways depending on how the encryption is done).
One additional common reason against using a TPM for full disk encryption is if you want to make data recoverable even if you TPM (motherboard/cpu) fires itself.
I would say for most companies the benefits of requiring a password (or better HSK + PIN) for boot instead of only a TPM are outweighing the risk of a RAM removal attacks. Especially if combined with intrusion detection and short times between suspend and full (non hybrid) hibernation.
It's a feature of modern server CPUs which have a AES-128 encryption engine directly embedded in the memory controller (and combine that feature with virtualization, i.e. different encryption keys for different VM).
> does LUKS on Linux keep the keys in the processor's SME all the time?
The LUKS mater key is kept in the Linux Kernel Keyring and while I'm 90% sure that at least when accessing a encrypted partition it's in RAM.
I also would guess that the large majority (all?) of on-the-fly disk encryption software suites/libraries have this problem.
The only way not to have this problems would be to pipe all disk (data) I/O through a fast encryption engine connected to the TPM. And as far as I know this is not part of the TPM feature set(1) (the fast, high throughput part). But then DRM has kinda similar requirements, so maybe I'm wrong.
Through IMHO most companies and people in most situations don't have to worry about RAM extraction attacks as they are way to complicated and brittle, especially if combined with e.g. case intrusion detection and suspend-to-disk automatically after some time. Through as far as I remember it played a role in some "police extracts chats from locked iPhone" cases.
(1): TPM is besides some features around attestation and early boot mainly a from of Hardware Key Store, so e.g. if you use it to sign a blob you don't pipe the blob through the TPM but you (cryptographically secure) hash the blob and then only sign the few bytes long hash by passing it through the TPM. Similar encryption is normally done by doing a AES encryption of a blob and then encrypt the few bytes long AES key using the TPM. But again, I'm not a expert in that area and thinks might have changed, but I guess they haven't (I would be surprised).
or tell microsoft to use tpm 2.0 features if they force us to use a tpm v2?
Using a tpm without such features in order to improve a disk encryption setup to the same or above that of a password is difficult and full of problems, and there are some distinct drawbacks. There is a reason why Microsoft bitlocker is primarily intended to protect a users home directory after they have provided a password. If the pin to the tpm is in clear text on the disk, and all the tpm is doing is converting that pin to a password to unlock the disk, the benefits are generally small.
Back when I worked at MS, a PW was required on boot to deencrypt the drive.
I am honestly shocked that isn't the default for bitlocker. But then again it does require people to have a unique bitlocker PW, and if they ever forget it, everything on the machine is gone for good. (Which I've actually been bitten by, oops!)
I am not sure if it was the same system, but at a company I worked for we also had a boot password for bitlocker. People would sometimes forget it or bitlocker would somehow corrupt itself. IT was usually able to fix it though. I believe they were able to print out some kind of longer master password that could be used to unlock the machine.
(It would be nice if MSFT would do with Bitlocker recovery keys what they do with EFS recovery keys, and encrypt them with a public key. At that point popping Active Directory wouldn't be enough to get Bitlocker recovery keys-- you'd need a private key that, hopefully, was stored offline or in an HSM.)
manual PIN entry IS the default for BitLocker, and the article states this.
Even though it decreases security substantially, they can still use lots of fancy words in the technical description, and only someone with knowledge in the field will understand how most of it is BS.
So ideally you'd just get your recovery key and store it someplace well protected like a safe or a password manager.
i think passphrases are better for any situation where you might be typing them in multiple times a day.
since you can use all lowercase letters, it makes it much quicker than having to press the shift key for capitals or symbols, and you can make up for the lack of those characters by using a longer words/passphrase
https://www.useapassphrase.com
on top of that i usually spend a bit of time choosing words that are quicker to type. like words that have letters that alternative between each hand seem to be quicker than typing a word that's only on one side of the keyboard. avoiding words that have double letters for the same reason. making sure the end of one word and the start of the next are typed with different hands. choosing words where most of the letters go in the direction of your pinky to your index finger if possible
If you insist on choosing words, you must compensate for this by choosing more words; i.e. having a longer passphrase. Exactly how many bits of entropy you lose by manually choosing words is hard to say without knowing your exact criteria for choosing, but it can be calculated exactly if these are known.
https://pypi.org/project/xkcdpass/
https://www.eff.org/dice
We've got a few parameters to work from here:
- By a Google Books estimate from some years back, there were roughly 140 million books ever published. That's been going up by ~1--5 million a year for the past decade or so (only about 300k are "traditionally" published). See Bowker.
- If we limit ourselves to a reasonable canon -- the 100, or 1,000, or 10,000 most-frequently-read books, that number goes down a lot. (Twenty years ago when I had this conversation at work with a user, I said "a phrase from Alice in Wonderland isn't obscure enough. They'd chosen lines from "Jabberwocky", and no I'd not run a cracker.)
- A typical book runs about 250 pages, at about 500 words per page, and about 10 words per sentence. That's about 125,000 words, or 12,500 sentences, per book. Even assuming no sentence ever repeats (they do), that's "only" about 1.7 billion sentences in all published books. For the top 10k, it's only 125 million, the top thousand and 100 are 12.5 and 1.3 million respectively.
Computationally and cryptographically, those are small keyspaces.
Oh: and many of those books are scanned and OCRed. ZLibrary (from which LibGen and other sources pull) has over 8 million books (http://zlibraryexau2g3p.onion/) --- approaching that of a substantial university library collection (The University of California library system has 40.8 million print volumes across 10 campuses and 100 libraries, with 4.3 million digitised in HathiTrust: https://libraries.universityofcalifornia.edu/about/facts-and...).
Randomly-gathered words (EFF Diceware or xcdpass, see https://www.eff.org/dice or https://pypi.org/project/xkcdpass/) are robust --- we don't just combine words at random typically. And as mentioned, joining phrases from different books should be reasonably memorable (combinatorics work in the defender's favour).
Now TFA says it took 30 minutes and that's within the timeframe of an "evil maid attack".
If we take the same 30 minutes, then it's doable to: dupe the SSD and install a physical keylogger between the laptop's keyboard and the laptop's mobo, put back the laptop in place while looking like nothing happened. Then on the next login, when the person enter his password to decrypt the SSD, have the physical keylooger emit (radio?) the password.
Some may say it's science fiction but in TFA in 30 minutes they opened the laptop and hooked an analyzer to the TPM.
I guess what I mean to say is: it's hard to be safe in the face of an evil maid who has 30 minutes of access to your machine.
TPM is fine, but you need to set a PIN to unlock the TPM. If you have a TPM without a PIN, somebody can just swipe the whole machine. PIN guesses are rate-limited by the hardware itself, so the PIN can generally be faster and easier to enter than a complex passphrase without compromising security.
IMO: TPM+reasonably random PIN offers comparable security to a strong password without a TPM, and better security than a weak password without a TPM. I prefer TPM+PIN since it's easier to enter 5-6 digits at boot versus a big complicated passphrase, but it's personal preference. TPM without a PIN is pretty useless though.
I agree that for the user who would pick a secure passphrase, it's comparable security either way and thus really comes down to preference. I like tapping a quick PIN on the numpad rather than typing out a passphrase, but I can definitely see the advantages to the passphrase approach: you don't have to depend on a piece of hardware specific to the machine, and the attack surface for a potential backdoor is a lot smaller, especially if you're using FOSS full disk encryption software like Veracrypt.
what happens at lockout?
Isn’t it one million?
Sure, the door is locked, but it's still very easy to open.
How might I handle the situation where a given device has been stolen, attacked and returned, without my having observed it happening?
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.
Coworkers of mine did a recruiting trip to <untrusted country> and were told by corporate: do not bring your laptops. We'll provide you with laptops when you get there to use for the week. Any laptop you bring stays there because we don't trust that you didn't leave it alone in a hotel room at some point. And if that happens, we presume it's compromised.
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...
That is such a lame “cause”. What was the actual underlying cause - i.e. what was it that allowed a malicious email to pwn the laptop?
If they somehow need to be able to do that, I presume there is normally some form of sandboxing?
Best defense is working backups with regular snapshots. Patient data would still be exposed and I think the only way to mitigate this is collecting the lowest amount of data possible.
Ideally patient data is encrypted in a way that the patient himself would need to provide the password to access the information as just-in-time decryption.
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.
http://www.thinkwiki.org/wiki/maintenance#Recovering_BIOS_pa....
Some high end machines also have specific solder points you can ground out during boot, but it's not shorting a battery, it's setting a GPIO state.
They couldn't log in, because that VPN tunnel is only open before logging in. So they had to gain access while on the login screen.
They couldn't log in, because that VPN tunnel is only open before logging in. So they had to gain access while on the login screen.
For context: fTPM refers to a software-based implementation of a TPM running in an execution environment the OS has no direct access to. On Intel hardware, this is on the Management Engine - depending on the specific CPU range, this will either be on the CPU package or in the motherboard chipset. On AMD systems, it's running in the Platform Security Processor, a separate ARM core that's on the CPU package. For ARM systems, it's generally running on the main execution cores but in the TrustZone environment. In all these scenarios the TPM code is running in the same environment as a bunch of other code that exposes some additional attack surface, so seems less appealing than a discrete TPM. On the other hand, the sort of attack described here is probably impractical unless you have much higher end equipment.
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.
The reason: the newer yubikeys don't ever leave the usb port. Mine is almost impossible to remove. And if this attack is based on a stolen laptop then chances are the yubikey comes with it.
https://www.amazon.com/dp/B07HBDX2CM
Incidentally, you can also use a paperclip (a chain, even) to trigger a touch without having to touch the key directly.
You can choose, no pin / pin once after plugging in / pin on every use.
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.
1) Physical access = Pwned
2) Determined attacker = Pwned
Rigid rights management would help, but security competes with ease of access.
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?
https://www.rfc-editor.org/rfc/rfc3724.html
There is actually a pretty big shift in corporate networks going on right now, originally driven by IaaS and SaaS adoption (if your applications and data don’t live in your own data center, what is your ‘private network’ doing for you?). This change has been massively accelerated by WFH/COVID in the past 18 months.
https://www.mxic.com.tw/en-us/products/NOR-Flash/Serial-NOR-...
my curiosity got the better of me and i looked it up and thought other people might be curious too, and I thought it might save people time if I gave the details
Only as an example (and not actually usable in this case unless a chip-off is done), there is what I call a cross-breed between an octopus and a acupuncturist:
https://blog.acelaboratory.com/pc-3000-flash-spider-board-ad...
Excuse me, but what? What code executes when reading a pdf?
(Not sure if your question meant code inside a PDF? If so, you'll find that PDFs can contain JavaScript which is executed when opened.)