CVE-2022-23529: Should You Be Concerned About the JsonWebToken Vulnerability?
On January 9, 2023, Palo Alto revealed that their researchers have discovered a vulnerability in the popular JsonWebToken open source project.
Although the JsonWebToken vulnerability received a CVSS score of 9.8, upon closer examination it appears that the chances for the preconditions required to exploit the vulnerability in real world applications are slim.
In this blog post we will provide some background regarding the vulnerability and explain the conditions in which it can be exploited.
As mentioned in the Palo Alto post, CVE-2022-23529 can lead to Remote Code Execution (RCE) when a server verifies a maliciously crafted JSON web token (JWT) request from version 8.5.1 up to (excluded) 9.0.0.
JSON Web Token is a compact and self-contained way for securely transmitting information as a JSON object and its uses can be authorization or information exchange through parties.
The compact size of the JSON object makes it possible to be transferred in URLs, POST parameters, or inside an HTTP header.
The JSON object created is referred to as a token and serves as a way of trust between two different parties.
It consists of three parts separated by dots:
The JWT’s payload contains, among other things, useful information about the user and its permissions. In authorization, the JWT will be included in any request between a server and application or a client after the login in order to identify which access routes/services/resources it is permitted to access via its token.
How does JWT authentication work?
After a user is logged in using a username or password and the server validates the credentials, it will create a signed JWT with a secret key and will probably store it in a different location.
Then every request the user will perform will be accompanied by the JWT which the server will need to verify using the secret key that it stored.
In order to exploit the vulnerability there are a few conditions that need to be met:
- The server does not store secret keys securely.
- The attacker needs to have access to and control the secret keys.
As you can see, these requirements deem the application as insecure in a way that allows an attacker to exploit it regardless of the vulnerability.
In case the attacker has the right prerequisites, it can create a malicious token that can potentially execute code on the server.
When the server verifies the secret key, it uses the verify() method that takes the requested token as input and verifies whether it is correct.
The verify() method receives three parameters: token, secretOrPublicKey, and options when
in the verify.js code we can see that if the algorithm in the option parameter is empty, then values from the secretOrPublicKey parameter will be assigned instead.
Palo Alto has demonstrated an exploit in which they craft a malicious JWT object that uses the toString() method to execute code.
The toString() java method is used to return a string representing an object when represented. When the object is not represented, the user implementation will be invoked.
Should you be worried?
There is no doubt the affected package is indeed popular with over 10 million weekly downloads and over 20 thousand dependents.
That said, the prerequisite conditions are unlikely to be met because the secret keys will not be easily accessible and controlled by attackers. If they are able to do so, they would be able to create their own key and would not need to exploit this vulnerability.
The general consensus around the security community is that the severity of the vulnerability is highly exaggerated and that exploitation in the wild is unlikely.
An argument made by quite a few security researchers is that if CVE-2022-23529 is a vulnerability it means that there are a lot of other packages that are vulnerable in the same way.
However, there is a (very low) chance that this can be relevant when combining the vulnerability with another vulnerability.
Bottom line, while there is no cause for alarm around this specific vulnerability, you should definitely patch it as a practice of good security hygiene.