---- Original Message ----- From: "Tom Bowers" <bowerstat_private> To: <ryansmithat_private>; <forensicsat_private> Sent: Friday, June 27, 2003 8:20 AM Subject: Re: looking for EFS weaknesses > The weaknesses of W2K EFS are as follows: > > 1. The default recovery agent for encrypted files is the W2K > Administrator account. Therefore if you can compromise the Administrator > account and login as the same you have access to ALL encrypted files. > This compromise is very easily accomplished with Peter Nordahl's Linux > boot disk. It can be found at: > http://home.eunet.no/~pnordahl/ntpasswd/bootdisk.html As someone already pointed out, we will be using a domain admin as the recovery agent. This takes the capability away from the local admin to recover encrypted files. The certificate for the domain admin will be stored on a physically secured removable media device. > > 2. Elcomsoft has developed a tool that locates and attempts to > break/interpret the private keys being used for EFS in a GUI based tool. > It can be found at: > http://www.elcomsoft.com/aefsdr.html# From the product information sheet: = Known problems and limitations - The program can decrypt protected files only if encryption keys (at least, some of them) are still exist in the system and have not been tampered. - If Account Database Key (SYSKEY) is stored on floppy disk, or if "Password Startup" option has been set, you should know/have one of the following in order to be able to decrypt the files: - startup password or startup floppy disk - the password of user who encrypted the files -the password of Recovery Agent (if one is availbale) - If the computer was a part of domain at a time when the files were encrypted, you may not be able to decrypt the files in some cases. Thank you for the tip though, I will be sure to encorporate all these into our policy. > > 3. Yes both of these solutions require physical access to the affected > PC but if we assume a stolen laptop with company proprietory data on > it...... The files for the most part will be stored to a network server with fairly secured physical access. We're debating the policies currently, but I believe certificates will be stored in some form of physically secured removable media. So long as policies are followed, these procedures should suffice to hinder the previously stated weaknesses, am I correct? > > When we architected W2K for Wyeth we had high hopes for EFS. They were > soon dashed because of the weaknesses listed above and in your email. > EFS in XP does not share these weaknesses due to a change in how they > handle their key pairs. Did Microsoft not make the same corrections to Win2k in a service pack? > > Respectfully, > > > > Tom Bowers, CISSP > Wyeth Pharamceuticals > Lead Desktop & Firewall Engineer > > > >>> Ryan Smith <ryansmithat_private> 6/26/2003 11:53:30 AM >>> > > > After some research, I am considering rolling out an encryption > solution > based on win2k EFS. I know of one weakness, that encrypting a file that > > already exists will leave behind an insecurely deleted plaintext file. > > This means anyone with any decent forensics tool could bypass the OS > and > easily read it directly off the hard drive. > > It also transfers files insecurely across the network. SSL should > solve > for that. > > Does anyone know of any other major weaknesses in the EFS encryption, > certificate handling, encryption, etc? For this group I'm particularly > > looking for areas of the hard drive that may contain hidden plaintext > copies of normally encrypted documents. > > ----------------------------------------------------------------- > This list is provided by the SecurityFocus ARIS analyzer service. > For more information on this free incident handling, management > and tracking system please see: http://aris.securityfocus.com > > ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Mon Jun 30 2003 - 04:25:32 PDT