Psychic Signatures - what you need to know
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.
Psychic Signature vulnerability lies in the crypto for ECDSA signatures, which protects systems for critical tasks like authentication. Hackers can bypass any signature check with this vulnerability. We will explain what it is and how to mitigate it in this post.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoOn 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.
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.
Click on the link below and download the PDF of this one pager.
DownloadSecure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoOn 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.
Table of contents
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.