* Scenario: Attacker is able to create alg=None tokens for other users and changes victim user's password. For doing this, attacker uses his/her own token and modifies it to match victim's. Attacker has to only know or guess (enumerate) victim user identifiers.
* You can check and use your victim user identifier from above
* Task: Change victim user's password with an alg=None JWT token
* For short explanation what alg=None means, check https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/#Meet-the--None--Algorithm
* Note: Wasdat implementation is terrible and allows alg=none tokens even if a secret key is configured
* Create or use pre-existing (wasdat-victim@example.com, attacker@example.com) users to Wasdat
* Acquire and decode tokens of attacker and wasdat-victim
* Identify which field holds the user id
* Encode a token with alg=None and use it
* Manipulate the attacker's token so that it matches the victim's
* Tool examples (decoding, encoding):
* built-in `jwt` library in Python 3.x
* jwt.io
* CyberChef
* You can modify the curl command from first assignment (or use something else)
* Scenario: Someone was able to crack Wasdat's weak secret key for signing JWT Tokens. In fact, no cracking was required as it was left as library default value. Nobody at Wasdat responded, so this secret key `"secret-key"` ended up in a Tweet with appropriate tags #wasdat #jwt #yolo.
* Task: Change victim user's password with a forged token that is signed
* Create or use pre-existing (wasdat-victim@example.com, attacker@example.com) users to Wasdat
* Acquire and decode tokens of attacker and wasdat-victim
* Identify which field holds the user id
* Encode a token with matching algorithm
* Manipulate the attacker's token so that it matches the victim's
* Add also field "was: true" to demonstrate you can manipulate payload freely
* Tool examples (decoding, encoding):
* built-in `jwt` library in Python 3.x
* jwt.io
* CyberChef
* You can modify the curl command from first assignment (or use something else)
* Scenario: Wasdat has opened an alpha version of their custom search API endpoint `/api/articles/custom-search` (POST) (see usage example above). Looks like the current version of the API merely displays the search back to user. They plan on having it public while it's in development and once it's ready, they plan selling access to it for marketing companies. Move Fast and Break Things philosophy has backfired, however, as the API is vulnerable to XML External Element.
* Task: Get contents of `/etc/passwd` from Wasdat backend
* Modify example API call to exploit XEE vulnerability and retrieve contents of /etc/passwd of backend
* In your report:
* Include the payload you used
* Include the flag present in `/etc/passwd`
* As usual, refer to "Issue report" from Assignment instructions (don't forget mitigation section!)
* For mitigation tips, check https://owasp.org/www-project-top-ten/2017/A4_2017-XML_External_Entities_(XXE).html
* (same as above) plus addition: it turns out that a company that sells missile guidance systems for refurbished cruise missiles has bought Wasdat and co-located Wasdat's backend systems to their networks. Also, missile-control's HTTP API design isn't perfect, as the missiles can be launched using a GET request (which should not have side effects).
* Task: Launch The Missiles
* Modify example API call to exploit XEE vulnerability and perform call to `http://missile-control:6666/launch-the-missiles`
* Note that `missile-control` only resolves and routes inside the Application network. Don't worry if pinging it doesn't work from your Docker host.
