If you don't love me now: JsonWebToken breaks the software supply chain (again)

The JsonWebToken library has a serious flaw, which could lead to remote code execution (RCE). That’s potentially a huge problem, because it’s used all over the place.

Yes, here’s another example of the risks in uncontrolled software supply chains. This npm library is relied upon by countless apps and services — perhaps yours.

The bug’s been fixed, after the vulnerability was disclosed responsibly. In this week’s Secure Software Blogwatch, we worry for people who don’t update.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: MCU Who.
 

JWT type confusion

What’s the craic? Bill Toulas reports — “Auth0 fixes RCE flaw in JsonWebToken library used by 22,000 projects”:

“Massive supply chain repercussions”
Auth0 fixed a remote code execution vulnerability in the immensely popular 'JsonWebToken' open-source library used by over 22,000 projects … downloaded over 36 million times per month on NPM [and] used in open source projects created by Microsoft, Twilio, Salesforce, Intuit, Box, IBM, Docusign, Slack, SAP, and many more. The vulnerability is tracked as CVE-2022-23529.
…
The JsonWebToken project is an open-source library used to create, sign, and verify JSON Web tokens. [It] is developed and maintained by Okta Auth0 and has over 9 million weekly downloads on the NPM package repository and over 22,000 projects on the library, reflecting its massive adoption.
…
This vulnerability is categorized as high severity. … Due to JsonWebToken being such a broadly used open-source library, the flaw has massive supply chain repercussions, and it will continue to have for an extended period until most projects have upgraded.

And swim away from the Nathan Eddy currents — “JsonWebToken Security Bug Opens Servers to RCE ”:

“Discover vulnerable components”
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). … 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.
…
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. … Increasingly, tools have been launched to help defense, identity and access management, and security operations center teams discover vulnerable components.

Horse’s mouth? Artur Oleyarsh — “Disclosing a New Vulnerability in JWT Secret Poisoning”:

“Commonly used as the backbone of many services”
JWTs are used to transmit different types of information, but are mainly used to deliver “claims,” which are pieces of information about some subject. … The most common use case of JWTs is for authorization and authentication.
…
An authentication server will validate the information sent within a request and issue a JWT signed with a secret key. [The] server will validate the information sent within a request and issue a JWT signed with a secret key. … Before the user receives access to a requested resource, the JWT … will be verified using the secret key. [But] an attacker who can control the secret key will be able to execute code on a host verifying JWT.
…
A poisoned secret key could lead to RCE. In reality, keeping and maintaining secret keys involves best practices such as using secret managers and secret key rotations, as well as encryption, etc. … Due to the complexity of this vulnerability, we suggested a CVSS score of 7.6 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L.
…
Open source projects are commonly used as the backbone of many services and platforms today. … Security awareness is crucial when using open source software. Reviewing commonly used security open source implementations is necessary for maintaining their dependability, and it's something the open source community can take part in.

Not worried because you don’t use that library? Here’s HayoS:

Consider transitive dependencies. You should also take a look at which npm packages use this as a dependency.

Déjà vu? tetha categorizes and classifies:

It's pretty much yet another one on the pile of object deserialization vulnerabilities.

How so? julienwoll advises thuswise:

If a malicious actor has the ability to modify the key retrieval parameter (referring to the secretOrPublicKey argument) … of the jwt.verify() function, they can gain remote code execution. … You are affected only if you allow untrusted entities to modify the key retrieval parameter … on a host that you control.

Wait. Pause. How can that possibly happen? u/castleinthesky86 scoffs in a slightly sweary style:

Two cents: If an attacker has compromised your secrets delivery process you’re already ****ed. and thats my technical analysis.

But reality’s a bit more nuanced. As kkeane explains:

Attackers sometimes chain several individual exploits together. So if another exploit manages to get into the system, then the attacker can use this vulnerability.

This vulnerability would then allow an attacker, for example, to pretend to be the user "Hans Mueller" and then access databases outside of the compromised system.

JWT? JSON? ELI45, please. Paul Ducklin explains it to your CTO:

JWT is short for JSON Web Token. … JSON itself is short for JavaScript Object Notation.

JSON is a modernish way of representing structured data; its format is a bit like XML … but without all the opening-and-closing angle brackets to get in the way of legibility. … Whether the JSON really is easier to read than the XML is an open question, but the big idea of JSON is that because the data is encoded as legal JavaScript source, albeit without any directly or indirectly executable code in it, you can parse and process it using your existing JavaScript engine.
…
And one popular use of JSON is the JWT system. … JWT is a blob of encoded data that is used by many cloud servers as a service access token: … A blob of base64-encoded (actually, URL64-encoded) data that includes three fields: Which crytographic algorithm was used in constructing the JWT; what sort of access the JWT grants, and for how long; a keyed cryptographic hash of the first two fields, using a secret key known only to your service provider.

Meanwhile, u/OuiOuiKiwi neatly sums up the insecure supply chain issue:

If you allow untrusted entities to modify your code, you have way bigger issues.

And Finally:

If Marvel made a Doctor Who movie

Hat tip: Ambegris

Previously in And finally

You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or ssbw@richi.uk. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.

Image sauce: JJ Ying (via Unsplash; leveled and cropped)