From: Kevan Smith (Kevan.Smithtideworks.com)
Date: Wed May 12 2004 - 11:43:05 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Excellent insights, Nicolas, and from a technical standpoint I don't
disagree in the least.

My point, however, is that the 'most secure' approach is often not the
'best' approach. Selecting an appropriate PKI approach (whether that's
a single user on a home machine, or an enterprise with thousands of
systems) requires a delicate balancing act between security, usability,
cost, and recoverability. As most organizations would recognize
different needs for different purposes, a complete PKI approach will
almost always include a combination of approaches.

Certs stored on user workstations are relatively simple to use and
inexpensive to deploy (as long as the users don't roam), they can also
be archived for recovery (which is a good thing as it's all too easy to
lose the key), and they work well to prevent a casual or unskilled
attacker from gaining unauthorized access to the data. At least for now
- this may change as hacker-kiddy tools begin targeting the weaknesses
you mention.

When the needs of security increase (for example, non-repudiation,
payroll data, trade secret emails, letters to your significant
other...), these begin to offset the need for usability, which will
dictate moving to more secure means. If the security needs are high
enough (as with military plans, cert recovery actions, etc), security
needs may dictate that a smart card alone is still not enough (i.e.,
requiring multiple smart cards & user passwords at a dedicated offline
system, in combination with other specialized hardware).

As with all things, as security increases, usability decreases. The
question is one of balance.

Kevan S.

-----Original Message-----
From: Nicolas RUFF (lists) [mailto:ruff.listsedelweb.fr]
Sent: Wednesday, May 12, 2004 2:36 AM
To: focus-mssecurityfocus.com
Subject: Re: Relative Security Provided by Cached Domain Credentials?

        Hi,

> True, EFS certificates (indeed, all user certificates) are stored
> either in the users profile (locally on the client computer) or on a
> smartcard, depending your implementation. With certs stored in your
> user profile, the private key portion of the cert is stored locally on

> the client computer, and possibly archived on the issuing CA *. These

> certs are NOT available (to anyone) from other computers unless the
> user first exports/imports his/her certificate to all his/her
workstations.

When non-hardware storage is used, and if I remember well, the private
key(s) can be found in the following directory :
C:\Documents and Settings\<username>\Application Data\Microsoft\Crypto

However the following directory is also somewhat involved in the process
of private key retrieval :
C:\Documents and Settings\<username>\Application Data\Microsoft\Protect
See the CREDHIST file ? Looks like a CREDentials HISTory file : if an
administrator resets your Windows password because you lost the old one,
you do not want to lose all your private keys ...

I will not go deep into details, because you will find all you need on
this site :
http://www.beginningtoseethelight.org/efsrecovery/index.php

Public and/or private keys stored on a workstation can be accessed
through various methods, even if the user does not *explicitly* export
them :

- Stolen laptop or other physical access to the workstation : you have
direct access to the hard drive (EFS was mainly designed to address the
risk of stolen laptops, but IMHO this is far from a perfect solution).

- Administrative shares : if you can guess the login/password pair for a
local administrative account, you can access all local drives from
anywhere on the Internet using the default \\<IP>\C$ share.
* WinXP : blank passwords are not allowed to log on remotely.
* Win2K : the password can be blank (see SANS Top 10 vulnerabilities,
and the Chinese "Fluxay"
remote hacking tool).

- Remote Registry access : certificates are mapped into registry, and
the Remote Registry service is started by default. You need admin rights
on the target workstation, though.

- Exploit : go get the latest DCOM/LSA/whatever exploit and copy the
keys via FTP, or access the CryptoAPI as SYSTEM.

- Virus/Malware : instead of targeting email adresses, credit card
numbers, etc. you can target private keys and upload them to a "*.ru"
website.

Etc. etc.

It is true that you cannot export private keys using the CryptoAPI, if
they are marked as "non exportable". But remember that this flag is
enforced by the API (nothing prevents the kernel from accessing your
private keys). I am working on this for now :-)

Conclusion : non-hardware key stores are *not* safe (but you knew this
already ?).

> So, even if an attacker cracks a user's password, he/she will still
> need the certificate to access the EFS encrypted files, which requires

> that they launch the attack while logged on locally to the victim's
> computer(s). Granted, it may be possible to drop a remote control
> backdoor on the box to log on undetected, or do any number of other
> nasty things to achieve the same effect, but it certainly raises the
> bar.

The only things an attacker need are :
- The private key file.
- The user password, if the above file has been stolen "offline"
(encrypted with the user password).
If you can hijack a user session, this is not required as the key
remains decrypted in memory as long as the user is logged in.
- An idea of the "semi-documented" file structures involved.

* The "certificate" (=public key, signed by the trusted CA) is only used
for encryption, not for decryption.
* If the victim is logged in during the attack, you can access all EFS
encrypted files transparently as the victim does, so you do not need to
attack anything. But as we see this is not mandatory : you can still
decrypt EFS files "offline".
* If you *only* have an EFS encrypted file and a user password, you
cannot decrypt the file.
However, as shown before, getting access to the private key is not so
hard on software stores.

> While AEFSDR (or similar tools) looks like a handy addition to any
> administrators grab-bag, it doesn't lift any hurdles facing a hacker.

As long as users have strong, non-guessable Windows passwords ...

This is the main problem with EFS : whole user security = robustness of
a single Windows password (which also might be stored in weak forms,
such as LM hash).

> If the EFS encrypted data is important enough (or the user hops
> workstations enough), you can remove the user's profile from the
picture
> by requiring smart cards for EFS. The key pairs are stored on the
card
> rather than the computer, allowing users to roam, and forcing the
> attacker to acquire both the username/password to logon to the
computer,
> and the smart card/PIN to access the files.

Smartcards are far more secure, because even if a Trojan can sniff the
PIN code, you still need
physical access to the card to decrypt files.

However, remember that as long as the card is in the card reader, and
the user logged in, you can
access all his EFS encrypted files transparently as he does. Don't even
think of activating the
"strong" key protection (ask for PIN code on each private key access),
if you don't want to kill
your left mouse button in one day :-)

Regards,
- Nicolas RUFF
-----------------------------------
Security Consultant
EdelWeb (http://www.edelweb.fr/)
Mail : nicolas.ruffedelweb.fr
-----------------------------------

------------------------------------------------------------------------
---
------------------------------------------------------------------------
---

---------------------------------------------------------------------------
---------------------------------------------------------------------------

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]