Ken,

I think David's point is that an estimated 50% of the Windows 2000
installations out there might want to reevaluate the benefits of EFS. The
protection offered by EFS can be overcome in almost every situation if your
user account isn't a member of a Windows 2000 domain. That is contrary to
what most people automatically assume when they hear about the nifty W2K
file encryption features.

Even if you do remove the recovery agent private key from the Administrator
account you aren't safe. The Administrator account can reset the password
of any local account. Once reset you log in as that user and decrypt data
using their private key.

If the user account belongs to a domain the local Admin account can't reset
the password. Suddenly the local Admin account isn't looking as useful.
Even this doesn't prevent an attacker from trying to guess the user's
password, once again, to log in and decrypt the data (if you allow cached
logons). But that is a separate challenge.

Now you can argue that most of the 400,000+ laptops stolen last year were
not nabbed for their data content. I'd agree with you. But there are
technology literate criminals who recognize the value of the information as
well as the hardware. These individuals pose a real threat that most people
thought EFS virtually eliminated.

I don't know that Microsoft owns much blame for this one. They've created
documents addressing this issue and included solutions to resolve the
problem. The biggest challenge is educating the rest of the world about
this problem and getting them to change their behavior accordingly.

----
Bruce K. Marshall - brucemlucent.com - 913-338-5090 x114
Lucent Technologies Worldwide Services - Overland Park, KS
> -----Original Message-----
> From: Ken Pfeil [mailto:Keninfosec101.org]
> Sent: Tuesday, June 19, 2001 1:14 PM
> To: Pybus, David; focus-mssecurityfocus.com
> Cc: mpriestmicrosoft.com
> Subject: RE: Boot Partition
>
>
> So you're saying that by resetting the Administrator's
> password with a Linux
> boot disk is going to let you circumvent EFS encryption on
> Windows 2000
> (which uses syskey enabled by default)?
>
> OK, let's say you defeat syskey. You've reset the admin
> password. Wheee..
> Now we're having fun. So you can decrypt the encrypted files
> even though the
> keys were exported? Or are you assuming that every user renames the
> administrator account and uses that to log on? Then again, if
> you've given
> up admin access the game is pretty much over anyway. So the
> point again, is
> what? You can circumvent a security measure by having
> administrator access?
>
> > -----Original Message-----
> > From: Pybus, David [mailto:DPybuscolt-telecom.com]
> > Sent: Monday, June 18, 2001 5:21 PM
> > To: 'Keninfosec101.org'; Pybus, David; focus-mssecurityfocus.com
> > Cc: mpriestmicrosoft.com
> > Subject: RE: Boot Partition
> >
> >
> > If you circumvent EFS using the tool mentioned in the advisory then
> > the attack becomes trivial. Yes there is a specific vulnerability
> > that that
> > can be easily tested in the lab using the tool discussed in
> the advisory.
> > It takes no more than a few minutes and a couple of re-boots to
> > gain access
> > to a local user's encrypted files if EFS has not been properly
> > secured with
> > either a pass-phrase or a floppy. All that is required is
> the tool linked
> > below and a target machine with a floppy. This is the case
> regardless of
> > what other precautions have been taken - no access to
> recovery keys is
> > required. The tool is available from:
> > 	http://home.eunet.no/~pnordahl/ntpasswd/bootdisk.html
> > It provides a host of other interesting functions as well.
> >
> > Regards,
> > David Pybus
> >
> > -----Original Message-----
> > From: Ken Pfeil [mailto:Keninfosec101.org]
> > Sent: 18 June 2001 21:33
> > To: Pybus, David; focus-mssecurityfocus.com
> > Cc: mpriestmicrosoft.com
> > Subject: RE: Boot Partition
> >
> >
> > And given enough time, CPU cycles, and physical access, nearly ANY
> > encryption scheme can be broken. The point is to make it more
> > difficult (not
> > impossible) to recover information when using EFS. You will never
> > reach that
> > point of computing nirvana that will guarantee security of
> information. I
> > must be missing the point of your posting David. Is there
> some type of
> > vulnerability here or are we theorizing hypothetical situations?
> >
> > > -----Original Message-----
> > > From: Pybus, David [mailto:DPybuscolt-telecom.com]
> > > Sent: Monday, June 18, 2001 3:57 PM
> > > To: 'Keninfosec101.org'; Pybus, David; focus-mssecurityfocus.com
> > > Cc: mpriestmicrosoft.com
> > > Subject: RE: Boot Partition
> > >
> > >
> > > The fundamental point of my previous posting was not intended
> > to highlight
> > > the sensitivity of the recovery agent and associated keys but the
> > > dependence
> > > of the security of EFS on using SYSKEY with a secure password.
> > > Removing the
> > > the recovery agents is a standard recommendation made in most
> > > documentation
> > > covering the secure use of EFS.
> > >
> > > By utilising the tool mentioned in the advisory it is
> possible to access
> > > files encrypted by a local user whether the administrator
> keys have been
> > > removed or not. This is because the protection of the
> users keys is
> > > dependant
> > > on the protection of the SAM and the SAM is protected by SYSKEY.
> > > The utility
> > > enables the circumvention of SYSKEY such that passwords can be
> > > reset without
> > > disabling SYSKEY. It is important to reset the password without
> > disabling
> > > SYSKEY as disabling SYSKEY would destroy all the information in
> > > the SAM, in
> > > this case destroying the private keys needed to recover the
> > > encrypted data.
> > >
> > > This dependence on SYSKEY is touched upon briefly in the
> below MS paper.
> > > If SYSKEY is enabled without a password or token then a
> local users
> > > encrypted
> > > files are at risk regardless of what other precautions have been
> > > taken, this
> > >
> > > critical point doesn't quite seem to be made in the existing MS
> > > paper. While
> > >
> > > this is a minor point to get excited about we all know
> that a diligent
> > > hacker
> > > may only need a minor point to gain access to your files.
> > >
> > > Physical access is still needed to exploit this vulnerability.
> > One of the
> > > primary uses for EFS is to prevent access to sensitive files on a
> > > laptop in
> > > the event of its theft. In this scenario it is reasonable to
> > suggest that
> > > the
> > > attacker would have a large quantity of time and full physical
> > > access to the
> > > system, rather the muting the physical access defence.
> > >
> > > Kind regards,
> > > David Pybus
> > >
> > > -----Original Message-----
> > > From: Ken Pfeil [mailto:Keninfosec101.org]
> > > Sent: 18 June 2001 19:55
> > > To: Pybus, David; focus-mssecurityfocus.com
> > > Cc: mpriestmicrosoft.com
> > > Subject: RE: Boot Partition
> > >
> > >
> > > "If anybody out there is intent on using EFS to protect
> > critical files or
> > > data then I would suggest reading"
> > > http://www.microsoft.com/technet/security/analefs.asp (as well
> > as the EFS
> > > help file and nearly every best practice document dealing with
> > > EFS. They all
> > > seem to mention exporting/backing up the recovery certificate and
> > > associated
> > > private key :-)
> > >
> > > Example blurbs..
> > >
> > > "The private keys associated with recovery certificates
> are extremely
> > > sensitive. Never leave them unsecured. Either generate them on
> > a computer
> > > that is physically secured or export the key and
> certificate into a .pfx
> > > file, protected under a strong password and secure that
> file on a floppy
> > > disk. (p20, Using the Encrypting File System, Recommendations)"
> > >
> > > And this "blast from the past":
> > > "The designated recovery agent should export the data recovery
> > > certificate,
> > > secure it in a safe place, and delete the data recovery
> > > certificate from the
> > > system hard disk. In this way, the only person who can recover
> > > data for the
> > > system is the person who has physical access to the data recovery
> > > certificate. (Windows 2000 Server beta 3 RC1 help, Best
> Practices)".
> > >
> > > Needless to say, this is a rather dated "advisory".
> > >
> > >
> > > > -----Original Message-----
> > > > From: Pybus, David [mailto:DPybuscolt-telecom.com]
> > > > Sent: Monday, June 18, 2001 4:17 AM
> > > > To: focus-mssecurityfocus.com
> > > > Subject: RE: Boot Partition
> > > >
> > > >
> > > > If anybody out there is intent on using EFS to protect
> > critical files or
> > > > data then I would suggest reading the following advisory:
> > > > 	http://www.securityfocus.com/archive/2/59550
> > > > It questions the security of EFS when used with Windows
> 2000 in its
> > > > default configuration. The advisory comes from the same team
> > at ISS that
> > > > wrote the MS Windows 2000 Security book.
> > > >
> > > > Regards,
> > > > David Pybus
> > > >
> > > > Security Engineer - COLT Internet
> > > >
> > > > -----Original Message-----
> > > > From: Matt Priestley [mailto:mpriestmicrosoft.com]
> > > > Sent: 01 June 2001 02:50
> > > > To: focus-mssecurityfocus.com
> > > > Subject: RE: Boot Partition
> > > >
> > > >
> > > > This isn't true if you use Encrypting File System in Win2k.
> > You can also
> > > > emulate EFS in code by using the DPAPI (CryptProtectData &
> > > > CryptUnProtectData). In those cases files are
> irretrievable except by
> > > > the creating user - in the case of SAM this would be
> SYSTEM, I think -
> > > > or by an admin with a recovery key. NTFSDOS doesn't work on such
> > > > configs.
> > > >
> > > > -matthew Priestley
> > > > mpriestmicrosoft.com
> > > >
> > > > Phone: 425-703-9478
> > > > Fax: 425-936-7329
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Chris Paget [mailto:mad.nuttermindless.com]
> > > > Sent: Thursday, May 31, 2001 1:25 AM
> > > > To: focus-mssecurityfocus.com
> > > > Subject: Re: Boot Partition
> > > >
> > > >
> > > > One of the easiest ways to hack a 2K box is to boot it
> to DOS, run
> > > > NTFSDOS (from www.winternals.com ), grab a copy of the
> SAM, and throw
> > > > it at L0phtcrack.  I'm sure there are similar NTFS
> tools for *nix.
> > > >
> > > > Having just checked winternals, I see that NTFSDOS now
> allows you to
> > > > write to an NTFS partition from DOS / 98, bypassing all
> ACLs.  If you
> > > > can overwrite any arbitrary system file from your other
> OS, how open
> > > > do you want the box to be?
> > > >
> > > > Iif you only have 2K installed you can set the boot
> order to be HDD
> > > > first, and then password-protect the BIOS - that way
> someone has to
> > > > open the case and clear the CMOS before they can get a
> DOS prompt.
> > > >
> > > > Chris
> > > >
> > > > --
> > > > Chris Paget
> > > > mad.nutermindless.com
> > > >
> > > >
> > > >
> > > > On Wed, 30 May 2001 12:11:12 -0400, you wrote:
> > > >
> > > > >
> > > > >Hey all,
> > > > >
> > > > >I'm in the process of putting together a document summarizing
> > > > >issues related to dual(+) booting operating systems.  I do this
> > > > >religiously at home, where I play, but I am getting an
> > > > >increasing number of requests from clients in business
> > > > >environments (where many of them like to do their playing.)
> > > > >These are primarily small business environments who
> can start to
> > > > >benefit from being connected 24-7.
> > > > >
> > > > >I am interested primarily in security issues (anything and
> > > > >everything) although any other comments on the topic would be
> > > > >appreciated.  All OSes, WIN2K help especially.  For the record,
> > > > >I typically create a small active primary fat partition (10-16
> > > > >M) with good ole DOS6.22 and nothing else, other than necessary
> > > > >boot files.
> > > > >
> > > > >Matthew Tallon
> > > >
> > > >
> > > >
> **********************************************************************
> > > > COLT Telecommunications
> > > > Registered in England No. 2452736
> > > > Registered Office: Bishopsgate Court, 4 Norton Folgate,
> London E1 6DQ
> > > > Tel. 020 7390 3900
> > > >
> > > > This message is subject to and does not create or vary
> any contractual
> > > > relationship between COLT Telecommunications, its
> subsidiaries or
> > > > affiliates ("COLT") and you. Internet communications
> are not secure
> > > > and therefore COLT does not accept legal responsibility for the
> > > > contents of this message.  Any view or opinions
> expressed are those of
> > > > the author. The message is intended for the addressee
> only and its
> > > > contents and any attached files are strictly
> confidential. If you have
> > > > received it in error, please telephone the number
> above. Thank you.
> > > >
> > > >
> > > >
> **********************************************************************
> > >
> > >
> > >
> **********************************************************************
> > > COLT Telecommunications
> > > Registered in England No. 2452736
> > > Registered Office: Bishopsgate Court, 4 Norton Folgate,
> London E1 6DQ
> > > Tel. 020 7390 3900
> > >
> > > This message is subject to and does not create or vary
> any contractual
> > > relationship between COLT Telecommunications, its subsidiaries or
> > > affiliates ("COLT") and you. Internet communications are
> not secure
> > > and therefore COLT does not accept legal responsibility for the
> > > contents of this message.  Any view or opinions expressed
> are those of
> > > the author. The message is intended for the addressee only and its
> > > contents and any attached files are strictly
> confidential. If you have
> > > received it in error, please telephone the number above.
> Thank you.
> > >
> > >
> > >
> **********************************************************************
> >
> >
> >
> **********************************************************************
> > COLT Telecommunications
> > Registered in England No. 2452736
> > Registered Office: Bishopsgate Court, 4 Norton Folgate,
> London E1 6DQ
> > Tel. 020 7390 3900
> >
> > This message is subject to and does not create or vary any
> contractual
> > relationship between COLT Telecommunications, its subsidiaries or
> > affiliates ("COLT") and you. Internet communications are not secure
> > and therefore COLT does not accept legal responsibility for the
> > contents of this message.  Any view or opinions expressed
> are those of
> > the author. The message is intended for the addressee only and its
> > contents and any attached files are strictly confidential.
> If you have
> > received it in error, please telephone the number above. Thank you.
> >
> >
> >
> **************************************************************
> ********

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