cyber_moron
asked on
is this for real?
has anybody tried the advanced EFS data recovery
quote:
Advanced EFS Data Recovery will recover (decrypt) files encrypted on NTFS (EFS) partitions created. Files are being decrypted even in a case when the system is not bootable and so you cannot log on, and/or some encryption keys (private or master) have been tampered. Besides, decryption is possible even when Windows is protected using SYSKEY.
is this for real?
quote:
Advanced EFS Data Recovery will recover (decrypt) files encrypted on NTFS (EFS) partitions created. Files are being decrypted even in a case when the system is not bootable and so you cannot log on, and/or some encryption keys (private or master) have been tampered. Besides, decryption is possible even when Windows is protected using SYSKEY.
is this for real?
yeah, interesting thing about encryption, is that it more often leads to user losing own access than in defending from view of some other
Very True SunBow :) Yes EFS Recovery from ElcomSoft does work- if you haven't followed best practices- you must export the key's of the recovery agent's. Syskey is bypassed easily. just look for Todd Sabin's utilites pwdump and read about dll injection. Granted you need admin rights to get it to work- but it's done too easily. Todd has an excellent explaination of how it's achived. Syskey is also bypassed if you machine is not powered up- the SAM database is only encrypted with syskey when the OS boot's- not if you use a boot cd or floppy to read the sam while the OS is off-line.
Anyway- I've tried Advanced EFS, and determined that I can find the files just as well as it could by using a lowlevel HD reader (file recovery software) and looking for efsX.tmp where X starts at 0 and increments for each file that is encrypted. That way you get the Plain Text of a file- and don't need to crack EFS of get the recovery agent's keys. It's a pretty big flaw in the design- but not widely known. I've not worked with it extensivly- or on a HD that was totally encrypted- just a few files and folders on a NTFS drive.
-rich
Anyway- I've tried Advanced EFS, and determined that I can find the files just as well as it could by using a lowlevel HD reader (file recovery software) and looking for efsX.tmp where X starts at 0 and increments for each file that is encrypted. That way you get the Plain Text of a file- and don't need to crack EFS of get the recovery agent's keys. It's a pretty big flaw in the design- but not widely known. I've not worked with it extensivly- or on a HD that was totally encrypted- just a few files and folders on a NTFS drive.
-rich
ASKER
now, my question is, if such possibilities do exist, how secure is the whole encryption system in Windows.
They boast that it is very secure while it doesnt seem to.
My opinion is that when it comes to security (and everything else in life) a plan B it's a must and one system it's not enough.
Better have a second encryption software to run in the background, so if one fail the other might work
CM
They boast that it is very secure while it doesnt seem to.
My opinion is that when it comes to security (and everything else in life) a plan B it's a must and one system it's not enough.
Better have a second encryption software to run in the background, so if one fail the other might work
CM
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I agree with everything Rich is saying here, except for one implied assertion: an encrypted file does NOT always leave behind an efsX.tmp file. It ONLY does this when you are encrypting a FILE in a folder that is NOT marked for encryption. If you *first* "encrypt" the folder (the folder doesn't actually get encrypted, but it does get the EFS attribute), then ALL new files created in or copied to that folder will IMMEDIATELY be encrypted, and EFS itself will generate NO plaintext temp file or any copy of plaintext elsewhere on disk. [The efsX.tmp plaintext copy of the file is only created when (a) the folder is not encrypted before creating the file or (b) the file was already saved in plaintext form first, and *then* encrypted after.]
Many applications will create a temporary backup of a file while the file is being worked on. The good applications will create the temporary file either (a) alongside the original file (i.e. in the same folder as the original file's folder) or (b) in the %temp% or %tmp% folder location. A few applications will dump their temporary files in some other folder that you wouldn't expect (and which you wouldn't normally think to encrypt), but that is NOT commonplace.
Anytime I work with a customer to plan a secure deployment of EFS, I *strongly* recommend that they encrypt at the *folder* level, not individual files (except where absolutely necessary). If they can configure their systems to encrypt the major folders where data will be stored, and *then* their users create a whole bunch of data (or restore it from backup), then the risk of plaintext shreds of that data will be reduced to a very small risk.
And, even if the users' data is encrypted after the fact, any *new* data that is generated after the folders are encrypted will NOT be stored in plaintext form on the drive. [Well, that's almost true - there *is* the possibility that some files or file fragments will occasionally show up in plaintext form in the pagefile.sys or, if the computer is enabled for hibernation and the user hibernates while some files are open, those files will be stored in some form in the hiberfile.sys. What I *don't* know is whether the copy of these (usually small number of) files is actually in plaintext form in the pagefile or hiberfil, or if the memory pages are compressed, XOR'd or otherwise altered before they're written to disk in the pagefile or hiberfil. I'd be curious to know, since it would mean the difference between someone just scanning these files - sometimes hundreds or thousands of MB of storage space on disk, which would be tedious - on disk for ASCII strings (which is how I'd look for useable text), vs. having to run/program some specialized tool that would reverse the "alteration" on every block of data and *then* inspect it for possible ASCII strings.]
Many applications will create a temporary backup of a file while the file is being worked on. The good applications will create the temporary file either (a) alongside the original file (i.e. in the same folder as the original file's folder) or (b) in the %temp% or %tmp% folder location. A few applications will dump their temporary files in some other folder that you wouldn't expect (and which you wouldn't normally think to encrypt), but that is NOT commonplace.
Anytime I work with a customer to plan a secure deployment of EFS, I *strongly* recommend that they encrypt at the *folder* level, not individual files (except where absolutely necessary). If they can configure their systems to encrypt the major folders where data will be stored, and *then* their users create a whole bunch of data (or restore it from backup), then the risk of plaintext shreds of that data will be reduced to a very small risk.
And, even if the users' data is encrypted after the fact, any *new* data that is generated after the folders are encrypted will NOT be stored in plaintext form on the drive. [Well, that's almost true - there *is* the possibility that some files or file fragments will occasionally show up in plaintext form in the pagefile.sys or, if the computer is enabled for hibernation and the user hibernates while some files are open, those files will be stored in some form in the hiberfile.sys. What I *don't* know is whether the copy of these (usually small number of) files is actually in plaintext form in the pagefile or hiberfil, or if the memory pages are compressed, XOR'd or otherwise altered before they're written to disk in the pagefile or hiberfil. I'd be curious to know, since it would mean the difference between someone just scanning these files - sometimes hundreds or thousands of MB of storage space on disk, which would be tedious - on disk for ASCII strings (which is how I'd look for useable text), vs. having to run/program some specialized tool that would reverse the "alteration" on every block of data and *then* inspect it for possible ASCII strings.]
HOW TO: Encrypt Data Using EFS in Windows 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;230520
Best Practices for the Encrypting File System
http://support.microsoft.com/default.aspx?scid=kb;EN-US;223316
Disable/Enable EFS on a Stand-Alone Windows 2000-Based Computer
http://support.microsoft.com/default.aspx?scid=kb;en-us;243035
You Cannot Decrypt Files After You Reset Your Password with a Password-Reset Disk
http://support.microsoft.com/default.aspx?scid=kb;en-us;308273
If you're a "home user" - read Methods for Recovering Encrypted Data Files
http://support.microsoft.com/default.aspx?scid=kb;en-us;255742
http://support.microsoft.com/?kbid=290260
HOW TO: Back Up the Recovery Agent Encrypting File System Private Key in Windows 2000
http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q241/2/01.asp&NoWebContent=1
Many Regards
Jorgen Malmgren
IT-Supervisor
Denmark
:o) Your brain is like a parachute. It works best when it's open