A high-severity remote code execution vulnerability has been discovered in the JsonWebToken (JWT) open-source encryption project. Tracked as CVE-2022-23529, an attacker can exploit this vulnerability to gain remote code execution on the target server verifying a maliciously crafted JSON web token (JWT) request.
Artur Oleyarsh, Security Researcher at Unit42, has mentioned in his blog, “This vulnerability requires several prerequisites to be exploitable, which makes it less likely for an attacker to use it in the wild.”
JSON Web Token
JsonWebToken is an open-source JavaScript package developed and maintained by Okta’s Auth0. This package enables users to decode, verify, and generate JSON web tokens for authorization and authentication purposes to transmit information securely. It has over 9 million weekly downloads on the npm software registry and is used by more than 22,000 projects.
JWTs are digitally signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.
JSON Web Token structure
JWTs consist of three parts Header, Payload, and Signature, separated by dots (.). JWT looks like this: Header.Payload.Signature
The header consists of two parts:
- The type of token (which is JWT).
- The signing algorithm being used, such as HMAC SHA256 or RSA.
The Payload contains the claims, which are statements about an entity (typically, the user) and additional data. The claims are of three types:
- Registered: A set of claims that are not mandatory but recommended. Example: iss (issuer), exp (expiration time), sub (subject), aud (audience), and others.
- Public: These claims can be defined at will by the JWT users. These claims are described in the IANA JSON Web Token Registry.
- Private: These are custom claims created to share information between parties that agree to use them and are neither registered nor public claims.
The Signature is created using the encoded header, the encoded payload, and the algorithm specified in the header. The signature is used to verify that the message wasn’t changed along the way. In the case of tokens signed with a private key, it can also verify that the sender of the JWT is who it says it is.
Working Process of the JSON Web Tokens
JWT.io site describes the process as follows:
- The application or client requests authorization to the authorization server. This is performed through one of the different authorization flows. For example, a typical OpenID Connect compliant web application will go through the /oauth/authorize endpoint using the authorization code flow.
- The authorization server returns an access token to the application when the authorization is granted.
- The application uses the access token to access a protected resource (like an API).
It is important to note that with signed tokens, all the information contained within the token is exposed to users or other parties, even though they cannot change it. This means you should not put secret information within the token.
Vulnerability Description
The flaw exists in the verify method, which is used to verify the validity of the JWT and return the decoded payload part. The method accepts three parameters: token, secretOrPublicKey, and options.
The values in the Privacy Enhanced Mail (PEM) file, provided by the secretOrPublicKey argument, will be assigned when no allowed algorithms are supplied within the options algorithms list. This is problematic since no proper check is provided to identify whether secretOrPublicKey is a valid PEM file’s content, and this unverified object’s toString() method is being blindly used. Attackers who control this object can provide their own toString() method, which will then be executed by JsonWebToken’s verify function.
When a malicious object is passed to the verify function via the secretOrPublicKey parameter and allowed to override its toString() method. The code will get executed and exit the node process before the .includes(‘BEGIN CERTIFICATE’)check in the verify function, resulting in an arbitrary write file on the hosting machine.
An attacker can use the same technique with a slightly modified payload by using the child_process module will be able to achieve remote code execution on the target system.
Affected versions
JsonWebToken package versions prior to 8.5.1 are affected by this vulnerability.
Mitigation
Customers are recommended to upgrade to the JsonWebToken package version 9.0.0, which can be downloaded from the JsonWebToken download page.
Qualys Detection
Qualys customers can scan their devices with QIDs 377890, 991092, and 990952 to detect vulnerable assets.
The QIDs 991092 and 990952 will be available to customers who subscribe to the SCA (Software Composition Analysis) product. SCA (Software Composition Analysis) is currently available for Container Security.
Please continue to follow Qualys Threat Protection for more coverage of the latest vulnerabilities.
References
https://jwt.io/introduction
https://github.com/auth0/node-jsonwebtoken
https://unit42.paloaltonetworks.com/jsonwebtoken-vulnerability-cve-2022-23529/
https://github.com/auth0/node-jsonwebtoken/security/advisories/GHSA-27h2-hvpr-p74q
