21th Jan 2003 [SBWID-5939]
COMMAND
	Attacking EFS through cached domain logon credentials
SYSTEMS AFFECTED
	All Windows Encrypted File Systems
PROBLEM
	Todd    Sabin    [[email protected]]of    BindView     RAZOR     Team
	[http://razor.bindview.com] says :
	Recently, I stumbled upon a page on Microsoft's website,
	
	  http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/news/efs.asp
	
	which talks about  possible  attack(s)  against  EFS,  by  changing  the
	Administrator's password. The conclusion of the article is that this  is
	only possible if the user whose account  is  being  attacked  is  not  a
	member of a domain.
	This is not completely correct, and I wanted to clarify  how  an  attack
	against a domain-member's EFS  encrypted  files  can  work.  The  threat
	model is this:
	Some corporate user has a laptop, and logs into it  as  a  member  of  a
	domain, say CORP\bigshot. He has sensitive  files  on  the  laptop,  and
	keeps them encrypted with EFS. The CORP network administrators are  very
	diligent, and have removed any EFS recovery agent keys from the  laptop.
	Nevertheless, while on the road, the  user  can  still  log  in  to  the
	laptop as CORP\bigshot and use the encrypted files.
	Now, some bad guy steals the laptop. Can the bad guy read the  encrypted
	files?
	The answer is that it depends (at least) on the strength of  the  user's
	password. Depending on your users and your password policy,  this  might
	vary from, "Trivial", to "Quite difficult".
	Bad Guy attacks as follows:
	
	1.  Steals the laptop
	2.  Uses chntpw to change the Administrator's password.
	3.  Logs on as Administrator, using the password just set.
	4.  Dumps the CORP\bigshot's cached logon credentials.  I wrote a
	tool, hashpipe, which dumps these.  (Hashpipe has not been publicly
	released, and I have no plans to release it.  But if I can do this,
	plenty of other people can, too.)  These cached credentials are what
	allow the user to logon without a domain controller being reachable.
	They are not the same thing as the user's password hash, but a
	function of it and the username.  Nevertheless, it is enough
	information to use in cracking the user's password.
	5.  Runs a dictionary attack against this "cachehash".  If that
	doesn't yield the user's password, go to brute force.  If the user's
	password is not particularly strong, he'll end up with the users's
	plaintext password in a few days.
	6.  Logs in as CORP\bigshot, and reads all the encrypted files.
	
	I did a demo of this exact attack, except for step 1, at BlackHat 2001.
	Can other SYSKEY modes help?  Given  this  threat  model,  probably  not
	much. If the laptop has SYSKEY set to require a boot floppy, the  floppy
	is probably going to be in the laptop bag, if not right  in  the  floppy
	drive itself, and be stolen right along with the laptop. If  the  laptop
	has SYSKEY set to require a boot password, then the  attacker  just  has
	another  password  to  crack.  (Cracking  a  SYSKEY  boot  password   is
	different from cracking a cached domain logon credential,  but  just  as
	feasible.)
SOLUTION
	In summary, if all your users have  to  do  to  access  their  encrypted
	files is type their password, that's all an attacker is  going  to  have
	to do. If your users have easily crackable passwords, it doesn't  matter
	if the files are encrypted with 128 bit DESX. One thing which  may  help
	is smart cards, but I haven't looked at that scenario, so  can't  really
	say one way or the other.
	Also, bear in mind that the above is just one  possible  attack  against
	EFS.
	Maybe you've don't actually have 128 bit encryption?
	
	 http://www.newscientist.com/news/news.jsp?id=ns99991804
	
	Maybe the attacker was sitting next to the  user  on  an  airplane,  and
	watched him type his password. The attacker wouldn't even have to  crack
	the password.
	Maybe the user just closes his laptop when he's  done  working,  doesn't
	log out or shutdown, and has set his  Windows  2000  not  to  require  a
	password when waking up. The attacker  wouldn't  need  the  password  at
	all.