Ed, I think the critical issue here may be cached credentials. If you have a machine in a domain that allows caching, perhaps Windows 2000 stores the user's private key in unencrypted form. I have not been able to verify this but it would explain what you are seeing. However, a standalone personal computer would not suffer from such an attach, which would explain what I am seeing. I am wracking my brain trying to imagine why a private key would be cached in unencrypted form. Eoghan On Fri, 13 Sep 2002, Ed Moyle wrote: > On Friday, September 13, 2002 08:44, Eoghan Casey wrote: > > > If you do not have the user's passphrase or a recovery agent, how do you > > do you get around EFS? > > I've gotten a few questions about this, so here is the way to do it. > There are a few caveats that should be taken into consideration before > doing this on a system, though. The first (and most important) is that > the utility I refence below requires *writing* to the drive, so you > obviously don't want to do this on any drive that can't be written to > (e.g. evidence)... so work with a mirror if you are going to do this in > that context. This type of thing really works best with remote users > (e.g. laptops) and you need physical access to the machine. I've done > this on Win2k, but haven't tried with XP. > > Briefly, EFS works by encrypting a file with DESX. Then, the DESX file > key is encrypted with some number of public keys that are in EFS certs > that windows knows about. These encrypted file keys are stored with the > file as part of the file record. One might assume that some kind of > password based key derivation would be used to encrypt the private keys > that correspond to those public keys (would seem logical to me,) but that > isn't the case in EFS... > > If you can trick Windows 2000 into logging you in (whether you know the > account password or not, you can successfully decrypt the EFS encrypted > files. How do you trick windows into logging you in? I recommend the > excellent pnordahl utility (http://home.eunet.no/~pnordahl/ntpasswd/) > for doing this (don't use on a blank password... really important.) This > works with local accounts; if you can trick Windows 2000 into logging > you in with cached credentials, you can decrypt also with domain accounts. > You really need to log in to the domain if roaming profiles are used > since the keys are stored with the profile, but using roaming profiles > and/or not having cached logins really hampers the ability of most users > to do their work, so most users/organizations usually don't do that. > > Hope this information helps somebody out there. > > Regards, > -Ed > > ----------------------------------------------------------------- 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 : Wed Sep 18 2002 - 05:44:49 PDT