Syskey password on ...
 
Notifications
Clear all

Syskey password on startup

18 Posts
4 Users
0 Likes
2,289 Views
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

I checked a bit around, and it seems you found a new (please read as old wink ) interesting topic of research.

It seems to me like all the original work on Syskey protection has been made a looong time ago and nowadays, with the new info we have available there may be some possibilities.

The original work by Nicola Cuomo
https://web.archive.org/web/20060511000813/http//www.studenti.unina.it/~ncuomo/syskey/syskey.txt
Sets aside modes #1 and #2

The key used by Syskey to encrypt the password hashes (called bootkey
or system key) can be generated and stored in three ways. The method
to use is selected when running syskey.exe on the host.

1) Using a user supplied passphrase(actually the MD5 hash of it). The
system will prompt for the passphrase during startup.

2) Using a system generated key stored on a floppy. The system will
ask for the boot floppy during startup.

3) Using a system generated key stored on the "the local system using
a complex obfuscation algorithm" (citing Microsoft site[2]). This is
the default method used.

In the first two cases generally nothing can be done. If you cannot
get the passphrase or the boot floppy you are compelled to crack the
syskeyed hashes.

The last case is different.

and analyzes mode #3 only, but the paper is (and study/programs) are several years old, dating back at the time where MD5 (or a similar hashing algorithm) was considered "secure" or at least outperforming the capabilities of most computers.
Maybe today, with the increased computing power and thanks to a few new approaches it may be possible to "attack" modes #1 and #2.

Also the other "main" documentation, which is the analysis and tool by Peter Nordahl
http//pogostick.net/~pnh/ntpasswd/
though updated/bettered/what not, remains within the "limits" of the original research
http//pogostick.net/~pnh/ntpasswd/syskey.txt
a Syskeyed system can only be accessed through removing Syskey altogether (thus losing Users passwords and EFS keys).
Please note how the latter document numbers the modes according to the values in Registry (different from the previous doc)

However the value named 'SecureBoot' holds the mode of syskey
1 - Key in registry
2 - Enter passphrase
3 - Key on floppy

But removing this key (or setting it to 0) isn't enough to disable
syskey. There's more..

It seems to me ? like it should be *somehow* possible to brute-force (or dictionary) attack offline the Registry anyway, provided that a collision can be generated on the StartKey.key MD5 crypt hash
http//www.pearsonitcertification.com/articles/article.aspx?p=25090

However, now there is a problem how to protect the Syskey. This protection may be implemented in one of three ways

  • The Syskey is obfuscated and stored in the Registry. System can boot without administrative action.
  • The Syskey is obfuscated and placed on a floppy disk that must be present when the system reboots. The Syskey is not stored anywhere on the system. The key is stored in a file call STARTKEY.KEY. Do not store the key on an ERD. To do so would be to provide two items needed to attack your system in one location. Do make copies of the disk. Without it you cannot boot your Windows NT system.
  • A passphrase is entered and then used to create encrypt the Syskey. An MD5 cryptographic hash (digest) of the Syskey is stored in the Registry. The password must be entered during system boot to make the system usable.

In either the floppy disk choice or the password choice, the Syskey is not stored anywhere on the system. Therefore, these choices are more secure. If the floppy disk is lost or becomes corrupt, however, or if the password is forgotten, the system cannot be booted.

The known program SAMINSIDE has a "side tool" called PasswordToSyskey.exe that can seemingly generate a Startkey.key from a given password/passphrase, so the missing step is "connecting" the StartKey.key to it's Cryptographic MD5 hash in the SAM.

I believe that - one way or the other - this is the approach PSPR uses
http//elcomsoft.com/help/en/pspr/index.html
http//elcomsoft.com/help/en/pspr/recoveredhashes.html

Please note that usually the SAM database is encrypted with a locally stored system key, and PSPR automatically decrypts it, but the SYSKEY utility can be used to additionally secure it by moving the SAM database encryption key off the Windows-based computer. The SYSKEY utility can also be used to configure a start-up password that must be entered to decrypt the system key so that Windows can access the SAM database. If the local machine is configured this way, PSPR can try to recover this start-up password click on Find SYSKEY startup password link to open a new window where you can set brute-force and dictionary attack options. The same window is opened if you dump password hashes from external SAM and SYSTEM files (in Manual mode), or if the start-up password is known, you can enter it there (or if SYSKEY is stored on a floppy disk, provide PSPR with it in order to get password hashes decrypted for further attacks).

As it happens I have devised solution #3, a clunky workaround that can preserve EFS but breaks some of the OS.

Care to share some info on this? ?

jaclaz

 
Posted : 08/06/2014 1:44 pm
(@robinsage)
Posts: 28
Eminent Member
Topic starter
 

Care to share some info on this? ?
jaclaz

I was waiting for Jamie to review this thread. Last time I revealed wink a workaround for a program the software company demanded the thread be removed ( Lesson learned etc.

Anyhow, it's not rocket science, just joined up some dots. For EFS it's documented that if the password is changed offline, then access is lost. However, if you can restore the original password then it all works again.
So,
1. obtain user login password by asking in my scenario / cracking with usual tools if required.
2. remove syskey (and blank password)
3. reset user password as per #1
4. reboot & login
5. access EFS / Export keys

I used Passcape's Reset Windows Password tool http//www.passcape.com/reset_windows_password to reset the syskey. The free tool from Petter Hagen http//pogostick.net/~pnh/ntpasswd/ is next on the list.

Pascape warn that "After you reset the password, you may temporary lose access to your Web site passwords, file share credentials, Wireless connection passwords, EFS-encrypted files, e-mails encrypted with your private keys, other personal data encrypted with DPAPI"

As Dr.McCoy said " it's worse than that…"

Somethings are definitely broken in the windows crypto as highlighted with wifi security. WiFi can connect to open APs but WireShark shows no packets are transmitted when you attempt to join WEP / WPA / WPS networks. Normal LAN works fine but as this is in a VM or just a test then it doesn't matter if you can get the files. I have tried resetting perms on the Registry and Windows folder. I guess comparing before / after reg is a logical step.

Insecurety Research has a write up on SAMSRV.dll http//insecurety.net/?p=768

Well that's it. It works for me. Hopefully it may be of some use for you too.

alice

 
Posted : 08/06/2014 10:35 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Insecurety Research has a write up on SAMSRV.dll http//insecurety.net/?p=768

Yep, that is more or less the idea, though I have - being picky - to underline how the F format may not be documented but it is "known", see as an example
http//sourcecodebrowser.com/samdump2/1.1.1/samdump2_8c.html

I have no idea if it is possible, mind you, but in the case of the "computer repair ransom", the "normal" login passwords are not changed (and the legitimate user already knows them).

So, you are in a "special" situation of the "passphrase to start up", where you actually know the passwords but you don't know the key used to encrypt them.

Maybe something *loosely similar* to a known plain text attack is possible. ?

jaclaz

 
Posted : 09/06/2014 12:03 am
(@robinsage)
Posts: 28
Eminent Member
Topic starter
 

A variation on the original scenario is that startup password has been set, but the system not shutdown yet. A temporary solution is to not shutdown / reboot the system, and just use hibernate as necessary. A system "resume" does not generate the "startup" prompt.

alice

 
Posted : 09/06/2014 4:04 am
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

A variation on the original scenario is that startup password has been set, but the system not shutdown yet. A temporary solution is to not shutdown / reboot the system, and just use hibernate as necessary. A system "resume" does not generate the "startup" prompt.

alice

Yep, that shoudl be only for "cold boot".
But I presume the end user won't be aware that the Syskey settings have been changed untill he/she actually reboots, otherwise it would be simpler to just run again the Syskey tool and change back the settings (but to do that one would need to have the password cry ).
I cannot say if in that case (system up and running) one of the "dumping" tools can save/recover the password.
Maybe it would be needed a *somehow* "hacked" syskey that bypasses the verification of the "old" password. ? (allowing to change the settings without providing it).

jaclaz

 
Posted : 09/06/2014 1:58 pm
(@robinsage)
Posts: 28
Eminent Member
Topic starter
 

Apologies for this EFS related but slightly off topic question -

Whilst reading up on syskey I saw this reference to "offline EFS file(s) & Key transplant to another system" o over at http//www.beginningtoseethelight.org/efsrecovery/index.htm The page is somewhat dated 06/2003. Has anyone actually tried this method?

alice

 
Posted : 10/06/2014 2:55 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Never dealt with EFS.

What I can say is that in the past other info on that site came out as accurate and valid, and that specifically the contents of that page "sound" right and appear in accordance with
http//ntfs.com/using-encrypted-files.htm
http//ntfs.com/internals-encrypted-files.htm
http//ntfs.com/attribute-encrypted-files.htm
http//ntfs.com/issues-encrypted-files.htm

jaclaz

 
Posted : 10/06/2014 4:11 pm
(@robinsage)
Posts: 28
Eminent Member
Topic starter
 

As a former old'school ms techie I'm always wary of EFS foul ups. I'll give the hex edit a try, but not soon. Real work to do etc )

thanks for your feedback and links. D

alice

 
Posted : 10/06/2014 5:45 pm
Page 2 / 2
Share: