On April 19th 2022, Neil Madden disclosed a vulnerability in Oracle Java 15 through 18, and OpenJDK 15, 17, and 18. The vulnerability lies in the cryptography for ECDSA signatures, which allows an attacker to bypass signature checks entirely for these signatures. 

It’s easy to see headlines about this vulnerability and skim right past them given the obscure nature of ECDSA signatures. However, ECDSA signatures actually play a key role in protecting systems across the internet for critical tasks like authentication.

Before we dive into details, if you want to experience how hackers exploit Psychic Signatures in a hands-on way. Jump straight into our free lab - Missions to try it out yourself.

What’s the big deal with ECDSA?

You may not have heard of ECDSA before. It’s the short name for Elliptic Curve Digital Signature Algorithm, which is a type of cryptography that makes use of the mathematical properties of elliptic curves, offering some of the strongest cryptographic security in the industry at the moment.

This means that it’s used for a lot of important functions, like:

• The signing of SSL certificates
• Handshakes during encrypted communications
• SAML
• JWT signatures
• OpenID Connect signatures

This means that ECDSA is a key part of many of the most sensitive functions for protecting systems out there. The ability to bypass signature checks would be potentially quite devastating.

How is the vulnerability exploited?

The mathematics of ECDSA is somewhat complicated, unfortunately. But the key thing to know is that an ECDSA signature contains 2 pieces of information: r, and s. 

These numbers are used to calculate the validity of the signature. The value r is the “result” (left side) of a calculation using both r and s on the right side of the equation. Given that multiplying by 0 is a bad idea, the ECDSA specification explicitly calls out that if the value of r or s is ever 0, they should be discarded. 

But the Java implementation of ECDSA forgot to take this into account. As such, it will accept a signature with both r and s is 0, which will always be true. We can demonstrate this with an example of a JWT, showing just how easy it is. Using https://token.dev/, we can generate a token with the algorithm ES256, similar to one that would be generated  by an application:

Recall that a JWT is split up into 3 parts:

• Header (in blue)
• Payload (in green)
• Signature (in red)

Now, if we wanted to bypass the signature check, how would we go about this? The signature specifies the values for r and s, and is encoded in the DER format. 

Let’s change our JWT to use this new signature. Note that in JWTs, the equal sign is not included.

Now, our signature has r and s set to 0, and in vulnerable versions of Java the signature check will now succeed for any payload you specify. 

Who’s affected, and how to mitigate it?

The vulnerability affects both Oracle Java and OpenJDK. These include:

Oracle Java SE (And older, non-supported versions): 

• 18

• 17.0.2

Oracle GraalVM Enterprise Edition: 

• 22.0.0.2
• 21.3.1

OpenJDK:

• 18
• 17.0.2
• 15.0.6
• 13.0.10
• 11.0.14
• 8u322
• 7u331

Both Oracle and OpenJDK have put out advisories, and patches for the issue that can be applied right away. 

Hands-on practices to defend against this vulnerability

Here at Secure Code Warrior, we strive to provide developers the most relevant information and hands-on exercises for critical vulnerabilities, whether it is a latest one like Psychic Signatures or something that’s been around for years.

We believe that, to truly keep risk at bay, it is necessary to enable developers to understand the defense mechanism and write secure code from the start. That’s why we create a step-by-step walkthrough of this vulnerability (and many others) for you and the teams that are impacted. 

In the walkthrough, you will be able to follow the instruction to exploit the Physic Signature in JWTs and see the impact to a functioning app in real-time.

Try it out now.

‍