Skip to main content

Posts

Showing posts with the label JWT

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

JWT kid header exploitation

  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

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 bac

JWT token exploitation by Bruteforce weak signing key

Bruteforce weak signing key Try to  brute force  a weak signing key. If you get the secret key that is used for creating the signature, then you can modify data and use that key to create a new signature. In this scenario, the server is validating the signature, but the server is using the weak key for creating the signature. I know some of you might be confused about this. Check this  blog  to understand the  digital signature . Check the above image, if you know the secret you can create your own signature, and that same secret is used for validating the signature at the server end. This is how it works. For brute force, you can sue any signature dictionary.  https://raw.githubusercontent.com/wallarm/jwt-secrets/master/jwt.secrets.list Copy the JWT token and paste it into the below command and give the path to the dictionary. Bruteforcing: hashcat -a 0 -m 16500 <YOUR-JWT> /path/to/jwt.secrets.list or python3 jwt_tool.py <JWT Token> -C -d jwt.secrets.list Let’s say after u

JWT token exploitation by none algorithm

Modify the algorithm to none Change the  “alg”: “none”  and also delete the signature part but remember to leave the trailing dot after the payload and send the request to see if the none algorithm is working or not. Example:  eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0.eyJpc3MiOiJwb3J0c3dpZ2dlciIsInN1YiI6ImFkbWluaXN0cmF0b3IiLCJleHAiOjE2NTY0MTczNDJ9. Header:   eyJ0eXAiOiJKV1QiLCJhbGciOiJub25lIn0 {  “typ”: “JWT”,  “alg”: “none” } Payload:  eyJpc3MiOiJwb3J0c3dpZ2dlciIsInN1YiI6ImFkbWluaXN0cmF0b3IiLCJleHAiOjE2NTY0MTczNDJ9 {  “iss”: “portswigger”,  “sub”: “administrator”,  “exp”: 1656417342 } References: https://portswigger.net/web-security/jwt https://jwt.io/  

JWT Vulnerabilities List (Simple Explanation)

  JWT vulnerabilities: Tamper without modifying anything Modify the algorithm to none Bruteforce weak signing key Privilege Escalation by JWK header injection (RS256 or asymmetric hashing algorithm attack) Privilege Escalation by JKU header injection (RS256 or asymmetric hashing algorithm attack) The exploitation of kid header in JWT (Directory Traversal and command Injection) (RS256 and HS256) 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) 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) Cross service relay attack Check exp Tamper without modifying anything Change the value in the payload and check if the signature is validating at the server end or no

What is JWT - JSON Web Tokens (Simple Explanation)

What is JWT? JWT token is a base64url encoded string that is used to transmit the information between server and client. JWT token mostly contains the user information which is used for authorization. JWT token can be sent through a URL, POST parameter, and HTTP header. The information that is sent by JWT is verified and trusted because it is digitally signed .  JWT token looks like: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 . eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ . SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c JWT token has three parts: https://jwt.io/ Header: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 {“alg”: “HS256”,”typ”: “JWT”} Payload: eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ {“sub”: “1234567890”,”name”: “John Doe”,”iat”: 1516239022} Signature: SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c HMACSHA256(base64UrlEncode(header) + “.” +base64UrlEncode(payload), your-secret) Uses of JWT token * Authorization: After successful auth