RAM dumping USB key attacks windows encryption, passwords

[Darren Kitchen]

Have you guys seen this? What do you think?

http://mcgrewsecurity.com/projects/msramdmp/

[ls]

hmm interesting, this may have some potential

but does this also works if the computer is correctly shutdown ?

[Kerberos]

  I saw an article on Slashdot related to this. Researchers shut down a computer and then took the RAM chips out and froze them. The result was that the RAM chips were actually able to hold all of their data for hours, allowing ample time to recover encryption keys stored within them.

  It doesn't matter how the computer is shut down, the flaw is in the way that the RAM physically stores the data. While power is required to keep the information in tact in normal circumstances, cutting off the power will not result in immediate loss of the data because of the persistence of the physical aspect of the RAM chips (in other words, it's like recovering deleted files from a hard drive, which is possible because of how the data is physically written and stored on the hard disk).

  I believe, however (not 100% sure) that since programs like truecrypt don't cache the passwords and keyfiles (if you're using them right) they should be immune to attacks like this. Any objections?

[moonlit]

This has been around a while now, it's fairly easy, if you have physical access for long enough you don't even need to remove the RAM, just cut the power, boot a micro Linux distro, dd the RAM to an image on a USB stick/drive, walk away.

Oh yeah, and Firewire has always had direct memory access, so with a suitable Firewire device and a machine with a matching port, you could grab the RAM contents without even powering off the machine.

[natural_orange]

I'm surprised that this has not patched yet, it doesn't seem very difficult to fix, you just need something to wipe the ram chips when your done with them. Though if your HDD encrypted whatever is doing the wipe couldn't be encrypted. Probably something that would need to be added to the BIOS or bootloader.

This is why they need the built-in crypto chips that are actually physically impossible to remove the key from because no command is built in to the chip that will output the keys.

Another great example of someone not fully testing there product, i imagine that the developers just assumed like 99% of people in the world that RAM dissipated quickly after power was cut.

[nicatronTg]

I'm surprised that this has not patched yet, it doesn't seem very difficult to fix, you just need something to wipe the ram chips when your done with them. Though if your HDD encrypted whatever is doing the wipe couldn't be encrypted. Probably something that would need to be added to the BIOS or bootloader.

This is why they need the built-in crypto chips that are actually physically impossible to remove the key from because no command is built in to the chip that will output the keys.

Another great example of someone not fully testing there product, i imagine that the developers just assumed like 99% of people in the world that RAM dissipated quickly after power was cut.

That would take forever to clear the RAM. To completely remove the data, you would need to flood the entire ram chip with mass amounts of random crap.

[natural_orange]

How would that take forever? RAM is incredibly fast, it shouldn't take more than a few seconds, espeically if the app knows exactly where the key is stored.

To be honest even if the app only overwrote a random bit out of 10 it would be enough to compromise the integrity of the key.

[DingleBerries]

Sounds good now we need to see this in action

[IOSys]

I'm surprised that this has not patched yet, it doesn't seem very difficult to fix, you just need something to wipe the ram chips when your done with them. Though if your HDD encrypted whatever is doing the wipe couldn't be encrypted. Probably something that would need to be added to the BIOS or bootloader.

This is why they need the built-in crypto chips that are actually physically impossible to remove the key from because no command is built in to the chip that will output the keys.

Another great example of someone not fully testing there product, i imagine that the developers just assumed like 99% of people in the world that RAM dissipated quickly after power was cut.

Social engineering 101 : Now I know that you are like 99% of people : You don't READ THE FUCKING MANUAL, ever, do you ?

This "attack" has been documented in the truecrypt-manual for years and it is why truecrypt (or any other well-coded encryption-program)

wipes the key(s) from RAM when you dismount the encrypted drive . If you think any "built-in-chip" like a TPM-chip that complies to US-export regulations will solve this problem.. keep dreaming .

But to answer the OP's question : I don't think much about this "new" thing  because there is nothing new here.

You have been able to dump RAM-contents for ages provided you have physical access to the machine.

Inherently, unencrypted master keys have to be stored in RAM as well. When a TrueCrypt volume is dismounted, TrueCrypt erases its master keys (stored in RAM). When the computer is cleanly restarted (or cleanly shut down) or hibernates, all TrueCrypt volumes are automatically dismounted and, thus, all master keys stored in RAM are erased by the TrueCrypt driver (including master keys for system partitions/drives). However, when power supply is abruptly interrupted, when the computer is reset (not cleanly restarted), or when the system crashes, TrueCrypt naturally stops running and therefore cannot erase any keys or any other sensitive data. Furthermore, as Microsoft does not provide any API for handling hibernation, master keys used for system encryption cannot be reliably erased from RAM when a computer hibernates.

* Allegedly, for 1.5-35 seconds under normal operating temperatures (26-44 °C) and up to several hours when the memory modules are cooled (when the computer is running) to very low temperatures (e.g. -50 °C). New types of memory modules allegedly exhibit a much shorter decay time than older types (e.g. 1.5-2.5 seconds).

http://www.truecrypt.org/docs/security-precautions.php

[nicatronTg]

How would that take forever? RAM is incredibly fast, it shouldn't take more than a few seconds, espeically if the app knows exactly where the key is stored.

To be honest even if the app only overwrote a random bit out of 10 it would be enough to compromise the integrity of the key.

Sorry, I was thinking of HDDs, at the time of posting.

[digip]

it is why truecrypt (or any other well-coded encryption-program)

wipes the key(s) from RAM when you dismount the encrypted drive .

Yeah, but unrelated to this article on the reboot with USB key, researches have found that even things like True-Crypt leave the info in ram for from 30 seconds up to many minutes later if they cool the ram chips. Highly unlikely that a forensic team is stting outside yoru house waiting to come raid your box though. See http://citp.princeton.edu/memory/

I still think that unless all steps are handled in a timely manner, their window of error gets smaller and one srewup while trying to reteive the keys makes it that much harder to get them. They rick getting only partial data and that in itself is not enough to decrypt an encrypted drive.

There is however one other hack that I have read about lately. It doesnt involve booting with a usb key to get the data, but instead uses Firewire. This pertains to a specific brand of encryption software by "Pointsec Full Disk Encryption" being cracked, but it coudl prbably be applied to others in some way.

"This simple attack takes advantage of the FireWire protocol and its ability to directly access and modify the RAM of a target machine with a FireWire port installed. Using a simple and readily available forensics software tool, it is possible to connect a FireWire cable to a computer, and within seconds bypass the Windows authentication and log in as a local administrator.

This attack is made possible because the operating system on the computer loads and boots directly into Windows without first asking for a Pointsec ‘preboot authentication’ password. Normally, with whole disk encryption, a user is required to enter a password immediately upon turning the machine on. That password is what unlocks the decryption key and allows the rest of the operating system to load and execute. This FireWire attack would not be successful in that case, because the attack requires that Windows already be up and running. In the circumstance of a properly configured encrypted computer, a stolen system that is powered off would be well protected from unauthorized access and this type of attack."

- http://isc.sans.org/diary.html?storyid=4133

This is only a joke ---> I just want to add for the paranoid admins out there, start putting crazy glue in all your USB and Firewire ports and keep your PC's locked in a safe with an ethernet, power, fan, keyboard and mouse cables running out from it (and dont use USB Keyboards and Mice). <--- This is only a joke.

[digip]

Have you guys seen this? What do you think?

http://mcgrewsecurity.com/projects/msramdmp/

What I find interesting is that he did this in a VM and was able to get data from it. If someone has physical access to a machine there really isnt any limitation to what they can do I guess, but they key to this is having access to the machine as well as the time and tools needed to carry out the dump. Walking into a starbucks your not going to get a drive by dump from somones machine the same way you would with say one of the switchblade payloads or something.

[DingleBerries]

reviving an old topic. if someone did happen to have enough time they could image the hhd and bring it home then run it inside a VM.  Is it possible to image just select part of a drive? I am not very familiar with imaging software. Would you indeed be able to image and encrypted disk?

1. Locate a computer outside the usual work space, i.e in a back room or in my school there is one inside the teachers bathroom?

2. Boot imaging software

3. Plugin a usb powered external hdd

4. Hide hdd behind the computer

5. Hide the VGA adapter and or power cord for monitor

6. come back later with imaged drive

7. rum on vm

8. ????

9. Profit

This is of course very black hat way of doing this and probably very traceable.

Getting longer sorry. Since the RAM in a VM can also be created as a paging file would it be easier to pause the VM make a copy of the page file and go at it with different attacks to your hearts content?

[moonlit]

reviving an old topic. if someone did happen to have enough time they could image the hhd and bring it home then run it inside a VM.  Is it possible to image just select part of a drive? I am not very familiar with imaging software. Would you indeed be able to image and encrypted disk?

1. Locate a computer outside the usual work space, i.e in a back room or in my school there is one inside the teachers bathroom?

2. Boot imaging software

3. Plugin a usb powered external hdd

4. Hide hdd behind the computer

5. Hide the VGA adapter and or power cord for monitor

6. come back later with imaged drive

7. rum on vm

8. ????

9. Profit

This is of course very black hat way of doing this and probably very traceable.

Getting longer sorry. Since the RAM in a VM can also be created as a paging file would it be easier to pause the VM make a copy of the page file and go at it with different attacks to your hearts content?

The problem with your suggestion is that it ignores anything that's in RAM but not on the HDD. This could be cached data, encryption keys, pieces of documents, just about anything. The HDD image is nice, but ideally you don't want to disturb the machine wherever you can avoid it, you may contaminate the HDD image or RAM dump. You could indeed run the HDD image in a VM, or at least extract data from it, but it's a little redundant in that the data in RAM has long since been destroyed (you walked away from the machine without it) and the VM would only have the data that you could extract using other methods (for example, examining the drive image without running it, perhaps bit by bit looking for patters that make up files, or even mounting a copy of the image on another machine).

[DingleBerries]

Something can not be stored in the ram forever. The password has to be placed there when the pc boots up so imaging the drive could give you the section of the hhd that holds and places the encryption key in the ram. The only way i see this not working is if there is a conflict with the drive being protected during the imaging process. In theory you should be able to take your new imaged drive and place it in a different pc and it boot with the exact same setting as the original giving you ample amounts of time to crack it and even if the admin changes the pass word on the original computer you should have all the data needed. On the other hand it might be difficult to make the imaged drive into a format that a VM can read and understand.

[digip]

Something can not be stored in the ram forever. The password has to be placed there when the pc boots up so imaging the drive could give you the section of the hhd that holds and places the encryption key in the ram.

The encrypted key in RAM is only there after you authenticate from the HDD, which is fruitless if the drive is encrypted, your method of retreiving anything wont work from a dump of the HDD, but if you have a dump of the RAM shortly after it the key was used, then you have a chance to unlock the encrypted drive after a reboot for any other sensitve data that would otherwise be locked down and encrypted upon rebooting the machine. The HDD would only have a hash you would then need to crack in order to use it, but if you can't get to the hash due to encryption, then a copy of the HDD is useless. Passwords on the HDD are (usually) not stored in plain text. ;)

[pelmen]

@Moonlit

If possible care to go into details on how to "dd" the RAM and image it to a flash drive?

Thanks

[moonlit]

@Moonlit

If possible care to go into details on how to "dd" the RAM and image it to a flash drive?

Thanks

You could try:

dd if=/dev/ram of=/mnt/sda1/ramdump.img

(Where /dev/ram is your RAM, may vary depending on the distro you choose.

/mnt/sda1 is the drive you want to save to, will depend on what drives you have and which you want to save to, and ramdump.img is the filename, can be changed according to taste.)

Edit: You'll need to do this under something that isn't Windows. Just about any Linux distro will do, but bear in mind that for this purpose you'd want it to be as small as possible (think floppy disk distros) so it doesn't write over much of the potential "evidence" in the RAM. Bigger distros will work to practice with, but they'll overwrite the stuff you're trying to dig up with this technique.

So with your Linux distro in hand, boot it up, get to a terminal (you shouldn't have a GUI if you're preparing a stick/disk just for this task, but if you have one, pull up a terminal anyway) and type the line I included above (you may have to make slight alterations depending on the distro and how many/what kind of disks you have). It might take a short while because flash drives are fairly slow, but be patient, it'll look like it's doing nothing for a while, then it'll stop looking like it's doing nothing, then that's when it's done. You can then take the file on the flash drive to be dissected elsewhere.

[Junke1990]

I've did it with Ubuntu 7.10 and noticed a few command's were, first up is Ubuntu doesn't use mnt but uses media and second in my case the thumb drive wasn't sdd but was sdb. One little prob I run in to was the /mnt/flash that doesn't excist in Ubuntu if you just pull the thumb drive out and reconnect it Ubuntu will mount it. This will save some work, Ubuntu will mount this with /media/disk/