A high-severity vulnerability (CVE-2022-23529) has been discovered in the popular JsonWebToken (JWT) open source encryption project, which could be used by attackers to achieve remote code execution (RCE) on a target encryption server.
The JWT open standard defines a method of transferring information securely by encoding and signing JSON data. According to researchers at Palo Alto Networks’ Unit 42, an exploit for the vulnerability results in the server verifying a maliciously crafted JSON web token request.
“Running malicious code on a server can lead to a huge damage and loss of confidentiality, integrity, and also may cause a denial of service,” cautions Unit 42 security researcher Artur Oleyarsh. “Systems related to and communicating with the vulnerable server may suffer as well, so the attack potential and the consequences once the system is vulnerable for a remote code execution is significant.”
The issue poses a threat to all who are using JWT versions prior and including v8.5.1. The patched version of the package is v9.0.0, according to a Jan. 9 posting from Unit 42.
Oleyarsh explains that usually, vulnerabilities related to JSON Web tokens are related to different token forging techniques that allow a malicious actor to bypass authentication and authorization mechanisms.
“This gives them [the] opportunity to take over accounts, impersonate users, and elevate privileges,” he says. However, “this latest vulnerability is unique for several reasons. First, here we are talking about executing code on a host verifying JSON web tokens.”
Underneath the Hood of CVE-2022-23529
Rather than bypassing authentication or authorization mechanisms, the bug provides a way for a cyberattacker to gain control over a key retrieval parameter of the “jwt.verify” function (known as secretOrPublicKey).
In a proof-of-concept exploit, Unit 42 was able to override the “toString()” method of the key object.
“In JavaScript, every object that inherits from Object.prototype, inherit the toString() method,” Oleyarsh says. “Thus, if there is a blindly trusted call to that method, and we control the key object, we can override its toString() with malicious content and execute arbitrary code.”
Open Source Usage Grows, Along With Cyberthreat Level
As the use of open source software (OSS) continues to grow, so does cyberattacker interest in using software components and packages like JWT as an attack vector.
“We are seeing threat actors actively scanning for known vulnerabilities and exploiting them within minutes,” Oleyarsh says. “Without attention and awareness to OSS security, I think we will see more and more attacks leveraging OSS security issues.”
He says as a community, security practitioners need to contribute and cooperate to make OSS software safer.
“Some of the developers and maintainers of OSS are building solutions with security in mind, which means that they are constantly fixing security vulnerabilities, scanning for vulnerable dependencies, and maintaining security advisories and publishing them so the users can patch for the non-vulnerable versions, and some of them are not,” Oleyarsh notes.
Increasingly, tools have been launched to help defense, identity and access management, and security operations center teams discover vulnerable components. Google’s OSV-Scanner, which launched in December, for instance generates a list of dependencies in a software development project and checks the OSV database for known vulnerabilities.
“Some are doing a great job in creating wonderful and creative solutions for many problems and making it available for use to anyone without charge,” Oleyarsh says. “If you are implementing OSS within your organization, it is a good practice to use OSS package scanners to scan for vulnerable versions of OSS packages you are using, as well for vulnerable dependencies.”
Meanwhile Google is also throwing its considerable weight behind a proposed US government-led policy framework aimed at shoring up security for open source software, urging the private sector to support the initiative.
From a manual perspective, Oleyarsh adds that teams should take a regular look at the security advisories pages of the OSS projects they use to keep up to date on bugs, and look at implementing software composition analysis (SCA) tools to help to track all the open source packages and modules used by a project in order to inform that process.
Then, “when you encounter a bug which has security implications, it is a good practice to reach out to the maintainers via a private chat and report the issue and even suggest and discuss the solution,” he says.
