Who Knows What Passwords Lurk in the Heart of Windows? The Shadow Knows!
File permissions are tricky things. In many systems, they are not part of the file themselves. This means that permissions sometimes get lost when copying files.
This issue came up recently when Microsoft acknowledged a serious weakness in many versions of its Windows 10 operating system. The weakness, nicknamed SeriousSAM or HiveNightmare, occurs in a Microsoft function that can take snapshots of files, folders, or entire volumes. They call this a shadow copy, and it’s a useful feature for copying and restoring files quickly.
Shadow Copy Weakness
When making these shadow copies, the shadow copy software does not always keep the permission structure correct for a series of parts in the critical portion of the operating system (CWE-281 Improper Preservation of Permissions). One of the impacted areas is the Security Account Manager (SAM).
Normally, the SAM is a protected part of the operating system as it contains hashed passwords and security tokens for all the accounts on the system. When regular users can read this database file, they have access to hashed credentials for accounts with higher levels of permission than the user, like system privileges.
This attack is labeled CAPEC-647: Collect Data from Registries. Adversaries can then either relay these tokens in a Pass the Hash attack (CAPEC-644: Use of Captured Hashes), access restricted volumes (CAPEC-561: Windows Admin Shares with Stolen Credentials), and/or reverse the account password hashes and execute a Kerberos Silver Ticket Attack (CAPEC-645: Use of Captured Tickets).
Recommendations for Addressing the Weakness
Microsoft has put out some recommendations on how to mitigate this vulnerability. According to the CWE crypto team, this issue could be addressed in the long term by thinking about adding crypto agility, the ability to easily upgrade to more modern hashes to record passwords and tokens.
Currently, in Windows, hashes are kept in either the archaic LM hash (which is not a hash) or the current but ineffective NTLM hash (Version 1 is not a hash and Version 2 is a weak hash). These are considered relatively weak as they suffer from CWE-328: Reversible One-Way Hash, or CWE-916: Use of Password Hash with Insufficient Computational Effort depending on the version. They use processes and algorithms such as MD5 and DES, which are no longer effective due to the advancement of computers.
It’s important to consider that when Microsoft makes changes it impacts a significant part of the industry, so these changes cannot be made easily. They need to be balanced against other security controls that Microsoft has been providing instead of hardened credentials. Also, change in large ecosystems takes time. NTLMv2 was introduced in 1998 and some systems still need to use the weaker LM hash for compatibility today. Even if the SeriousSAM- or HiveNightmare-relevant hashes are upgraded today, we might still be using NTLMv2 in 2040.
If possible, consider updating your systems to use more robust password storage algorithms. Many of these resist brute forcing (CAPEC-16: Dictionary-based Password Attack) and the creation of a rainbow table (CAPEC-55: Rainbow Table Password Cracking), such as more modern and NIST-approved hashes for the storage of passwords including [insert example(s)]. Some modern hashes use memory-hard functions to make hashing speedups in custom software harder to accomplish. Here is a useful charts on how long it would take to crack NTLM passwords of different lengths with different character sets.
Going forward, when you or your team are building new systems and applications, it is important to consider using modern hashes for the storage of credentials as well as being mindful of both files and their relevant permissions when copying.
