Still putting your crypto-protected PC in hibernate? $300 app can hack it (Updated)

Attacking strong crypto may soon become a script kiddie exercise.

Cracking PGP, TrueCrypt, and other strong encryption packages just got more affordable, with the release of a $300 package that can pluck decryption keys out of computer memory in certain cases.

Thursday's release of the Elcomsoft Forensic Disk Decryptor poses the biggest threat to people who leave their pre-OS X 10.7.2 Mac laptops or FireWire-equipped PCs in hibernate or sleep states while encrypted drives are mounted. It has long been possible to use the FireWire or Mac Thunderbolt interfaces to retrieve the contents of volatile memory on machines that are password-protected but not powered down. But until now, it has cost closer to $1,000 for an easy and reliable way to use that data against people using strong full-disk encryption programs.

The new product from Moscow-based ElcomSoft changes that. Like Passware, which Ars first chronicled in 2009, it's able to comb through memory dumps and locate the cryptographic keys stored inside. But at a third of the price, Forensic Disk Decryptor could bring that capability to a much larger customer base.

Not quite perfect

Current versions of Passware and Full Disk Decryptor are marketed as being able to extract keys used by PGP, TrueCrypt, Apple's FileVault, and Microsoft's BitLocker. These encryption programs are widely regarded as providing near-perfect implementations of strong cryptography, making them reliable ways for executives and other high-value targets to encrypt single files, drive partitions, or entire disks. But there's a catch: The programs are only able to read or write to encrypted areas by storing a cryptographic key in computer memory. That opens the door to attackers who can access the memory and then ferret out the key. (The ElcomSoft product only isolates the key. Software and hardware for acquiring the memory dump must be acquired separately.)

Forensic Disk Decryptor works best against machines that have a FireWire port, but there are other ways an attacker might also access keys stored in memory. The most obvious alternative is the Thunderbolt interface included on newer Macs. Like FireWire, it also appears to grant users direct memory access, although blog posts here and here report this behavior was quietly fixed in OS X version 10.7.2 (thanks to Ars reader spookware for the links).

On Macs that predate that version, that would make it possible for attackers to carry out the same types of attacks. Another possibility is obtaining a file that gets written to disk just prior to a computer being put into hibernation. If the encrypted disk is mounted during that process, the key is likely to be contained inside the file. A third possible avenue is retrieving a key stored in unencrypted virtual machine memory that gets written to a hard drive.

Marketers at ElcomSoft have gone to great lengths to portray Disk Decryptor as something novel. That's an exaggeration that loses the larger point. While these attacks have been possible for years, they're becoming easier and more inexpensive to carry out. It wouldn't be surprising to see similarly reliable open-source software released in the next few years, assuming it isn't already available.

What this means is that if you rely on strong encryption to protect the contents of a hard drive, you shouldn't leave your computer in sleep or hibernation mode and assume your secrets are safe. In a matter of minutes, an attacker who finds it unattended may be able to dump the memory and retrieve the key, even if the machine is password protected. This capability has existed for years, but it's quickly becoming a script kiddie exercise. People who truly value their privacy and have no use for the FireWire or Thunderbolt ports on their machines may want to consider destroying them, as one savvy computer user has suggested.

Readers should also understand that Forensic Disk Decryptor and similar programs aren't exploiting any vulnerabilities in PGP or the other strong crypto apps being attacked. In-memory key storage is a requirement for the affected programs to work. Still, release of the $300 program means it's easier than ever for someone with access to your PC to rifle through contents you long assumed were off-limits. Remember that the next time you plan to leave it unattended, even for just a few minutes.

Update, December 21, 2012 3:30 California time:

David Finkelstein, Symantec's director of encryption development wrote in an e-mail:

Regardless of what any press release may say, your article incorrectly states that PGP encrypted systems placed into hibernation can be easily cracked with forensic tools.

When a system running PGP Whole Disk Encryption enters hibernation, the hibernation file is stored encrypted on the disk. Any user must re-enter their password (or insert their hardware token and provide the associated PIN) before the system will resume from hibernation. An attacker cannot gain access to the disk key from a hibernated system that is employing PGP Whole Disk Encryption.

He went on to write: "And of course, my comments only apply to systems that have the entire disk encrypted. If you only encrypt a partition (or two), it is possible that the hibernation file (or hibernation partition) is not encrypted."

Windows PCs or Mac Pros with add-in cards are another matter though. The way to make this safe on windows would be for the ACPI routines in the bios to disable DMA transactions when going to sleep. But unless the firewire/thunderbolt is present on the motherboard then the firmware has no way of knowing about those add on devices.

The correct solution for this kind of thing is to use Intel VT-d (aka IOMMU) to limit DMA transactions to safe memory locations. Sadly not all chipsets support IOMMU and Microsoft has not built in support for using it in to Windows.

Surely virtualizing the memory space for Thunderbolt would have solved this problem?

Thunderbolt is basically external PCI-e, that has the ability to do DMA reads/writes to and from main system memory (and anything else in that address space) It is unfeasible to allow access to parts of memory and not others.

It's completely feasible. As spookware noted, IOMMUs are not remotely new tech (a number of Intel chips have has that built in for years now). As is the case a depressingly high amount of the time, the industry has been lazy about actually using the tech without a imminent threat to motivate them. But it's all there and ready to go.

Wait, Thunderbolt still takes whatever RAM addresses are requested at the other end of the cable literally? How was the lesson of Firewire unlearned? Why are supposedly intelligent devices on a bus so heavily coupled together?

At the lowest level of the data layer, thunderbolt is just an external extension of the PCIe bus; and operates below the level of the OS.

The reason TB and Firewire both have such low level direct access to the system hardware is that it's necessary to guarantee low latency on a soft-realtime OS. USB requires CPU intervention to work and has less consistent latency since it's dependent on the OS scheduler to keep feeding it time slices. This gives it a security benefit; but was mostly done for cost reasons. USB controllers can be as dumb as a bag of hammers; firewire controllers need the extra capacity to manage the IO themselves.

For macs this was fixed along time ago. As of OSX 10.7.2 the DMA based attacks no longer work. When the system sleeps the firmware disables DMA transactions.

That's somewhat overstating things, I think. The problem isn't fixed.

OS X as of 10.7.2 does indeed disable DMA transactions when the machine is sleeping or locked. But unlocked machines remain vulnerable. More pertinently, if you switch users using Fast User Switching, even to a Guest user, DMA is re-enabled, and FireWire and Thunderbolt can both be used to dump the system's memory.

To defend properly against this attack, OS X would have to use the IOMMU (VT-d) to hide the passwords somewhere that was simply inaccessible to DMA. Another option would be to use SM memory to store the keys, but I'm not sure how practical that would be (since you probably don't want to have to switch to SM mode each time you want to encrypt or decrypt some data).

Windows PCs or Mac Pros with add-in cards are another matter though. The way to make this safe on windows would be for the ACPI routines in the bios to disable DMA transactions when going to sleep. But unless the firewire/thunderbolt is present on the motherboard then the firmware has no way of knowing about those add on devices.

The correct solution for this kind of thing is to use Intel VT-d (aka IOMMU) to limit DMA transactions to safe memory locations. Sadly not all chipsets support IOMMU and Microsoft has not built in support for using it in to Windows.

If your computer is hibernated, then your memory is already dumped to disk. No need for DMA based attacks.

BTW, Thanks for the info, I didn't know that Apple disables DMA during sleep:-)

Windows PCs or Mac Pros with add-in cards are another matter though. The way to make this safe on windows would be for the ACPI routines in the bios to disable DMA transactions when going to sleep. But unless the firewire/thunderbolt is present on the motherboard then the firmware has no way of knowing about those add on devices.

The correct solution for this kind of thing is to use Intel VT-d (aka IOMMU) to limit DMA transactions to safe memory locations. Sadly not all chipsets support IOMMU and Microsoft has not built in support for using it in to Windows.

The implication of Thunderbolt seems a little vague, to me, though. The linked article says:

Quote:

Because Thunderbolt has the same unrestricted access to the computer, Graham speculates it is vulnerable to the same types of attacks.

Intel processors offer the means to significantly rein in Thunderbolt by restricting a device's access to memory locations of the computer it's attached to. But as of now, there are no indications Mac OS X makes use of this.

So, an expert speculates that Thunderbolt is affected, and says nobody proved the opposite to him. And that was two years ago. A bit weak for Ars' conclusion that encryption breaking is possible through Thunderbolt. Or do any other sources state that?

Wait, Thunderbolt still takes whatever RAM addresses are requested at the other end of the cable literally? How was the lesson of Firewire unlearned? Why are supposedly intelligent devices on a bus so heavily coupled together?

Could TB be maliciously exploited to expand the RAM of recent Macs without paying the Apple Tax?

I seem to recall that PGP bit-reversed the key in memory every few seconds so that it couldn't leave a long-term 'imprint' for later recovery, and also that there was an option to automatically wipe the key from memory so that it was never resident for longer than required. (I could be mis-remembing this, but I can't find the documents now.)

If this is true, then the only way someone could get access to your machine is essentially yank it from your hands while you're using it and immediately access the files. Any other event would wipe the keys from memory.

And since wired access requires either a reboot or at the very least a change in the network preferences, that doesn't seem like a feasible attack vector unless you already have the machine in hand.

Wait, Thunderbolt still takes whatever RAM addresses are requested at the other end of the cable literally? How was the lesson of Firewire unlearned? Why are supposedly intelligent devices on a bus so heavily coupled together?

At the lowest level of the data layer, thunderbolt is just an external extension of the PCIe bus; and operates below the level of the OS.

The reason TB and Firewire both have such low level direct access to the system hardware is that it's necessary to guarantee low latency on a soft-realtime OS. USB requires CPU intervention to work and has less consistent latency since it's dependent on the OS scheduler to keep feeding it time slices. This gives it a security benefit; but was mostly done for cost reasons. USB controllers can be as dumb as a bag of hammers; firewire controllers need the extra capacity to manage the IO themselves.

Surely virtualizing the memory space for Thunderbolt would have solved this problem?

Thunderbolt is basically external PCI-e, that has the ability to do DMA reads/writes to and from main system memory (and anything else in that address space) It is unfeasible to allow access to parts of memory and not others.

Surely virtualizing the memory space for Thunderbolt would have solved this problem?

Thunderbolt is basically external PCI-e, that has the ability to do DMA reads/writes to and from main system memory (and anything else in that address space) It is unfeasible to allow access to parts of memory and not others.

Considering an IOMMU can lock down internal PCI-e, it should be completely capable of locking down Thunderbolt as well (unless Intel for some reason intentionally wired it around it... which would mean they intentionally went out of their way). Of course, the question still remains whether or not current systems actually leverage the IOMMU to do that with Thunderbolt, since it doesn't seem like anyone's bothered to check.

Windows PCs or Mac Pros with add-in cards are another matter though. The way to make this safe on windows would be for the ACPI routines in the bios to disable DMA transactions when going to sleep. But unless the firewire/thunderbolt is present on the motherboard then the firmware has no way of knowing about those add on devices.

The correct solution for this kind of thing is to use Intel VT-d (aka IOMMU) to limit DMA transactions to safe memory locations. Sadly not all chipsets support IOMMU and Microsoft has not built in support for using it in to Windows.

This seems to solve the problem in it's entirety as the FireWire DMA is needed even via Thunderbolt.

"Macs with firmware (OF/EFI) password set is not vulnerable to this attack, as FireWire DMA is disabled when a OF/EFI password is set."

Surely virtualizing the memory space for Thunderbolt would have solved this problem?

Thunderbolt is basically external PCI-e, that has the ability to do DMA reads/writes to and from main system memory (and anything else in that address space) It is unfeasible to allow access to parts of memory and not others.

It's completely feasible. As spookware noted, IOMMUs are not remotely new tech (a number of Intel chips have has that built in for years now). As is the case a depressingly high amount of the time, the industry has been lazy about actually using the tech without a imminent threat to motivate them. But it's all there and ready to go.

Windows PCs or Mac Pros with add-in cards are another matter though. The way to make this safe on windows would be for the ACPI routines in the bios to disable DMA transactions when going to sleep. But unless the firewire/thunderbolt is present on the motherboard then the firmware has no way of knowing about those add on devices.

The correct solution for this kind of thing is to use Intel VT-d (aka IOMMU) to limit DMA transactions to safe memory locations. Sadly not all chipsets support IOMMU and Microsoft has not built in support for using it in to Windows.

If your computer is hibernated, then your memory is already dumped to disk. No need for DMA based attacks.

BTW, Thanks for the info, I didn't know that Apple disables DMA during sleep:-)

For macs this was fixed along time ago. As of OSX 10.7.2 the DMA based attacks no longer work. When the system sleeps the firmware disables DMA transactions.

That's somewhat overstating things, I think. The problem isn't fixed.

OS X as of 10.7.2 does indeed disable DMA transactions when the machine is sleeping or locked. But unlocked machines remain vulnerable. More pertinently, if you switch users using Fast User Switching, even to a Guest user, DMA is re-enabled, and FireWire and Thunderbolt can both be used to dump the system's memory.

To defend properly against this attack, OS X would have to use the IOMMU (VT-d) to hide the passwords somewhere that was simply inaccessible to DMA. Another option would be to use SM memory to store the keys, but I'm not sure how practical that would be (since you probably don't want to have to switch to SM mode each time you want to encrypt or decrypt some data).

For macs this was fixed along time ago. As of OSX 10.7.2 the DMA based attacks no longer work. When the system sleeps the firmware disables DMA transactions.

That's somewhat overstating things, I think. The problem isn't fixed.

OS X as of 10.7.2 does indeed disable DMA transactions when the machine is sleeping or locked. But unlocked machines remain vulnerable. More pertinently, if you switch users using Fast User Switching, even to a Guest user, DMA is re-enabled, and FireWire and Thunderbolt can both be used to dump the system's memory.

To defend properly against this attack, OS X would have to use the IOMMU (VT-d) to hide the passwords somewhere that was simply inaccessible to DMA. Another option would be to use SM memory to store the keys, but I'm not sure how practical that would be (since you probably don't want to have to switch to SM mode each time you want to encrypt or decrypt some data).

If the Firmware lock is enabled does using "Fast User Switching" re-enable DMA?

One thing I don't understand and thats how this works with hibernation. i only have experience with bitlocker so I am not sure how this effects the other forms of encryption.

With bitlocker when you standby the machine and then wake it back up it does not ask for your encryption password. I can understand this therefore being a risk and standby should be turned off in this situation.

However, how is hibernation a risk? bitlocker works by encrypting the whole disk including where the hibernate file resides. When you wake from hibernation you must enter your encryption password.

As bitlocker is full disk encryption only I fail to see how hibernation can be a security issue for it?

How does this program find the key stored in RAM anyways? It seems to (my ignorant mind) me that using something equivalent to ASLR would make it at least more difficult to find the key that's loaded into memory?

This doesn't apply if you use S3 (all data stored to hard drive, RAM and CPU shut down), right? Assuming you're using full drive encryption too, I mean. Is the any reason not to use S3 hibernation with encryption? It's more stable, uses less power, and is only a little bit slower.

This might be a stupid question, so please excuse me if that is the case, but does this apply in any way or form to fully encrypted Smartphones?

If it's a stupid question, you're apparently not the only one who wants to know the answer. I'm curious to know if anyone has tried/succeeded in hacking Samsung's SAFE technology. I currently have my Note 2 encrypted and love (among other things) that you can't access the memory over USB without unlocking the phone, but I do wonder just how secure it is.

Also, I wish you could turn off the feature that lets you wipe your phone on boot-up. Someone stealing the phone for the hardware isn't gonna give two $#!+s that it's encrypted; they'll just reset it.

One thing I don't understand and thats how this works with hibernation. i only have experience with bitlocker so I am not sure how this effects the other forms of encryption.

With a system like BitLocker, indeed the hibernation file is encrypted so this doesn't help. But for something like TrueCrypt, where you can have an unencrypted main volume and an encrypted volume contained in a file on that main volume, it could potentially be a problem unless TrueCrypt scrubs keys prior to sleep/hibernation. I believe TrueCrypt does in fact do this, but I don't know if the other products named do.

The password always struck me as the weakest link in the chain with these disk encryption schemes.

As I understand it, the disk is encrypted with a big fat key, say 4096bits. But that key is stored on disk and itself is only protected by your password. If your password is in any sort of dictionary or is fewer than 8 characters long, it can be brute forced and the attacker gets in. There's not much you can do about it. You can't carry the key around on a USB stick in case you lose it. Any physical attribute like your iris scan or fingerprint can be copied. It ultimately has to come down to something you can remember.

But of course, everyone is now using 13 character long alphanumeric passwords, aren't they?

Still, if I really, really wanted to steal your data, I would just get a look-a-like copy of your laptop, and swap it for yours when you weren't looking, then wait for you to open it up type your password in, at which point the look-a-like laptop would send me your password. If I was really keen I would swap out the internals of your laptop, so it was your laptop on the outside, but my malicious password stealer on the inside.

There is nothing on the Elcomsoft site about this product being able to run on Mac OSX or Linux:

Supported Disk Encryption ToolsElcomsoft Forensic Disk Decryptor works with encrypted volumes created by current versions of BitLocker, PGP and TrueCrypt, including removable and flash storage media encrypted with BitLocker To Go. Supports PGP encrypted containers and full disk encryption.

I assume the same kind of key memory vulnerability applies to OSX and Linux, but this product probably wouldn't be the tool to use to decrypt those systems, so I feel pretty safe with my current mix of GPG and TrueCrypt on my Ubuntu machines. Or am I just deluding myself?

For macs this was fixed along time ago. As of OSX 10.7.2 the DMA based attacks no longer work. When the system sleeps the firmware disables DMA transactions.

That's somewhat overstating things, I think. The problem isn't fixed.

OS X as of 10.7.2 does indeed disable DMA transactions when the machine is sleeping or locked. But unlocked machines remain vulnerable. More pertinently, if you switch users using Fast User Switching, even to a Guest user, DMA is re-enabled, and FireWire and Thunderbolt can both be used to dump the system's memory.

To defend properly against this attack, OS X would have to use the IOMMU (VT-d) to hide the passwords somewhere that was simply inaccessible to DMA. Another option would be to use SM memory to store the keys, but I'm not sure how practical that would be (since you probably don't want to have to switch to SM mode each time you want to encrypt or decrypt some data).

You cannot switch to another user without the authorized user's consent when the machine is properly secured, so how is that a viable attack vector?

And volume encryption is only be unlocked after I have explicitly entered my password before it can even read the hibernation file.

(A Mac can be forced to use only hibernation exclusively instead of just sleep or the default "smart sleep" which is a combination of the two, and that is of course recommended when security is a priority.)

There's also another solution that limits vulnerability. DON'T USE FULL DISK ENCRYPTION AS YOUR ONLY MEANS OF PROTECTING SENSITIVE INFORMATION. The way these attacks work is that you have the disk decrypted when the attacker strikes. Well, the best security measure for that is to only have the disk decrypted when you need the sensitive information. The 98% of the time you are checking Facebook, sending emails, playing games, etc. the sensitive info should not be decrypted. That way, you are only vulnerable to attack in the 2% of the time when you are actually accessing this info, a time in which you should make sure your machine is physically secure.

Also, I'm not sure that the price change is that big of a deal. I suspect that a great deal of the users are using them for illegal means, which would mean that there's a great likelihood that these people don't care that much about copyright.

"On Macs that predate that version, that would make it possible for attackers to carry out the same types of attacks. "

Ahah! Now that's why i "chose" the only Intel Macbook ever to be launched withouth a Firewire port! (Macbook Alumin(i)um - late 2008). As with everything with Apple, it's not a bug it's a feature! ;-)

So, even though i'm still using Snow Leopard i get a "free of jail" card on that vector of attack?

Quote:

"Another possibility is obtaining a file that gets written to disk just prior to a computer being put into hibernation. If the encrypted disk is mounted during that process, the key is likely to be contained inside the file. A third possible avenue is retrieving a key stored in unencrypted virtual machine memory that gets written to a hard drive.""

Aren't these two options the same thing? Also, on the Security tab in System Preferences, there's an option to "use secure virtual memory". I always thought that referred to swap and hibernation file written to disk, isn't it?