Slashdot Mirror
ElcomSoft Tool Cracks BitLocker, PGP, TrueCrypt In Real-Time
An anonymous reader writes "Russian firm ElcomSoft on Thursday announced the release of Elcomsoft Forensic Disk Decryptor (EFDD), a new forensic tool that can reportedly access information stored in disks and volumes encrypted with desktop and portable versions of BitLocker, PGP, and TrueCrypt. EFDD runs on all 32-bit and 64-bit editions of Windows XP, Windows Vista, and Windows 7, as well as Windows 2003 and Windows Server 2008." All that for $300.
Yeah, this is really just exploiting retarded key control. The encryption standards themselves are still secure
...just a hammer.
Obligatory: http://xkcd.com/538/
Access to some information or access to encrypted data?
It reads the encryption key from memory.
It requires a memory dump of the system where the keys are used. Bad submitter. Is anyone filtering the submissions? This is starting to look like reddit.
So, how does it work? Elcomsoft Forensic Disk Decryptor acquires the necessary decryption keys by analyzing memory dumps and/or hibernation files obtained from the target PC. You’ll thus need to get a memory dump from a running PC (locked or unlocked) with encrypted volumes mounted, via a standard forensic product or via a FireWire attack. Alternatively, decryption keys can also be derived from hibernation files if a target PC is turned off.
That's not really cracking. It's more like looking under the keyboard for sticky-notes.
All ideas^H^H^H^H^Hprocesses in this post are Patent Pending. (as well as the process of patenting all postings)
At $300 and being from Russia, one would assume that they wouldn't just release it as a DRM-free application...which raises the question whether they add DRM to it, and how they're going to protect it, especially if they've got the means of decrypting all of these high-security encryption mechanisms.
I'm wondering if there isn't an alternative business model here - a bounty for encrypted laptops, decrypting the data internally, and using that data for ransom. I'm pretty sure it'd work much better than selling licenses at $300 a pop.
Unlike the title claims, it doesn't _crack_ in real time, it just allows you to mount the encrypted volume and lets you decrypt it with the keys you found. I.e. make it work just like truecrypt when you mount a partition.
If they were able to _crack_ in real time, then they'd have just solved P = NP.
They are simply extracting the encryption keys from the memory of a running computer using DMA and firewire. @breaknenter has been doing this with inception and some scripts for years.
http://xkcd.com/538/
I don't use windows, but on other OSs, the swap where "hibernation" data goes, is encrypted to avoid such trivial exploits.
As for the firewire attack, that was first developed on Linux, and immediately prevented on Linux. On Windows, it has been available since XP days, and MS notified of the issue back then. So, no excuse it is still trivial to unlock, disk dump, mem dump a windows box through the DMA firewire hack, now 3 major versions on since this attack was well known.
... with three ways to locate it:
By analyzing the hibernation file (if the PC being analyzed is turned off);
By analyzing a memory dump file *
By performing a FireWire attack ** (PC being analyzed must be running with encrypted volumes mounted).
(or sniffing it with a key-logger, using a rubber hose, etc.)
To thwart it: Don't hibernate, don't leave a memory dump laying around, disable fire-wire, and power-down.
What TFS does not mention is that you need to acquire the encryption key for it to work. Hardly trivial.
Elcomsoft suggest attacking the hibernation file (Windows only, encrypted along with the system drive so probably inaccessible anyway, may not actually have the key) or using a Firewire attack on a live system with the volumes already mounted (useless for an offline attack, easily circumvented by disabling Firewire, not all machines even have it).
Nothing to see here.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
(Pics) || (didn't happen):
False
#
#\ @ ? Colonize Mars
#
This tool IS NOT capable of "cracking" disks encrypted by these methods. It is capable of locating the keys, should you be able to get a memory dump of the running system or obtain hibernation files, and decrypting the disks using the keys. In short, if you have something to hide, do not use hibernate and always power off your machine when you are not actively using it.
If I use a keyfile in Truecrypt, does this file also get loaded into RAM? Say, the keyfile is stored in a USB key that is removed after the Truecrypt partition is mounted.
But isn't it difficult to get a RAM dump, you say? Not really:
class It(){
if (Pics){
happen();
}
}
>My setup is the following: win...
first mistake? ;)
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
not if you're law enforcement
use the swat team and take control of computers while they are still on. or turn them on at suspect's home. transport in hibernated state and then "crack"
If you've got a firewire port in the machine, you're game over.
Otherwise, it depends on whether there's any direct remote exploits on the version of Windows you're running - I haven't heard of any of those for a long time.
Coffee-driven development.
I would actually call this more of a "finder of the decryption key if left hiding in RAM or hibernation file while encrypted partition is mounted":
It works only if
(1) you can get a volatile memory dump while the encrypted partition is mounted and the decryption key currently resides in the volatile memory or
(2) if you can get access to a hibernation partition/file which contains the decryption key from when the encrypted partition was mounted.
From the linked article So, how does it work? Elcomsoft Forensic Disk Decryptor acquires the necessary decryption keys by analyzing memory dumps and/or hibernation files obtained from the target PC. Youâ(TM)ll thus need to get a memory dump from a running PC (locked or unlocked) with encrypted volumes mounted, via a standard forensic product or via a FireWire attack. Alternatively, decryption keys can also be derived from hibernation files if a target PC is turned off. So saying that this software is capable of decrypting PGP / Bitlocker / Truecrypt partitions is hyperbole. A more accurate assessment of this software is capable of finding the decrpytion/encryption key in RAM or hibernation files.
I thought TrueCrypt,et al were smarter with their RAM-based keys than that and made them more difficult to sniff in RAM, as this has long been a well-known weakness of any encryption software.
Or is there something about whole-disk encryption software that makes this more difficult (which I can see from a performance perspective)?
You would think they would randomize memory locations or have some kind of method of encrypting the keys in-memory and decrypting them and wiping as they did disk I/O. A race condition that would expose them, but with a smaller window for exploitation than leaving them in memory.
b) if it was put in sleep mode then I'm not safe. To this date I assumed that the thief would just bounce off the login screen and restart the machine, sooner or later. Is is possible to obtain a memory dump on a running machine? Of course, USB auto-run is off
If they have physical access to the computer, they can just blast the RAM with compressed gas to freeze it. At low temperatures, the RAM keeps its data for a few seconds. Then they pull the RAM and stick it in a device that dumps it.
Give me Classic Slashdot or give me death!
If your machine has FireWire ports they can be used to directly access memory and obtain the keys - it would not be safe in this case. This is a well known forensic technique for doing memory dumps. Do not allow the machine to sleep or hibernate as this will also write memory to disk where it can be examined offline.
Build it, Drive it, Improve it! Hybridz.org
He most likely has absolutely no use for firewire and can simply disable it in the bios.
Don't know something? Look it up. Still don't know? Then ask.
I used to have their password kit for enterprise and it would make me look like a complete computer GOD to the users.
"I lost the password to my spreadsheet...."
"what is the password I used on this zip file?"
etc....
I would crack about 5-10 passwords a week with their tools and ended up never having to buy drinks when going out with office workers after work because of it.
Do not look at laser with remaining good eye.
That is military grade... That's exactly how military encryption works.
Do not look at laser with remaining good eye.
It still doesn't break encryption, the encryption part is still performing exactly as it's supposed to.
What's broken is the method of protecting the key, ie the means by which you "choose not to divulge the key"...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
It can't retrieve keys from arbitrary computers. There are specific circumstances that need to exist before they can do anything.
If the computer is on, it can potentially read the decrypted key from RAM. The computer must have been first turned on AND the correct passphrase entered to decrypt they they key to decrypt the volumes. If it's turned on but the decryption hasn't been performed yet, they gain nothing. They can't just turn on the computer and expect to crack it.
The other method they mention is reading it from hibernation files if the system is not powered on. However, if the system drive is encrypted they can't get to the hibernation files.
If you shut the machine down when you walk away you are pretty safe. Of course this doesn't prevent anyone determined enough to install a hardware key logger or something...
Ascalante: Your bride is over 3,000 years old.
Kull: She told me she was 19!
I can build walking robots, too, if I have the algorithms.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Keep all your AES keys in registers -- no affiliation, except that I'm a user and I would much prefer that it be mainlined to streamline my rebuild process. Given that there's such little performance penalty on x64/AES-NI, this should be the defacto standard.
Shutting down writes data to the hibernation file. How do you think think Windows boots faster now than it used to, while getting bigger and bigger.
Shutdown = Log off user, hibernate kernel, turn off power.
Boot = Try and resume kernel from hibernate file first.
Putting your Windows 7 laptop in standby also hibernates too. Try removing power while in standby then booting it up again. it'll resume where you last were, but it'll just take longer.
In Soviet Russia...
Nevermind; too easy.
An enigma, wrapped in a riddle, shrouded in bacon and cheese
Hibernate but don't sleep, and only if you are sure that your hibernation file will be stored encrypted.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Says it all really, doesn't it?
Now there is a solution to that attack, see here
http://www.privatecore.com/
OpenPGP as implemented in Pretty Good Privacy (PGP), Gnu Privacy Guard (GPG), and possibly other applications is a private-key/public-key encryption method. You encrypt with the public key, which cannot decrypt what it encrypts. Thus, the whole world can have copies of your public key. You decrypt only with your private key, which does not encrypt. Thus, you try to keep your private key truly private.
However, there is another consideration. You have a pass phrase that is used to encrypt your private key for storage on your computer. That is, your private key exists on your computer only in an encrypted form that cannot be used without first decrypting it with your pass phrase. My pass phrase has well over 30 characters (over 240 bits), including blank spaces and special characters. It exists only in my head plus on a piece of paper in a very secure and remote location in case I drop dead.
I use PGP. To decrypt a file, I must enter my pass phrase, which PGP then uses to decrypt my private key. PGP then uses the decrypted private key to decrypt the file. The decrypted key is in a cache and can be reused so that I do not have to keep typing my pass phrase. The cache is automatically purged after a user-set interval of time. I can also manually purge the cache, which I always do when I am through decrypting. Purging the cache should be standard procedure for anyone concerned about keeping encrypted data secure.
Thus: (1) Even if my private key is compromised (e.g., captured), it is really useless without my pass phrase, which does not exist electronically. (2) Proper procedures prevent access to the cached decrypted copy of my private key.
Of course, all this is overcome if a key-logger or other means is used to capture the input of my pass phrase. If that happens, I have greater problems than someone decrypting files I want to protect.
Both the "hybrid" sleep (where the data is written to hiberfile, then the system enters sleep) and the hybrid shutdown (where the system shuts down but writes startup data to the hiberfile) are easy to disable in the Windows power settings. More importantly, though, if they are enabled then when the system enters Hibernation you're protected anyhow. The hiberfile is on the system (encrypted) volume! They can't pull the key out of that...
This attack only works if for some reason you are using full drive encryption, but not on the system volume. By default, Windows won't even let you configure BitLocker that way; you'd have to do it manually or encrypt the drive using a different PC (one that does have its system volume encrypted) and then transfer it over and provide the decryption key.
There's no place I could be, since I've found Serenity...
Software must break you. To the end.
It will be better to purchase from an owner who is a good farmer and a good builder.
The possibility of pulling keys from memory-images has long been known. The possibility to get memory images via the brain-dead firewire design is also well known. Stealing keys is not breaking any encryption.
In addition, I doubt this can break PGP/GnuPG because if used properly, the passphrases for these reside in memory only for a fraction of a second after entered. As for the others, anybody that bothered to read anything about disk encryption knows that while a container is mapped, the keys can be pulled from memory. Bit wile the container is mapped, the decrypted disk can be read directly, so that is not that much of an additional problem.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I don't think that it is interesting that someone has figured a way to hack a running computer that they have physical access to.
However, the hibernation file inspection hack had bothered me, or rather didn't bother me after I read the document.
Check out http://www.truecrypt.org/docs/hibernation-file
from the link:
Note: The issue described below does not affect you if the system partition or system drive is encrypted* (for more information, see the chapter System Encryption) and if the hibernation file is located on any of the partitions within the key scope of system encryption (which it typically is, by default), for example, on the partition where Windows is installed. When the computer hibernates, data are encrypted on the fly before they are written to the hibernation file.
When a computer hibernates (or enters a power-saving mode), the content of its system memory is written to a so-called hibernation file on the hard drive. You can configure TrueCrypt (Settings > Preferences > Dismount all when: Entering power saving mode) to automatically dismount all mounted TrueCrypt volumes, erase their master keys stored in RAM, and cached passwords (stored in RAM), if there are any, before a computer hibernates (or enters a power-saving mode). However, keep in mind, that if you do not use system encryption (see the chapter System Encryption), TrueCrypt still cannot reliably prevent the contents of sensitive files opened in RAM from being saved unencrypted to a hibernation file. Note that when you open a file stored on a TrueCrypt volume, for example, in a text editor, then the content of the file is stored unencrypted in RAM (and it may remain unencrypted in RAM until the computer is turned off).
Note that when Windows enters Sleep mode, it may be actually configured to enter so-called Hybrid Sleep mode, which involves hibernation. Also note that the operating system may be configured to hibernate or enter the Hybrid Sleep mode when you click or select "Shut down" (for more information, please see the documentation for your operating system).
To prevent the issues described above, encrypt the system partition/drive (for information on how to do so, see the chapter System Encryption) and make sure that the hibernation file is located on one the partitions within the key scope of system encryption (which it typically is, by default), for example, on the partition where Windows is installed. When the computer hibernates, data will be encrypted on the fly before they are written to the hibernation file.
Note: You may also want to consider creating a hidden operating system (for more information, see the section Hidden Operating System).
Alternatively, if you cannot use system encryption, disable or prevent hibernation on your computer at least for each session during which you work with any sensitive data and during which you mount a TrueCrypt volume.
* Disclaimer: As Windows XP and Windows 2003 do not provide any API for encryption of hibernation files, TrueCrypt has to modify undocumented components of Windows XP/2003 in order to allow users to encrypt hibernation files. Therefore, TrueCrypt cannot guarantee that Windows XP/2003 hibernation files will always be encrypted. In response to our public complaint regarding the missing API, Microsoft began providing a public API for encryption of hibernation files on Windows Vista and later versions of Windows (for more information, see the Version History, section TrueCrypt 5.1a). Since version 7.0, TrueCrypt has used this API and therefore has been able to safely encrypt hibernation files under Windows Vista and later versions of Windows. Therefore, if you use Windows XP/2003 and want the hibernation file to be safely encrypted, we strongly recommend that you upgrade to Windows Vista or later and to TrueCrypt 7.0 or later.
There is no way to hide keys in RAM. TrueCrypt is not stupid here in any way, it is just impossible to hide the keys for a decrypted drive. It is also unnecessary, after all, you can just access the drive directly. Encryption only protects disks while they are not mapped (i.e. decrypted). It is not a solution at all for mapped disks.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Auto-dismount on idle timeout, I'd say. So many people will "lock" their laptop (read: CTRL-ALT-DEL+Enter) and leave themselves vulnerable.
class it(){ // MOAR CODES
}
var happen = new it;
if(!instanceOf("it", happen)){
print("PHALE");
}
** Before a key can be erased from RAM, the corresponding TrueCrypt volume must be dismounted. For non-system volumes, this does not cause any problems. However, as Microsoft currently does not provide any appropriate API for handling the final phase of the system shutdown process, paging files located on encrypted system volumes that are dismounted during the system shutdown process may still contain valid swapped-out memory pages (including portions of Windows system files). This could cause 'blue screen' errors. Therefore, to prevent 'blue screen' errors, TrueCrypt does not dismount encrypted system volumes and consequently cannot clear the master keys of the system volumes when the system is shut down or restarted.
Keys for non-system volumes are securely wiped from memory on dismount, which is automatic as part of the restart / shutdown procedure.
Finally had enough. Come see us over at https://soylentnews.org/
Would selling or using this product be a DMCA violation?
Things you write have an implicit copyright. Suppose your system encrypts your writings. Their software is promoted to be used to defeat that encryption.
It's a shame none of these disk encryption systems can use hardware (USB token for example) as part of the crypto. Then pulling out the token would remove the key, at least if the software behaved itself correctly with no caching. Truecrypt does go halfway in the sense that the hash of a file stored in hardware can form part of the key but it would be nice to see it done properly.
"Don't belong. Never join. Think for yourself. Peace." V.Stone, Microsoft Corporation
Modern systems have a working IOMMU and aren't vulnerable, if it is used, to stuff like snooping through memory via 1394. You need both processor and BIOS support and maybe chipset support too.
Now, if I had any idea which combinations would work, I would tell you. Linux complains about a disabled IOMMU which is supposedly costing me 64MB RAM, which might well mean that my Phenom II X6 has one but my BIOS doesn't support it.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The hiberfile.sys attack won't work with TrueCrypt full disk or system encryption for Windows: the hibernation file itself is encrypted, as it's stored in the encrypted system partion.
TrueCrypt replaces the Windows boot loader with its own and requires the key to decrypt the system upon awakening.
So, if the computer is off or hibernated, they'll access the hiberfile ... how?