CVE-2023-46233

What it actually does

The PBKDF2 (Password-Based Key Derivation Function 2) implementation in crypto-js versions prior to 4.2.0 is cryptographically weak. It defaults to using the insecure SHA1 hashing algorithm with only a single iteration. This drastically reduces the computational effort required to reverse-engineer the original input (like a password) from its hash, effectively nullifying the security purpose of the key derivation function.

Why it matters to the business

Using this library for password storage or signing exposes the organization to a high risk of data breaches and unauthorized access. If an attacker obtains the weakly protected password hashes, they can easily and quickly crack them to recover user passwords, leading to mass account takeovers. This can result in theft of sensitive customer or corporate data, financial fraud, and significant reputational damage. Forged digital signatures could lead to transaction repudiation and loss of data integrity.

How an attack unfolds

An attacker first obtains access to data protected by the vulnerable crypto-js implementation, such as a database of user password hashes exfiltrated during a separate breach. The attacker then takes these hashes offline. Using common password cracking tools like Hashcat or John the Ripper, they can launch a brute-force or dictionary attack. Because the hashing function uses only a single round of SHA1, the process is computationally trivial, allowing the attacker to recover the original plaintext passwords for a large number of accounts in a very short time. The attacker then uses these credentials to impersonate users, access sensitive systems, and exfiltrate data.

How to fix it

The primary remediation is to upgrade the crypto-js library to version 4.2.0 or later. If an immediate upgrade is not possible, a workaround is to manually configure the PBKDF2 function to use a secure hashing algorithm and a sufficient number of iterations. Specifically, specify SHA256 and an iteration count of at least 250,000 (OWASP currently recommends 600,000 for PBKDF2-HMAC-SHA256). After upgrading or applying the workaround, all existing password hashes and other derived keys must be re-generated using the secure configuration.

How to confirm the fix worked

Use a Software Composition Analysis (SCA) tool to scan your projects and dependencies for any use of crypto-js versions prior to 4.2.0. Manually inspect code where crypto-js's PBKDF2 is used. If the function call does not explicitly specify `iterations` and `hasher` options, it is vulnerable. A fixed implementation will explicitly set these parameters, for example: `CryptoJS.PBKDF2(password, salt, { keySize: 256/32, iterations: 250000, hasher: CryptoJS.algo.SHA256 })`. After remediation, confirm that the library has been upgraded and that new data is being hashed with the stronger settings.

Typical attack path

1. Attacker gains access to a data store containing hashes generated by the vulnerable library.
2. Attacker exfiltrates the password hashes for offline processing.
3. Attacker uses commodity hardware and standard cracking tools to brute-force the hashes.
4. Due to the single-iteration SHA1 weakness, the attacker rapidly recovers plaintext passwords.
5. Attacker uses the recovered credentials to log into applications, escalate privileges, and steal sensitive information.

How to detect it

Exploitation of this vulnerability occurs offline after an attacker has already stolen the hashed data. Therefore, detection efforts should focus on the initial data theft. Monitor for signs of database compromise or data exfiltration, such as unusual or large queries to tables containing user credentials, unauthorized access to database backups, or large outbound network transfers. A secondary, post-compromise indicator could be a surge of successful logins from a diverse set of accounts, especially those that have been inactive, suggesting the use of cracked credentials.

What your security team should do

• Use Software Composition Analysis (SCA) tools to immediately identify all applications using vulnerable versions of crypto-js (< 4.2.0).
• Prioritize upgrading or patching applications that use this library for authentication, password storage, or data signing.
• For any systems found to be vulnerable, initiate a plan to re-hash all stored passwords and invalidate any sessions or keys derived using the weak function.
• Audit codebases to ensure that no cryptographic functions are being used with insecure default parameters.