There are multiple vulnerabilities exist within JSON Web Tokens. This is a quick and easy lab for you to understand the fundamentals of JWTs and how to exploit them.
A JSON Web Token (JWT) is split into three parts; the header, body, signature. This allows small pieces of information to be securely transmitted between parties. The integrity of the information is enforced by the signature. The most common use for JWTs is Authorization and Information Transfer.
Each section of a JSON Web Token is individually Base64Url encoded.
header.body.signature
The most important information in the header is the algorithm used for the signature. The main algorithms that are supported out there are:
The body of the JWT is separated from the header and signature through the use of full stops. This part of the token contains the information that is being sent. Usually it contains the authenticated user and an iat which is used to verify when the token was created. The iat can be used to give the token a period of validity. In the set of challenges, the goal is to modify the body so that the user = admin.
The signature is made from the algorithm listed in the header. This is used to ensure the data has not been tampered with. To create the signature, the algorithm needs to be applied on the following payload:
base64urlencoded(header)+"."+base64urlencoded(body)
If it is possible to modify the body and have a valid signature. It would be possible to escalate privileges to a higher user such as admin.
Try to use the "none" algorithm. This algorithm does not require a signature which means the integrity of the token cannot be checked. Sometimes, the signature isn't even checked!
Try to check if it is possible to use HMAC (HS256) to sign the signature.
If it is possible to change the algorithm to HS256 and the verification key has been exposed, then it should be possible to create a valid signature
If the key is recovered, then it will be possible to create valid signatures. A good tool to use for this is Hashcat.
hashcat -a0 -m 16500 text.hash [dict]
The kid (key identifier) is used to identify which key is used for the token. This value can be vulnerable to file traversal. Thus if you can find a file exposed on the server (for example a css file). That file can be used as the key for the signature. This kind of vulnerability may exist with the other possible headers such as JKU and x5u as they also may be used to determine which key is used.
It is also possible for the kid value to access a database and as a result, SQL Injections may be possible.
This exploit may occur when libraries use vulnerable system calls to read the file.
The challenges I have made are some of the basic vulnerabilities for poor implementation of JWTs. The main goal is for you to have gained some experience so when the real thing comes along in a test or development process. Therefore, you will have a good methology and mindset for ensuring they are secure.
Enjoy my lab and let me know what you think.