Weak Hash vulnerability discovered in crypto-js and crypto-es (CVE-2023-46233 & CVE-2023-46133)

On October 18, security researcher Zemnmez began the process of responsibly disclosing a "Use of Weak Hash" vulnerability that they found in crypto-js, an open source JavaScript library of crypto standards, for which maintenance has been discontinued. The vulnerability also impacts the crypto-es package (for ES6 and TypeScript), and the researcher has opened a similar issue requesting that the maintainers enable private disclosures. Both the crypto-js and crypto-es repositories have enabled the "security advisories" and "private vulnerability reporting" features that Zemnmez requested. We have since learned that the vulnerability impacts all previous versions of the libraries. There are no indications that the vulnerabilities impact the core Node.js crypto libraries. 

Quick links

• Understanding the vulnerabilities

• Preparing for the fix(es)

• Finding vulnerable projects

• Prioritizing fixes

• Fixing vulnerable projects

• Next steps

Explaining the crypto-js and crypto-es vulnerabilities

Snyk has created two advisories for the vulnerability:

• SNYK-JS-CRYPTOJS-6028119 for crypto-js (CVE-2023-46233)

• SNYK-JS-CRYPTOES-6032390 for crypto-es (CVE-2023-46133)

New versions of the crypto-es (2.1.0), and crypto-js (4.2.0) libraries have been released to address the security vulnerability flagged by Zemnmez. The crypto-es commit indicates that it was a change to "default params to enhance security." While there is also a fix for the crypto-js library, it's important to remember that, while the library is not flagged as deprecated, it is not normally updated and you should consider alternative options (see below for more on this).

The related advisories share similar descriptions of the issue:

"Affected versions of this package are vulnerable to "Use of Weak Hash" due to inadequate security settings in the PBKDF2 (Algo) class, which uses insecure SHA1 and has a low iteration count of 1. These insecure settings allow attackers to perform brute-force attacks when PBKDF2 (Algo) is used with the default parameters (with the crypto-js advisory reiterating the fact that the library is no longer maintained.)"

The fixes changed the default value for the iterations parameter from 1 to 250000. The greatest risk for this vulnerability is to expose data that has been hashed using this functionality (such as stored passwords) to brute force attacks. In the case of pbkdf2,  the standard use cases would be stored passwords and stored signatures (for example, file verification). In cases where pbkdf2 is used for signature validation, it may also be possible (yet potentially expensive) to perform a chosen plain-text attack which results in an identical cryptographic signature. So the attacker can craft an input that essentially passes the cryptographic validation.

How to prepare for remediation

Gauge your exposure

You can use Snyk to quickly find the open source projects and container images that are impacted, even before the fixed versions of crypto-js and crypto-es were released. 

Navigate to the Dependencies in the Snyk App UI sidebar. Once you're in the Dependencies view, expand the Dependencies filter, and type in "crypto-js". You can select individual versions, or tick the Select all shortcut, then click outside of the filter to see the results, then repeat the process for "crypto-es". This will show you all of the projects that you have that have the crypto-es versions you selected. You can further browse the projects and dependencies to gauge your exposure, and to prioritize what you should fix first. 

I've got 33 projects that use crypto-js@3.3.0, one of which is a Docker image

Use Snyk Advisor to gauge the health of your packages 

Snyk Advisor can help you find the best package for your next project. A quick search for crypto-js shows that while the crypto library has an active community, maintenance is inactive, and mentions similar packages (note that this screenshot was taken before disclosure/assignment of the vulnerabilities, and because the developer published a new version, the maintenance level is currently detected as sustainable). 

Follow enhancements to the primary project or ecosystem

The previous maintainers of the discontinued crypto-js library attribute the deprecation, in part, to the fact that, "further development of CryptoJS would result in it only being a wrapper of native Crypto." Keeping track of the health score for the libraries you use can help you proactively avoid vulnerabilities, but it's also important to keep yourself abreast of enhancements to the ecosystem itself. For some teams, the best course of action for a situation like this is to see if native functionality in the ecosystem can replace third-party libraries.

Detecting the vulnerabilities with Snyk

There are various ways to detect the crypto-js and crypto-es vulnerabilities using Snyk. Using the Snyk CLI, you can test your projects locally, you can import your projects into Snyk using our SCM integrations, or you can use Snyk reports to quickly run a search for crypto-js and crypto-es across all the projects that you have already imported into Snyk. 

Testing your projects using the Snyk CLI

Snyk Container and Snyk Open Source can alert you to operating system packages or open source libraries that depend on vulnerable versions of crypto-js or crypto-es by using snyk container test and snyk test, respectively.  Snyk can monitor your container images and open source projects so you are notified when new vulnerabilities, such as these with crypto-js or crypto-es arise, but registering them via snyk container monitor (for container images) or snyk monitor (for usage of open source libraries).

The following example shows the Snyk CLI being used to scan a Node.js project, which, in this case, indicates that my project uses crypto-js version 4.0.0, and that I should update to 4.2.0.

$ > snyk test
Testing /Users/jamie/Projects/GitRepo/gatsby-demo...
Tested 1367 dependencies for known issues, found 29 issues, 1008 vulnerable paths.
Issues to fix by upgrading:
  Upgrade crypto-js@4.0.0 to crypto-js@4.2.0 to fix
  ✗ Use of Weak Hash (new) [High Severity][https://security.snyk.io/vuln/SNYK-JS-CRYPTOJS-6028119] in crypto-js@4.0.0
    introduced by crypto-js@4.0.0

Testing your projects using SCM integration

Importing your project into Snyk using our supported SCM integrations (GitHub, Bitbucket, GitLab, Azure Repos) will automatically trigger a test, which will enable you to use the Snyk UI to identify, prioritize, and fix the crypto-js and crypto-es vulnerabilities in your projects. 

Use Snyk Reporting or Snyk Insights to detect the vulnerabilities across your projects

Snyk customers with access to Snyk’s reporting (Enterprise plan) and Snyk Insights can quickly identify crypto-js or crypto-es in the projects they have already imported and are monitoring with Snyk. Both flavors of the crypto- vulnerability share a CWE. On the Insights page, filter on that shared CWE, CWE-328, as shown below.

If you do find the issue, you’ll be able to see exactly where it’s being used. You can then click on the project itself to find more information about the issue and fix instructions.

Prioritizing fixes using Snyk's Risk Score 

You're likely to identify multiple  crypto-js or crypto-es issues in your projects, which can cause confusion as to where to focus your fix efforts first. Snyk offers several mechanisms to assist with the prioritization process, but we recommend using our Risk Score.

Snyk’s Risk Score calculates many risk factors to help you quickly identify issues that should be addressed first. The score calculates a number of signals, such as EPSS, exploit maturity, CVSS, social trends, and more, and can then be used to quickly sift through the list of vulnerabilities and prioritize fixes accordingly. In the case of  crypto-js and crypto-es, the score will vary, based on context. 

The score is displayed for each  crypto-js and crypto-es issue on the Projects page and is also available within Snyk’s reporting.

How to fix the crypto- vulnerabilities in open source or container base images

Update your base image to a newer tag with a fixed vulnerability. Fix pull requests with the required fix can be triggered directly from within Snyk for supported ecosystems.

For example, Snyk will recommend alternative container base images via the UI or the CLI, and when you import your source code repository via an SCM such as GitHub, it enables you to automate the container image fix by raising a pull request that updates the Dockerfile FROM entry. 

It may also be possible to avoid the impact of the vulnerability by specifying the iterations parameter in your usage of PBKDF2, but it's equally important to verify that you aren't specifying a low value for  iterations as well:

{ 
    keySize: 256/32, 
    iterations: 1 
}

...as this would mimic the previous vulnerability.

Next steps in responding to the crypto-js and crypto-es vulnerabilities

1. Test your projects with Snyk using the methods outlined in this article. To get started, sign up for a free Snyk account, then import and scan all potentially impacted projects using the import wizard.

2. Identify the highest priority fixes for the crypto-js and crypto-es vulnerabilities using priority scoring or Insights (for customers on the Snyk Enterprise plan).

3. Apply fixes by updating your open source project dependencies or container images to crypto-js to 4.2.0 or greater, and crypto-es to 2.1.0 or later.

4. Continue to monitor this situation as it unfolds, and check back on the Snyk Blog for any developments as they occur. Snyk’s Security teams will update our resources regularly with the latest updates.

5. If you're using the no-longer-maintained  crypto-js, consider either moving to crypto-es or leveraging the built-in functions instead.