Skip to main content

JWT algorithm confusion exploitation or change the algorithm from RS256 to HS256 exploitation


  • Privilege Escalation by algorithm confusion when server public key is exposed and JWT token algorithm is RS256(Change the algorithm from RS256 or asymmetric hashing algorithm attack to HS256 or symmetric algorithm)

This is not just only an algorithm confusion, it confuses you too. Yes, I am not kidding :) 
Before going to understand the exploitation part, first understand what is RS256 and HS256
RS256 (Asymmetric Algorithm): It uses the private and public keys. The private key is never shared with anyone and this key is used for generating the signature. The server sends the JWT token by adding the signature to it. Public key is used by the JWT token receiver, who used this key to verify the signature. 
HS256 (Symmetric Algorithm): It is a symmetric key hashing algorithm that uses one secret key. The key is used for both generating the signature and validating the signature. The secret key is shared with both parties.

Let's assume a scenario where you received a JWT token that uses an RS256 algorithm. After some recon, you found a server public key let's say you found it in /.well-known/jwks.json . For more details check the above JWK issue.
As per our scenario, we know that the JWT token is using RS256 that’s means the server is generating a signature by the private key and the JWT receiver is using a public key for verification. 
So in the algorithm confusion attack, we use the public key that we found in our recon as a secret in the symmetric algorithm and sign our alter payload with that signature. Also, change the algorithm to HS256 before sending it to the server. So now when we send this modified JWT token to the server, we are telling the server that it is HS256 instead of RS256. If the server is misconfigured for the algorithm confusion, then the server may use the public key as the secret in the symmetric algorithm.
We used the public key as a secret in the symmetric algorithm for encrypting(Signing) the hash of payload and header. The server used the public key for decryption of the digital signature to take out the hash value.
The server also creates the hash of payload and header by using the same algorithm and key and after that server compares both hash values. As the same secret key is used by both attacker and server because of misconfiguration both the hash will match.
Learn about Digital Signature for more clarification.

Exploitation steps:
1. Capture the JWT request with the RS256 algorithm.
2. Send the request to the repeater
3. Let's say you found the public key /.well-known/jwks.json
4. Copy only highlighted part from the public key


5. Navigate to “JWT EditorKeys” Burp extender
6. Click on “New RSA Key” → paste the highlighted part in the key section without clicking on Generate → Click on ok
7. Right-click on the entry and then click on “Copy public key as PEM”
8. Paste the copied key into the decoder and encode it to Base64. Copied the encoded data
9. Now go back to “JWT EditorKeys” → Click on “New Symmetric Key” → Click on Generate → Replace the value of “k” with the value of Base64 encoded PEM that you just created.
10. Navigate back to the repeater request, and change the values whatever you want according to the request. Like in the above screenshot I have changed the “Sub” from “Wiener” to “administrator” for the administrative privileges.
11. Change the alg to HS256 from RS256
12. Click on “sign” in the “JSON web token” Burp extender and sign it with the symmetric key that you have created in the earlier step.
13. Send the request and you will get a successful response if a server is misconfigured to an algorithm confusion attack.

  • Privilege Escalation by algorithm confusion when server public key is not exposed and JWT token algorithm is RS256(Change the algorithm from RS256 or asymmetric hashing algorithm attack to HS256 or symmetric algorithm)

Working on it and will update you soon….


JWT:

https://lazyhacker22.blogspot.com/2022/07/jwt-vulnerabilities-list-simple.html

https://lazyhacker22.blogspot.com/2022/06/what-is-jwt-json-web-tokens-simple.html

Comments

Popular posts from this blog

Free Cybersecurity Certifications

Introduction to Cybersecurity Cybersecurity Essentials Networking Essentials Android Bug Bounty Hunting: Hunt Like a Rat Ethical Hacking Essentials (EHE) Digital Forensics Essentials (DFE) Network Defense Essentials (NDE) Introduction to Dark Web, Anonymity, and Cryptocurrency AWS Skill Builder Introduction to Cybersecurity Building a Cybersecurity Toolkit Cyber Aces Free Cyber Security Training Course Introduction to Information Security Penetration Testing - Discovering Vulnerabilities

Is your webcam exposed on the internet and everyone enjoying your personal moments? | How to check webcam or security camera is exposed on the internet or not?

Nowadays we start using many technology devices in our homes. Many people are installing CCTV or security cameras in their houses, private rooms, offices, private places, etc for security purposes and monitoring, but many of them don't know how to configure that device securely. So let's talk about CCTV and security cameras only.  What do most CCTV/Security camera users believe? Most users believe that using a strong username and password on a camera administrative page protects them. (Partially true in the case of online cameras) Example: Why it is partially true? It's partially true because you are protecting only the camera administrative page which is also an important part. Still, you are not protecting the protocol used to control streaming media servers (Real-Time Streaming Protocol ( RTSP )). I have seen many online webcams whose administrative page is secured by strong credentials, but they forget to secure the RTSP protocol which gives me access to the streaming

Web Application Security Testing (WAPT) Interview Questions

Let's Contribute All Together For Creating a Questions Dump What are the vulnerabilities you have to test in the Login form, Payment gateway? What is clickjacking? What is the mitigation of clickjacking? What is CSRF? How to mitigate CSRF? Let's take an example, If a developer implements a CSRF token in a cookie, will it mitigate the CSRF issue? Is it possible to mitigate the CSRF by header? If yes why, if No why? If the data is in JSON format, how you will check the CSRF issue and what are the ways of exploitation? Where to implement the CSRF token and why? If the client doesn't want to change the UI or doesn't want to implement the CSRF tokens, and headers then what mitigation you recommended to the client for CSRF? What is the problem with the per-request token? Is login CSRF possible? Explain login CSRF? Have you ever exploited it? What is the mitigation for login CSRF? Suppose, in an application csrf token is implemented in each request and every request, except th