RE: Relative Security Provided by Cached Domain Credentials?

• Previous message: Sarbjit Singh Gill: "RE: Relative Security Provided by Cached Domain Credentials?"
• Maybe in reply to: Zack Schiel: "Relative Security Provided by Cached Domain Credentials?"
• Next in thread: Sergey V. Gordeychik: "RE: Relative Security Provided by Cached Domain Credentials?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Fri, 28 May 2004 13:19:09 -0700
To: <ssgill@gilltechnologies.com>, "Langston, Fred" <flangston@verisign.com>, "Kim Oppalfens" <Kim.Oppalfens@azlan.be>, "Nicolas RUFF (lists)" <ruff.lists@edelweb.fr>, <focus-ms@securityfocus.com>

Gill,

I haven't tried this, so I'd welcome someone proving me wrong. However,
by the book:

A few keys to remember here are:
        1) A single user or other entity can have multiple independent
certificates assigned to them, with each certificate having a set number
of 'applications' (EFS, authentication, code signing, etc) assigned to
them.
        2) Private keys stored on smart cards never leave the smart
card. At least according to MS resources. There may be some 3d party
smart card management tools which provide private key archival for smart
cards, but even if so it wouldn't come into play here.
        3) Smart card certs don't support EFS.

So, a user can use a cert which is valid for authentication to logon via
terminal services. If that cert is stored locally on the users profile
AND the cert is also valid for EFS, they likely would be able to do
encrypt/decrypt their files (there are some limitations, review the MS
KB articles referenced earlier in the thread). However, having the
private key stored on the smart card would prevent its use in EFS, even
if the cert is authorized for EFS use.

What you probably could get to work for local file encryption, remote
file encryption, and terminal client file encryption, is using an
authentication cert stored on a smart card to logon, and a separate
profile based EFS cert to encrypt/decrypt files. This approach does
have a few caveats mentioned earlier in the thread and in the KB
articles, but the security implications that started this thread need
not necessarily be among them. Reason being, if a user account
_requires_ smart card logon, the password cracking attacks Nicolas
mentioned become ineffective. However, Don't forget your EFS Recovery
Agents! By default, this includes the local administrator account.
You'll want to limit EFS Recovery Agents by GPO, and address their
account security (via strong passwords or smart card logon).

Cheers,

Kevan S.

-----Original Message-----
From: Sarbjit Singh Gill [mailto:ssgill@gilltechnologies.com]
Sent: Friday, May 28, 2004 12:29 PM
To: 'Langston, Fred'; 'Kim Oppalfens'; Kevan Smith; 'Nicolas RUFF
(lists)'; focus-ms@securityfocus.com
Subject: RE: Relative Security Provided by Cached Domain Credentials?

 
So when a user logs on the w2k terminal using a smartcard + pin no
(rather then the usual A;t-Ctrl-Del), does the private certificate from
the smartcard get copied into the profile data on the disk ? If it does
then EFS works with smartcards, cause when EFS is decrypting, it looks
at the use profile currently logged on for the private certificate.
Please advice.

/Gill

-----Original Message-----
From: Langston, Fred [mailto:flangston@verisign.com]
Sent: Wednesday, May 26, 2004 5:51 AM
To: 'Kim Oppalfens'; Kevan Smith; Nicolas RUFF (lists);
focus-ms@securityfocus.com
Subject: RE: Relative Security Provided by Cached Domain Credentials?

Here's a reference for EFS and smart cards:
http://www.petri.co.il/how_does_efs_work.htm

This is the relevant text:

EFS's key-storage mechanism is based on W2K's CryptoAPI architecture,
which stores users' public and private keys separately from the randomly
generated FEK. This setup lets users store their private keys on secure
devices (e.g., NTFS volumes, smart cards). Smart cards, which require
smart card readers on computers, are credit-card sized devices that let
users log on to W2K with a PIN. Smart cards make personal information
(e.g., account numbers, passwords, digital certificates) portable.

Fred Langston, CISSP
Principal Consultant
VeriSign, Inc.
W: 206.903.8147 x223 M: 425.765.3330
FLangston@VeriSign.com

-----Original Message-----
From: Kim Oppalfens [mailto:Kim.Oppalfens@azlan.be]
Sent: Tuesday, May 25, 2004 6:56 AM
To: Kevan Smith; Nicolas RUFF (lists); focus-ms@securityfocus.com
Subject: RE: Relative Security Provided by Cached Domain Credentials?

I have seen mentioned the use of smartcards for efs certificates in this
thread a couple of times.

Although it would be nice in theory it was my understanding that this
cannot be used at present because not thought about in the efs API, so
during decreption or encryption for that matter only the personal
certificate store is checked for a key, not any smartcard related stuff.

At least that is what I understood about efs and smartcards.
Has any of you actually tested the smartcard solution, or it this how
you would theoratically handle it?

Kim Oppalfens

-----Original Message-----
From: Kevan Smith [mailto:Kevan.Smith@tideworks.com]
Sent: dinsdag 11 mei 2004 22:47
To: Nicolas RUFF (lists); focus-ms@securityfocus.com
Subject: RE: Relative Security Provided by Cached Domain Credentials?

We're testing the completeness of my understanding of Win2K3 PKIs, so
feel free to correct me, but as I understand it the situation isn't
quite as dire as Nicolas makes it sound.

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.

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.

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

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.

Cheers,

Kevan S.

* Private/Public key pairs may be archived to the CA under the
following
circumstances:
        - V2 certificate (V1 certificates cannot be archived)
        - Issued FROM a Windows 2003 Enterprise or DataCenter edition CA

                (not Standard Ed)
        - Issued TO a user (as opposed to a computer)
        - Issued FOR encryption/authentication purposes (not signing/
                non-repudiation).
        - Client certificate must be stored in the user profile. You
cannot

                archive certificates issued to a smart card.

-----Original Message-----
From: Nicolas RUFF (lists) [mailto:ruff.lists@edelweb.fr]
Sent: Tuesday, May 11, 2004 11:02 AM
To: focus-ms@securityfocus.com
Subject: Re: Relative Security Provided by Cached Domain Credentials?

> triple DES from memory
>
>>On a related note to part of the discussion in the 'Restricting change

>>of local admin' thread, does anyone know of a non-brute force way to
>>break the encryption on cached domain credentials? Local accounts are

>>easily modified or reset, but I'm not aware of any similar exploits
>>for cached domain credentials. Given that EFS' effectiveness to
>>secure laptop-stored data in a domain environment lives and dies by
>>the security of the cached credentials, I'm curious to know just *how
>>much* more secure they are.

        Hi,

About EFS :
-----------

- EFS encryption is 3DES (unless you have a restricted export version of
Windows), with a random FEK (File Encryption Key) for each file.
- FEK is encrypted with RSA, using the EFS User Certificate (Public
Key).
- Eventually, the user Private Key is encrypted with his Windows
Password.

So if you know the user password, you can decipher all EFS encrypted
files.
See "Advanced EFS Data Recovery" tool from ElcomSoft :
http://www.elcomsoft.com/aefsdr.html

About Cached Logons :
---------------------

Cached logons are stored in LSA Secrets and NL$ hidden keys. Basically,
it is a salted hash :
NTLMHash( username + NTLMHash(password) ) so you have to bruteforce. The
salt key is the username, so if you have N accounts to crack, it takes N
times the time to crack one account.

Since this attack is very time-consuming and has little chance to
succeed if user password > 6 chars, there is no public exploit
available. Hint : get an IDA Pro license if you want to know more :-)

-nicolas-

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

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

• Previous message: Sarbjit Singh Gill: "RE: Relative Security Provided by Cached Domain Credentials?"
• Maybe in reply to: Zack Schiel: "Relative Security Provided by Cached Domain Credentials?"
• Next in thread: Sergey V. Gordeychik: "RE: Relative Security Provided by Cached Domain Credentials?"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]