Is there a way to 1) bypass XP Pro Syskey that requires a startup passphrase,  and 2) bypass EFS -- in order to access files that were created within EFS-encrypted folders

I have edited the original post located here:  http://www.experts-exchange.com/Security/Q_21210532.html
This thread went off topic and deserved it's own dedicated thread with it's own points.

 
Comment from richrumble  feedback
Date: 11/21/2004 05:44PM PST
 Comment  


You could try exporting the syskey to floppy, but it's really of no real use, the SAM is just as vulnerable as it ever was with or without syskey. Syskey only run's when the PC is booted, so if someone used a floppy to read the SAM "offline" while the PC isn't booted with widows, the SAM has no additional encryption from syskey, even in XP, or 2003. Also, using any one of the modern SAM hash readers, Pwdump3, Pwdump3e, Pwdump3v2, or NTDump- syskey has no effect on them.
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_zbxr.asp

Now depedning on what method you encrypted you My Doc's folder with, you may have other issues. if you use M$ EFS, you definatly need to export your encryption key's to floppy or other media.
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_kcef.asp
http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/cryptfs.mspx

The problem with the syskey in XP is this, once the password is entered... then there is no more "extra" encryption- it's decoded because you entered the right password.

You might also look at this SID reader program from sysinternals
http://www.sysinternals.com/ntw2k/freeware/psgetsid.shtml
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prnb_efs_jskn.asp

-rich
 
Comment from SAbboushi
Date: 11/21/2004 06:31PM PST
 Your Comment  


Thanks richrumble-

>> the SAM has no additional encryption from syskey, even in XP,
According to the following link, syskey does add additional encryption to sensitive contents of the SAM (mostly master keys): link, http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/windows/xp/all/reskit/en-us/prnb_efs_zbxr.asp
A startup key (also called the syskey) can be used to protect all master keys as well as a variety of other secrets that are stored on computers. At system startup, the startup key is used to encrypt all of the private keys on the computer, including private keys that are used for EFS. Startup keys are automatically generated and used for computers in a domain but must be manually configured on stand-alone computers. Startup key security can be increased by storing the key on removable media or by requiring a system startup password.

 
Comment from richrumble  feedback
Date: 11/22/2004 05:24AM PST
 Comment  


... despite syskey's intentions- with the tools available today- syskey offers no additional protection from these tools obtaining the information syskey aim's to protect.

That said, http://support.microsoft.com/?kbid=288348 states the the encryption key's for EFS should be exported, then restored to an imaged PC. I'll bet the same might hold true for syskey, it is able to be exported to removable media, and it is possible to restore to the imaged pc. I've not seen this issue with syskey and sysprep, I can test again to see. I assume your using the latest version of sysprep- actually for XP you should use the sysprep from the XP Service Pack1 Deployment tools http://www.microsoft.com/downloads/details.aspx?FamilyID=7a83123d-507b-4095-9d9d-0a195f7b5f69&displaylang=en

...

GL!
-rich
 
Comment from SAbboushi
Date: 11/22/2004 06:59AM PST
 Your Comment  


Hi richrumble-

...
On a separate note, your are stating that the tools today can "obtain the information syskey aims to protect".  That concerns me.  I understood that it would take a few decades to crack EFS using today's supercomputers.  I understand that the only feasible way to access EFS encrypted files is to get the master key.  I understand that syskey encrypts the master key with EFS level encryption.  I looked at pwdump3 and found this:
>> Using this tool, a system administrator can check on the strength of the passwords on his system.
>> Please note: pwdump3 does not exploit a new vulerability; it utilizes
>> existing Windows communications capabilities. To use the program
>> successfully, one must supply a username and password that has
>> administrative-level privileges on the remote system.
This does not seem to support what you are implying.  I would be VERY interested to find out how one could defeat the syskey and EFS encryption on my machine and get access - I would be grateful if you could provide further details (although this is not related to my problem...)

Another observation - the links you have provided in the past couple of posts do not support your position that syskey adds no additional encryption.  

You refer to "exporting" the syskey; I believe you use Syskey to "encrypt" parts of the SAM which then requires a password or startup disk to decrypt parts of the SAM upon startup.  I configured syskey to require a password upon startup instead of requiring a startup disk.  ...

Richrumble - I really appreciate your efforts - I can tell that you have put time into your posts and creating the links.  ...

With Regards-
Sam
 
Comment from richrumble  feedback
Date: 11/23/2004 06:26AM PST
 Comment  


Understood, no problem.
Let me see if I can clarify.
Syskey- Syskey SAM encryption establishes a 128-bit cryptographic password encryption key as opposed to the 40-bit mechanism that ships by default (from NT4sp3-2003)
The failing or short comming of syskey as I see it:
     1) Syskey does not perminatly encrypt the information it is protecting, meaning that using a linux floppy (or NTFS-DOS floppy) to mount the HD and read the SAM will result in someone being able to read the SAM in the default 40-bit LanMan and NTLM hashes, not the 128-bit versions.
     2) While PwdumpX does require admin privleges to run properly, gaining admin is still a trivial process on winblows for the average LAN or user. PwdumpX uses dll injection, which is something that M$ would have to work very hard to re-write their kernel to prevent. While Dll injection isn't used by programs as a typical means-to-an-end, it nonetheless works for pwdumps purposes. http://www.bindview.com/news/display.cfm?Release=/99/1222.txt (only affected nt4)
http://www.microsoft.com/technet/security/bulletin/fq99-056.mspx

The reason Pwdump works is this, number one the administrator of the PC cannot even access the sam, only the highest account can, which is system. System trust's the admin account a little to much, and allows the dll injection/dll hooking to take place, giving the program system creditnitals to read the SAM. While syskey does encrypt the sam with 128-bit encryption in MEMORY, what is written to the HD is still the 40-bit key- and that's what pwdump reads the HD. http://www.winnetmag.com/Article/ArticleID/14780/14780.html a very good article, with better links.

johnTheRipper makes short work of LanMan hashes, it's the fastest cracker out there for NT, espically if you run it on linux, it's 10x faster than the windows port of john, and if using rainbow crack, passwords are practically instantenious.

...

Also of note, if the SAM is deletedaltogether off the HD, syskey enabled or not, the local admin will be a blank password. If there is a passphrase and even if the key's are stored on a floppy, using chntpw or the linux floppy can get around those just fine.

GL! I hope this helps.
-rich



 
Comment from SAbboushi
Date: 11/23/2004 07:35AM PST
 Your Comment  


richrumble - I certainly admire the depth of your technical knowledge on this matter.

My comments for further understanding
1) You are saying that by enabling syskey, no further encryption whatsoever is made to any of the SAM - that the startup password I have assigned with syskey is stored in the SAM using 40-bit encryption, that enabling syskey (with startup password prompt) results in the following process:
a) read the 40-bit startup password from the SAM
b) re-encrypts it using 128-bit encryption in memory
c) have XP Pro prompt for a startup password
d) encrypts the entered startup password in memory using 128-bit encryption
e) match the two passwords in memory using (b) and (d)
f) continue the XP Pro startup process upon a match?
Did I understand that right?

>> Syskey does not perminatly encrypt the information it is protecting
I am confused - the link you provided (http://www.microsoft.com/technet/security/bulletin/fq99-056.mspx) says "Syskey is designed to prevent password cracking attacks by encrypting the SAM database using 128-bit cryptography."  It goes on to say that the stream-reuse flaw was patched and that "The patch returns the protection to its stronger state by eliminating the key reuse."    It confirms what you said (only affected NT4), and confirms that this was not a problem for Windows 2000.  I am using XP Pro.

Your other 2 links (http://www.bindview.com/news/display.cfm?Release=/99/1222.txt and http://www.winnetmag.com/Article/ArticleID/14780/14780.html) confirms this bug/vulnerability and references the Microsoft bulletin and patch from almost 5 years ago.

Do you still believe that this 5 year old NT vulnerability exists in XP Pro? Or am I somehow missing your point (I do that sometimes...)

Your link http://www.winnetmag.com/Article/ArticleID/14780/14780.html referenced the following link:  http://support.microsoft.com/kb/q143475/ which says:

System Key hotfix: Strong encryption protects private account information by encrypting the password data using a 128-bit cryptographically random key, known as a password encryption key.
Only the private password information is strongly encrypted in the database, not the entire account database. Every system using the strong encryption option will have a unique password encryption key. The password encryption key is itself encrypted with a System Key. Using strong encryption of account passwords adds additional protection for the contents of the SAM portion of the registry and subsequent backup copies of the registry information


>> While syskey does encrypt the sam with 128-bit encryption in MEMORY, what is written to the HD is still the 40-bit key
The pasted text above seems to contradict your statement by stating that the the "information is strongly encrypted in the database".  Again, please let me know if I am misunderstanding what you are trying to tell me or if there is a link that will substantiate this.

...

richrumble - my brain hurts - you make me think!  
With Great Restpect
Sam
 
Comment from richrumble  feedback
Date: 11/23/2004 10:51AM PST
 Comment  


You make me type, i think that's worse... ;p
I understand the porblem. M$ is saying one thing (with the links I am providing), however it's been greatly documented that the protection they are promising isn't a reality. And it's easy to see for your self. using NTFS-DOS or the linux boot floppy/cd-rom. In order for M$'s Syskey to work as "advertised" the sam hashes would have to be the 128-bit versions of the 40-bit hashs- and then write that to disk. However, even in win2k-xp-and 2003 this is not the case. The syskey encryption works the same way NT-Auth works, by comparing hashes.
(from reading your last post, I'm sure you get these basics- but just in case)
When you type in your password to log-on to a pc, the pc looks at what you typed, then contact's the Domain Controler (or GC) and they negotiate another round of encryption called a challenge hash, then the DC/GC uses that challenge to encrypt the password it has in the DC/GC sam hash for that user name. The DC/GC waits to hear from the workstation. The workstation then encrypts what you typed with the LanMan/NTLM hash, then encrypts that NThash with the challenge, once both have been encrypted, that data is sent to the DC/GC. The DC/GC looks to see if that matches what it computed, if it does, your auth'd and you log-in. If not, your asked to try again.
Syskey does the same, it uses the values in the SAM on the HD, then encrypts that hash with the 128-bit algorythim on top of the 40-bit versions in the SAM, and stores that in memory.
If you turn off a syskey enabled PC suddenly (like pulling the power cable out), and you read the SAM off-line using a boot disk, you'll see that syskey doesn't write the 128-bit value to disk at any time.
The startup password is yet another Auth Mechanism, which was not available in the first itteration of syskey btw. I think once M$ figured out that syskey wasn't much of anything, they added the additional password function, this to me seems a lot like a bios boot password.

Now while you cannot reliably disable syskey after it's been enabled- what I would do is recreate the master image, and not enable syskey on the master image. Then when i imaged a PC, i'd turn on syskey after mini-setup finished.
Also, the vulnerability mentioned above did only apply to NT4, and nothing afterwards- so I do not see this affecting anything nowadays.

...

-rich

 
Comment from SAbboushi
Date: 11/23/2004 02:05PM PST
 Your Comment  


Thank Rich-  

I would like to do the test you suggest - I have ntfs-dos on a dos boot disk (I am still "Linux-stupid").  What exactly am I looking for to confirm that the passwords in the sam are NOT encrypted with a 128-bit key and is as vulnerable as you say with syskey enabled?

By the way, I am on a workgroup - no Domain controller.

>>  however it's been greatly documented that the protection they are promising isn't a reality
>>  this to me seems a lot like a bios boot password.
>>  Syskey does the same, it uses the values in the SAM on the HD, then encrypts that hash with the 128-bit algorythim on top of the 40-bit versions in the SAM, and stores that in memory.

Is your position that Syskey does not perform any encryption on the SAM?  Non-microsoft posts are contradicting this.

Would you dispute the following link:
http://www.windowsnetworking.com/kbase/WindowsTips/WindowsNT/RegistryTips/Miscellaneous/Whathappenswhen
syskeyisinstalledandhowtogetridofit.html

When syskey is active, the hashes are encrypted/obfuscated yet
another time before being stored in the SAM registry.
However, they're stored in the old form in memory after boot
(pwdump2 demonstrates this),
since the old form is needed for NTLM authentication on the network etc.


...

 
Comment from SAbboushi
Date: 11/27/2004 06:36AM PST
 Your Comment  


Hi richrumble -

I haven't heard back from you, so I figure I made you type too much...!

Your posts have been of great value to me - as a result, I have disabled LM Hash storage - so LM Hashes for user accounts are no longer available in my registry for cracking

Regarding your statements that syskey is easily defeated:
>>   despite syskey's intentions- with the tools available today- syskey offers no additional protection from these tools obtaining the information syskey aim's to protect.

From my search on the web, SAMInside seems to be the most recognized password recovery utility that can crack syskey.  I am attaching a link to their response confirming that they CANNOT crack syskey unless the key itself is stored in the registry (syskey obfuscation method that I asked you about in my last post).

http://www.insidepro.com/gb/eng/index.shtml

Subject: Re: SAM/SYSTEM files you request in message 158 to analyze

Hello!

Program SAMInside recovers passwords only if
SYSKEY is located in the Windows registry.
If your SYSKEY is entered on OS boot (or if
you store it on separate diskette), you're to
select menu "Import SAM and SYSKEY files...".
At the same time you aren't to use "GetSyskey" utility to get SYSKEY, but:
- manually create 16-byte file containing key (if you enter it manually); or
- use key stored on separate floppy disk (find more about SYSKEY.EXE use on this
page: http://support.microsoft.com/default.aspx?scid=KB;en-us;q143475)

P.S. Other programs (PWSEX + BKHive&SAMDump2)
also not work with your SAM/SYSTEM-files.

Best regards,
InsidePro Support
E-mail: Support@InsidePro.com
Web: http://www.InsidePro.com

...

Comment from richrumble  feedback
Date: 11/27/2004 11:21AM PST
 Comment  


This is my contention: The 40-bit version of this password: "HelloWorld" is
  Admin:500:NO PASSWORD*********************:F37F57A03351C09D237508F14BAB2AE3::: (no syskey- new machine)
admin:1007:NO PASSWORD*********************:F37F57A03351C09D237508F14BAB2AE3::: (syskey- different machine but syskey enabled for a long time now.)
That is the NTLM hash, the case sensitive version. This is a fresh install of winxp- no syskey enabled. It's also the same key I read from the SAM of a syskey enabled machine, and booted using http://home.eunet.no/~pnordahl/ntpasswd/   The cd-rom version is what I preffer. It will read and show you the hash, even reset a password. With NTFS-DOS you have to copy the sam file off and view it, or you can try to use "type" to show you the contents of it. c:\windows\system32\config\sam

I do disagree with the paper linked above, even though he is the author of the very tool I use to dump/change the hash's. Pwdump3 get's the hash's, even with the password protection, and the floppy storage of the syskey... you'll have to try it to verify I suppose. I'll brb, i'm going to see if I remember how to read the SAM file in the system32\config dir.

...

-rich
 
Comment from SAbboushi
Date: 11/28/2004 10:13AM PST
 Your Comment  


Rich- thanks for the link - (http://home.eunet.no/~pnordahl/ntpasswd).  I tried your preferred CD-Rom version.  Really cool - I will have to keep this CD on hand.

This is what I found:
1) Even with syskey (startup passphrase) enabled, I WAS able to blank Administrator and user passwords as you have said; however, I still needed to provide the syskey startup passphrase to startup before I could log into the user account - and sure enough, blanking the password for any account allowed me to then login without a password.
2) I used the utility to remove syskey - and Windows did boot - but then I was unable to log into ANY accounts, even those whose passwords I had blanked either before AND/OR after I had disabled syskey
The author does note (http://home.eunet.no/~pnordahl/ntpasswd/syskey.txt) that
           "VeryBAD: SWITHCHING OFF IN WINDOWS 2000 AND XP NOT PERFECT,
            WILL CAUSE TROUBLE, but you can access the computer
            afterwards."
In my case, I was NOT able to access my computer.  I was unable to get past the logon screen - but it appears from the author's comments that others can login under XP (maybe changes in SP2 closed vulnerability?).  Most of his work seems to have been for NT with some for Windows 2000:  "resetting this mode flag and SecureBoot to 0 is all that's needed to switch off syskey in NT4 (up to SP6 at time of writing). "

A followup e-mail to InsidePro supports my current belief that there is not yet a method to crack syskey (or that he is also unaware of a method to do so):
SA> I was told that syskey was easy to defeat, even with passphrase or
SA> floppy startup.  However, if I understand you correctly, you are
SA> saying that if I use syskey with startup password, then nobody will
SA> be able to crack my system with password recovery software?
Yes.

Best regards,
InsidePro Support
E-mail: Support@InsidePro.com
Web: http://www.InsidePro.com

... I encrypt "My Documents" with EFS.  So even if there is a method to blank passwords and defeat syskey, I believe that my EFS encrypted data will remain uncrackable.

...
 
Comment from richrumble  feedback
Date: 11/28/2004 11:38AM PST
 Comment  


There should be like 3 warnings for that floppy when turning syskey off... it's never worked for me reliably. Sorry you'll have to start over, but that's life with M$ sometimes. Once you have gotten back to the point where your going to run sysprep- Leave syskey off for the time being, make an image that will change the sid's, and test. If that works, keep that image just in case, then turn on syskey on the pc you derive the image from, then re-run sysprep, hopefully you won't have trouble, if you do still, you can roll back to the saved image just before syskey was enabled.

I was reading through my hacking exposed 3rd edition with reguard to syskey, and making sure I'm not crazy. By blanking the passwords, or changing them, in the sam, then writting them to disk- when the PC boot's up, syskey will take those pass's and encrypt them as it's supposed to, but will not write that value to disk, as I've been maintaing. Granted also, that ADMIN Right's and or Physical Access are required to do so.

Cracking syskey has never been in my claim, however bypassing it is. Syskey only run's when windows is running, and never overwrites the sam to disk. The newest version of the linux-boot-reset utility doesn't allow you to view the hash like it used to, I'm going to look for an old version to see if it does. Copying the SAM using ntfs-dos does also reflect the fact that the hash is the same syskey or no for the "HelloWorld" password.

Syskey will no affect M$ EFS- While EFS seems safe from cracking, it too suffers from a fatal flaw, that I exploit on a monthly basis. EFS creates a efsX.tmp file in the directory that the file or folder being encrypted resides. "X" being a number starting at 0 and incrementing. Even if the EFS key's are exported, the data remains in an unencrypted form on the HD. Using over-writters, formatters, disc wipes, are useless if one is using a good low-level reader like the ones you can get from OnTrack software- http://www.ontrack.com/software/
For years I used Tiramisu, with great sucess, and now we have the whole suite of ontrack's tools. They have paid for themselves twice over this year alone. While EFS encrypted files seem pretty safe if the key's are exported, they are not. Even using OnTrack's own Data Eraser, I am able to recover the data, np.
http://seclists.org/lists/bugtraq/2001/Jan/0304.html http://www.ntfs.com/issues-encrypted-files.htm
BTW, despite claims (again) all HD data is recoverable- depends on what level you wnat to take it to, with an electron-tunneling microscope all HD data is recoverable. But even without one, ontrack's tools are great. Altough data that is in a RAID stripe is difficult to recover.

You keep getting me off the subject ;) Anywho, let me know how your rebuild goes...
-rich