JWT header injection vulnerability

• Privilege Escalation by JWK header injection (RS256 or asymmetric hashing algorithm attack)
  JWK is a JSON web key. JWK is an optional key:value pair in a header of the JWT token. This JWK header is used by the server to embed the public key within a token itself in JWK format.
  Example:

Check if the JWK parameter is allowed in the header by the server. Also, check if the server is misconfigured that uses the key that’s embedded in the JWK parameter. If both the condition is accepted by the server then we can use our own key and send that key by using the JWK parameter and the server use that key for signature verification.

Exploitation Steps:
1. Capture the JWT request with the RS256 algorithm.
2. Send the request to the repeater
3. Navigate to “JWT EditorKeys” Burp extender

4. Click on “New RSA Key” → Click on Generate to automatically generate the new key pair (Note that you don’t need to select a key size as this will automatically be updated later.) → Click on “Ok”
5. Navigate back to the repeater request, and change the values whatever you want according to the request. Like in the below screenshot I have changed the “Sub” from “Wiener” to “administrator” for the administrative privileges.
6. Navigate to the “JSON web Token” extender in Burp → Click on “Attack” → Select “Embedded JWK”.
7. Send the request and you will get a successful response if JWK is allowed by the server and it is misconfigured.

Here in this scenario, when we choose “Embedded JWK”, our JWT token is automatically signed by the private key that we have created and the public key is embedded in the JWK parameter, which is used by the server for the decryption and for the digital signature verification.

Why we can’t use HS256 (Symmetric hashing) in JWK?
Might be some of you think the same as I was thinking when I am writing this blog. So JWK header has some structure defined and this header is used for sending the public key in that format, but in HS256 as its symmetric hashing algorithm, it uses the random secret key to generate the hash and the same key is at the server which is used at the server end to generate the hash and then both hashes compared. If both hashes are the same, then there is no tampering in the request. HS256 or symmetric hashing algorithm doesn’t follow that same format that is used for asymmetric hashing algorithm.
https://www.rfc-editor.org/rfc/rfc7638.txt

• Privilege Escalation by JKU header injection (RS256 or asymmetric hashing algorithm attack)

What is JKU?
JKU is JSON Web Key Set URL. 

In JWK, we embedded the public key in the request, but in JKU we embedded the URL which contains the set of keys. The server can fetch the set of keys and use the correct key by checking the kid value in the request and in the key set.

JWK Sets like this are sometimes exposed publicly via a standard endpoint, such as /.well-known/jwks.json
Mostly, keys are fetched from secure domains, but sometimes the server is misconfigured and you can use your own domain to fetch the public key and sign the token by your own private key. 
This scenario is the same as JWK only just a header key: value is different, here we use a URL to fetch the public key.

Exploitation Steps:
1. Capture the JWT request with the RS256 algorithm.
2. Send the request to the repeater
3. Navigate to “JWT EditorKeys” Burp extender
4. Click on “New RSA Key” → Click on Generate to automatically generate the new key pair (Note that you don’t need to select a key size as this will automatically be updated later.) → Click on “Ok”
5. Right-click on an entry and then click on “Copy public key JWK”

6. Navigate to the attacker control server, and create the file like this 
{“keys”: [ ]}
7. Paste the copied “Copy public key JWK” inside the bracket.
{“keys”: [

{
 “kty”: “RSA”,
 “e”: “AQAB”,
 “kid”: “d129fd69-c8e8–459f-b904–986dba3ed293”,
 “n”: “v0pisowR-JdQFWIj-AUvIW1i2E06dNPctHZhUjDgUz6kLgr5f_hw4Yd93GmTYXcYjpafv0NJqvDkhZ0GUy4iSmDEoLC211Z9f9vKQtfnQU-0QEd1zZcpAstU3RevUI23q_aukcMewVO2a4NxgNt6j9d-e31M-55kbo-UUNAm0t7XI42IBPaiCCjLOqSzMS0ly9bcLCJUJyELv_SrqKqkRZI3T_KtZUkBEZUsQv3i5iSRLbZt5gYA_0UccffAsRJhk4iBx7PB60fuxcFi1Uje-O2oiS0j69Aq5xzCbAqPkDLMfOv21R7xSCU_BzajtuBcGSfgbIjeEH9elxnt1hDGgQ”
}
]
}
8. Navigate back to the repeater request, and change the values, whatever you want according to the request. Like in the below screenshot I have changed the “Sub” from “Wiener” to “administrator” for the administrative privileges.
9. Replace the “kid” value in the request with the kid value of “Copy public key JWK”. It is an important step because by using the kid value server to identify which public key the server has to use from a set of keys or if only one key.
10. Add a new “jku” parameter in the header and set the value to the URL of the attacker control server where the JWK keys are hosted. Check steps 6,7
11. Click on “Sign” in the “JSON Web Token” extender in the Burp. It is also an important step. Now you are signing your modified request with your own private key.
12. Send the request and you will get a successful response if JKU is allowed by the server and it is misconfigured.

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