The background:
PGP WDE uses 256 bit, symmetric AES encryption. For those of you that don't know what this means, suffice it to say that the algorithm is sufficiently strong to prevent the average person/company/government agency from breaking it.
In many cases we do not have the cooperation of the system owner, so how do we handle this?
Scenario 1 - the computer is running:
If there ever was a reason to argue the Live vs. Dead acquisition arguement, disk encryption has to be one in favor of the live side. My personal preference is to acquire the volatile memory (at a minimum) before shutting down the system. Let's assume that you cannot image the whole system live - grabbing the memory with a tool like George Garner's forensic DD. No, it won't work on Vista or Server 2003 with a service pack installed, but the price is right. If you have the money though, George has solved that problem too.
So now you have a dd image of the physical memory, and a dead computer. You image the same computer and you start looking at the drive and realize that you are seeing nothing but garbage - there's no usable data on the drive.
Fortunately, Adam Bolieau help solved that problem. Adam and Tmasky did some really interesting work on acquiring memory via firewire, but he also wrote some really useful code that will read BIOS passwords from memory. Fortunately for us, PGP stores its passwords in the same memory location. So all we have to do is point bioskbsnarf.py[1] at the DD image that we made of the memory and viola - there's the password.
or at least the last 16 bytes in the keyboard interrupt buffer in the BIOS Data Area before you enter protected mode - so you may not see the "whole" password, but would you rather try to brute force but wouldn't it be easier to brute force the password "I am Computer Geek" if you could see: " a Computer Geek"? I think so. . .
Coming up:
Ok, I've got the password. Now what?
[1]. biobksnarf needs a Python interpreter to run. Python can be downloaded from Python.org, though I have not used the windows binaries with biokbsnarf. If you run into problems, try cygwin's python interpreter on a windows system.
From the command line: "python biobksnarf.py
Posts
9 comments:
Funny how it can be that easy sometimes. Looking forward to the rest of this!
A bit ago, I wrote some Perl code for Jon Evans that implemented the Python code.
So, I read through section 1 and 3. I guess my first response is "why would anyone go through these elaborate mechanisms for the sake of getting a password from a running and logged in computer?" Remember that the whole premise here is that the machine has to be turned on and logged in with valid credentials to begin with, before any of these simple, 318 steps even apply.
Um, I'm sorry but this product, as I understand it, was intended to ensure that lost laptops (which are presumably turned off) do not pose a threat as the data is encrypted. Is this "defeat" intended to describe how you would take a turned off laptop and defeat the password? I didn't see any mention of it beyond the obvious of brute force...good luck on that. However, if you have a running computer that has been logged in and is in the windows interface, then let me give you the 1 step method of getting a copy of the data to run forensics against all day long. It's called hooking up a USB drive and downloading the meaningful contents of the native drive.
If your trying to obtain forensic information from the box however, as this article seems to illustrate; I'd like to understand how it is that you ask, (in your kindest, big-brother-is-watching sort of way) for this person to log into WDE and the network for you so that you can take their computer for the next 30 minutes to reverse engineer this password. Riiiight. Tell you what, if you can get someone to give you a logged in and running computer, then one of two things is the case,
1. Your the CEO of fantasy land.
2. Your in the wrong profession because you can clearly sell water to a drowning man. Go find your calling in life as a salesperson instead of geeking out on reverse engineering passwords to a running, unencrypted (once you've authenticated to WDE, the drive "appears" as unencrypted) box.
Do you know if this trick would work with TrueCrypt's WDE?
Getting the last 16 bytes of the passphrase fot PGP WDE is only helpful if (a) the passphrase is short enough to bruteforce, or (b) the last 16 bytes actually contain enough meaning to guess the rest. Imagine that the password were not "I am a Computer Geek" but rather "g4m_V3:6#OL%~nazj^IUP a Computer Geek".. just to throw you off. I find this much more likely as someone using WDE is not going to use all dictionary words anyway.
Do you know if this trick would work with TrueCrypt's WDE?
No idea really.
Getting the last 16 bytes of the passphrase fot PGP WDE is only helpful if (a) the passphrase is short enough to bruteforce,
No, it's valuable regardless. Assume that the passphrase is 30 characters long and you have no recognizable pattern (e.g. words) to base your guesses on; in that case, your work would would require a bruteforce attack of ~128^14. I'd take that over ~128^30 any day of the week.
Imagine that the password were not "I am a Computer Geek" but rather "g4m_V3:6#OL%~nazj^IUP a Computer Geek".. just to throw you off. I find this much more likely as someone using WDE is not going to use all dictionary words anyway.
Most of my experience is with people in an enterprise who are forced to use WDE, granted, that's a different animal than the user who opts to use WDE, but the principle is the same as noted above. I have at least a part of your password.
While there isn't much research on password length/complexity you might look at http://world.std.com/~reinhold/passphrase.survey.asc for a reference. My experience is that passwords/phrases, event among the security conscious, tend to lean toward the easy/short end of the spectrum.
B
I have a much simpler question; if someone is running WDE and they are using the computer online, can one read the data if he can hack in or will it still simply appear to be random data?
"can one read the data if he can hack in...?"
Yes. Whole disk encryption only works to protect the drive when the drive is off. When the drive has been decrypted at boot, it's readable to whomever has access to the box. . .
Thank you very much for your response.
I had thought that only files which are open would be exposed (possibly) and unopened files would stay in a decrypted state. My impression was that files are decrypted and encrypted in ram, on an as used basis.
Is this wrong?
Thank you.
. . . "My impression was that files are decrypted and encrypted in ram, on an as used basis."
In my experience, this isn't the case, but I can't say that there isn't something out there that handles files this way.
I'm just guessing, but I'd say that it's probably really computationally expensive to do decryption this way.
Post a Comment