Summary: Microsoft states that they encrypt passwords in memory with "reversible encryption”. However, we know that this encryption is easy to overcome as the operating system itself allows for decryption to occur when tools are allowed access to the memory storage locations and automatically retrieve, and the operating system automatically decrypts, the encrypted password. Mimikatz accomplishes “cleartext” password retrieval by invoking a windows sub module called “LsaUnprotectMemory”, which is available to the Mimikatz and other credential harvesting programs when they have access to the debug features of Windows.
Suggested Mitigation: If we remove the wdigest and tspkg support in Windows XP (and later versions of Windows) and limit access to the debug function that allows for the system call that enables the reverse decryption of the encrypted kerberos, wdigest, and tspkg password entries, then we essentially have mitigated most of the risk.
Windows Authentication FAQ:
Q: Does Windows store credential information in memory?
A: Yes, Windows stores multiple copies of credential information in the LSASS (Local Security Authority Subsystem Service) portion of memory for each authentication protocol used on the system. In a typical XP system there are authentication protocols for wdigest (older IE6 based), tspkg (Terminal Services), and Kerberos (normal Windows authentication) services. In all there could be up to 5 copies of windows credentials for each user logged into a system stored in LSASS.
Q: Does Windows Encrypt Passwords in Memory?
A: Yes. All Windows credentials stored in LSASS are encrypted – but in a “reversible” way.
In “Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques" from Microsoft (attached), on page 34.
"Note: Windows operating systems never store any plaintext credentials in memory or on disk, only reversibly encrypted credentials. When later access to the plaintext forms of the credentials are required, Windows stores the passwords in encrypted form that can only be decrypted by the operating system to provide access in authorized circumstances.”
So, technically it is encrypted, but it is the decryption process, which is embedded in the OS that allows mimikatz and other credential harvesting tools to work. This feature cannot be disabled or isolated in XP (it is how the operating system works) and the best approach I’ve found so far is to limit the debug mode of the local users (including Administrator and SYSTEM) and domain users and removing support for the other, less commonly needed, credential handling protocols; wdigest and tspkg.
Q: How do tools like Mimikatz and Windows Credential Editor extract “cleartext” passwords from systems?
A: By taking advantage of a flaw in Microsoft OS that allows the automatic decryption of passwords in memory.
Specifically, when tools like Mimikatz and Windows Credential Editor (WCE) are used to extract “cleartext” passwords from a Windows operating system they do it by establishing a session in LSASS (the area where authentication is brokered and credentials are stored in Windows) and:
- Query the LSASS process for active (or recorded since last reboot) logon sessions in the memory. The commands used for this is lsasrv!LogonSessionList & lsasrv!LogonSessionListCount, included in the query results are the LUID's (locally unique identifier) generated by the Operating system to represent the various forms of authentication and users logged into the system.
- The output information is searched and the various authentication protocols (wdigest, kerberos, tspkg, etc.) are parsed out.
- The output of that search is queried for User identifiers, tokens, and “reversably encrypted” password values.
- The tools use a Windows LSASS command called LsaUnprotectMemory, which automatically calls a windows LSASS function called LsaEncryptMemory, which has access to the symmetric encryption keys (also stored in memory), to automatically decrypt the data that the tool gathered.
- The result is “cleartext” passwords.
The encryption used for each authentication protocol vary, but in Windows XP they are going to be based a combination of RC4 and DESx. In newer Windows operating systems 3DES and AES are utilized. This is a minor point because in un-patched and unsupported versions of Windows (as is Windows XP), there is no separate subsystems where authentication and decryption occurs, the keys are kept in the same memory as the encrypted files. It’s like sending a .zip file along with the password.
Q: Are Token Authenticators more secure?
A: For the most part. Although token values and PIN codes are stored in LSASS, they have a much shorter time to live as they change constantly and the credential will only be valid as long as the login session remains logged in. PIN Codes are exposed, which means physical security of the token devices is critical.
Q: How about certificate based authentication?
A: Not as secure as tokens. Although the same vulnerability exists for SmartCards, it is not a password that is stored but and NT Hash value of the certificate that is stored (along with the plaintext PIN), from the article:
"If the user logs on to Windows using a smartcard, LSA will not store a plaintext password, but it will store the corresponding NT hash value for the account and the plaintext PIN for the smartcard. If the account attribute for smartcard required for interactive logon is enabled, a random NT hash value is automatically generated for the account instead of the original password hash. This password hash that is automatically generated when the attribute is set does not change.”
In “Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques" from Microsoft (attached), on page 75.
"Will using smartcard logons mitigate the risk of the problem?
No, not significantly. While smartcard logons can enhance security to mitigate credential theft by removing the need for a user to know their account password, underlying password hashes and Kerberos tickets can still be stolen and re-used for network connections”
To mitigate this threat, the toggling off and on of the “Smartcard Required” user attribute changes the NT hash value.
No comments:
Post a Comment