NT/2000 Sam's fragile security mechanism

* ** Basic Sam file knowledge ***

The Security Account Manager (Security Account Manager) mechanism is used for security management of user accounts in Windows NT and win2000. The Security Account Manager manages Accounts through security identification, the Security ID is created at the same time when the account is created. Once the account is deleted, the Security ID is also deleted. The Security ID is unique. Even if the user name is the same, the Security ID obtained at each creation is completely different. Therefore, once an account is deleted, its security id no longer exists. That is, using the same user name to recreate the account will also be assigned different security IDs without retaining the original permissions.

The security account manager displays the % SystemRoot %/system32/config/SAM file. The Sam file is a user account database of Windows NT. All information about the login name and password of the NT user is stored in this file. Sam files can be considered similar to passwd files in Unix systems, but they are not so intuitive and clear. Passwd uses the format of saving text to save information. This is an example of the content of the Linux passwd file.

0: Root: 8l7v6: 0: 0: Root:/root:/bin/bash
1: Bin: *: 1: 1: Bin:/bin:
2: daemon: *: 2: 2: daemon:/sbin:
3: ADM: *: 3: 4: ADM:/var/adm:
4: LP: *: 4: 7: LP:/var/spool/lpd:
5: Sync: *: 5: 0: Sync:/sbin:/bin/Sync
6: shutdown: *: 6: 0: shutdown:/sbin/Shutdown
7: Halt: *: 7: 0: Halt:/sbin/halt
8: Mail: *: 8: 12: Mail:/var/spool/mail:
9: News: *: 9: 13: News:/var/spool/news:
10: uucp: *: 10: 14: uucp:/var/spool/uucp:
11: Operator: *: 11: 0 perator:/root:
12: games: *: 12: 100: games:/usr/games:
13: gopher: *: 13: 30: gopher:/usr/lib/gopher-data:
14: ftp: *: 14: 50: FTP user:/home/ftp:
15: Nobody: i0ij.: 99: 99: Nobody:/home/httpd:/bin/bash
16: David: c6cuzm: 500: 500:/home/DAVID:/bin/bash
17: dummy: fivtl4igu: 501: 503:/home/dummy:/bin/bash
18: msql :!! : 502: 504:/home/msql:/bin/bash
Each line in the passwd file in UNIX represents a user data, and each account has seven data parts. The format of the split is as follows:
Account name: Password: uid: GID: Profile: user directory: Shell
Except that the password is encrypted (the password here has been shadow), other projects are very clear.
This is not the case in NT. Although it also saves account information in files, if we open these nt sam files in the editor, we can't see anything except garbled characters. Because the NT System encrypts all the data, the General Editor cannot directly read the information. In the Registry
HKEY_LOCAL_MACHINE/SAM
HKEY_LOCAL_MACHINE/security/SAM
The contents of the SAM file are saved. Normally, only the system file can be read and written.

* ** How does nt account information be stored in the SAM file? ***

Two different passwords are saved in the SAM file: The LanManager (LM) hash algorithm and the more powerful encrypted NT Version. Lm is the weakness of the NT password file. Let's take a look at how the LM password algorithm encrypts the password. Consider a password like this: ba01ck28tr. Such a password can already be called a safe password, although it is not! # Special characters including uppercase letters, lowercase letters, and numbers. It can be considered as a password that meets security requirements.
Lm's password processing method is: if the password is less than 14 characters, use 0 to fill up the password with 14 characters, and convert all the letters to uppercase letters. Then, the processed passwords are divided into two groups of numbers, each of which is 7 digits. The password we mentioned just now becomes ba01ck2 and 8tr0000 after being processed. Then, the two seven-digit numbers generate the eight-digit des key, each eight-digit des key uses a magic number (which encrypts 0x4b47532140232425 with a key full of 1) to encrypt it again, connect the two encrypted strings together. This is the final password hash. This character transfer seems to be a whole, but the cracking software such as L0phtCrack can independently crack the two parts of the password string. Therefore, the password mentioned above (10 digits) is cracked ), because the password has been divided into two parts for cracking, and the latter part of the password has only three digits, it is not difficult to crack. The actual difficulty lies in the first seven passwords. Therefore, for NT, a 10-bit password is less secure than a 7-bit password. We can also understand that the password 1234567 * $ # may not be as secure as the password shic6. (The question about how to set a security password is not the scope of this article. If you are interested, refer to the relevant articles)
The official password (encrypted NT Version) is to convert the user's password into unicode encoding, and then use the md4 algorithm to encrypt the password.

The reason why nt retains two different versions of passwords is due to historical reasons. In a pure NT environment, the LAN Manager password should be disabled. Because the LAN Manager password uses weak DES keys and algorithms, it is easier to crack. In comparison, the NT official password using strong encryption algorithms should be safer.
However, the encryption methods for these two passwords are still insufficient in general. Therefore, Microsoft built a tool for syskey.exe to further strengthen the NT password in the patch behind win nt4's SP3. This software can be used. The Administrator only needs to run the program and answer some configuration questions to add this enhancement function. (Windows2000 has been set as the default installation)
How does syskey work to prevent easy access to the Sam password?
When the syskey is activated, the password is encrypted before it is stored in the registry. However, after the machine is started, the information in the old format will still be stored in the memory, because the password information in the old format is required for network verification.
We can think that syskey uses a method to mess up the password information. Or a CMK is used to activate the syskey. This key can be saved on a floppy disk, generated by the user at startup (generated by the user's entered password), or saved directly in the registry. Because there is no official technical instruction on how to disable syskey, once syskey is enabled, it will be disabled unless you use a registry backup before enabling syskey to restore the registry.

* ** What happened to the system after activating syskey? How do I disable syskey? ***

-1-

After activating syskey, the new key value 'secureboot' is added to the Registry HKLM/system/CurrentControlSet/control/LSA to save the syskey settings:
1-the key is saved in the registry.
2-The key is generated by the password entered during user logon.
3-Save the key in a floppy disk
However, if you delete the primary key or set the value to 0, you cannot disable syskey. It seems that there are other places ......

-2-
HKLM/SAM/domains/account/F is a binary structure, which usually stores the SID of the computer and other description information. When the syskey is activated, the content increases (about twice the original size). It is estimated that the Encrypted Key + some tags and other values are added, some of these tags and values contain the same content as secureboot. Therefore, in NT4 (SP6 patch package installed), you can disable syskey by setting these flag bits to 0. When changing these settings, the system provides an error message indicating that Sam and the system settings conflict with each other. However, after the computer is restarted, the system no longer uses syskey.

-3-
Another part of Win2000 also stores information about syskey.
HKLM/security/policy/polsecretencryptionkey/
This is also a binary structure and uses the same storage method. If the corresponding part is set to 0, syskey has been removed from Win2000. (If these three changes have an error (inconsistent), the system will automatically restore to the default value at the next start)

-4-
And the password information section. The old password is 16 bytes in length, but the length is increased to 20 bytes after syskey is used. The first four bytes seem to be a counter, which may be a historical usage record counter. It is strange that when the syskey is activated, it is not recorded immediately, but recorded at the next startup of the system. In addition, when the key is changed, the password information does not seem to be updated accordingly.