When using a playbook scan, I thought it odd that jwt_tool suggests HS attacks when the algorithm is RS (and doesn't suggest RS attacks):
$ python jwt_tool.py -rh 'Authorization: Foo eyJhb...' -t 'https://test-target.willhackforsushi.com/api/v1/capabilities' -M pb
...
Token header values:
[+] alg = "RS256"
...
LAUNCHING SCAN: JWT Attack Playbook
...
The following additional checks should be performed that are better tested manually:
[+] Try testing HS token against weak password configurations by running the following hashcat cracking options:
(Already testing against passwords in jwt-common.txt)
Try using longer dictionaries, custom dictionaries, mangling rules, or brute force attacks.
hashcat (https://hashcat.net/hashcat/) is ideal for this as it is highly optimised for speed. Just add your JWT to a text file, then use the following syntax to give you a good start:
[*] dictionary attacks: hashcat -a 0 -m 16500 jwt.txt passlist.txt
[*] rule-based attack: hashcat -a 0 -m 16500 jwt.txt passlist.txt -r rules/best64.rule
[*] brute-force attack: hashcat -a 3 -m 16500 jwt.txt ?u?l?l?l?l?l?l?l -i --increment-min=6
[+] Try waiting for the token to expire ("exp" value set to: 2022-11-02 07:57:35 (UTC))
Check if still working once expired.
It looks like lines 1514 and 1518 check headDict['alg'] for the algorithm type, but this value is changed somewhere else (also noted at line 1377 where is is saved as origalg).
When using a playbook scan, I thought it odd that jwt_tool suggests HS attacks when the algorithm is RS (and doesn't suggest RS attacks):
It looks like lines 1514 and 1518 check
headDict['alg']for the algorithm type, but this value is changed somewhere else (also noted at line 1377 where is is saved asorigalg).This is a tiny issue, PR incoming.