Exploitation: Practical Application

Welcome back to Using Components with Known Vulnerabilities session. In this second part, we’ll exploit a known vulnerability in our target application. We will jump straight to our intentionally vulnerable application and then move on to the mitigation part.

We can now retrieve our JSON Web Token from browser’s cookies or local storage.

Next, we will decode our JSON web token.

JSON web tokens have three sections, all of them base64 encoded and split by a dot. The first section is called header, and it includes information about token type and the algorithm used to compute token signature.

The second section is called payload, and it holds the actual data or claims.

The third and last section is the signature.

Tokens can be signed by the server using a key so the server is able to verify that the token is legitimate when it is sent back by the client in subsequent requests. The signature is calculated by base64 URL encoding the header and payload, concatenating them with a period as a separator, and passing the resulting value to an algorithm, such as the SHA-256 with a secret. The name of the algorithm used to compute the signature is what goes into the JSON web token headen so that the same algorithm can be used to verify a token’s authenticity. This was a quick overview of JSON web tokens.

But you’re better reading more about this since JSON web tokens are very popular and its use widespread.

So now let’s talk about the JWT common library’s vulnerability we will try to exploit. JWT libraries have to implement at least two mandatory signing algorithms, none and HFS 256. The none algorithm is a curious addition to JWT. It is intended to be used for situations where the integrity of the token has already been verified. Some libraries treat the tokens signed with the none algorithm as a valid token with a verified signature. You must be seeing where this is going. We will replace the alg property in the JWT header of our token by none. Then change some date in the payload section and remove the signature. If Juice Shop is vulnerable, our temporary JWT should be accepted.

Let’s copy and paste the JWT header into our terminal to decode it.

Now we copied the decoded header, modified the alg property, and encoded back using base64 command line tool.

Let’s copy and paste a new header into our text editor, appending a dot to separate it from the payload section we will append here later.

We need to do the same with the payload. Let’s copy and paste it into our terminal so that we can decode it.

Now we copy and paste the decoded payload, modified email property to something that should not exist in Juice Shop database, and encode the modified JSON payload using base64.

Again, let’s copy and paste the outcome into our text editor.

We won’t add a signature, since our token is not signed according to our new JWT header.

Now we are going to replace the token in our browser’s cookies and local storage with our crafted JSON web token.

Let’s now access some pages and see whether Juice Shop accepts our crafted JSON web token.

As you can see, the complaint form shows the email address we replaced in the JSON web token. Let’s see if we can post a message.

It looks like we have done it. Let’s check the customer feedback feature.

It also shows the email address we replaced in the JSON web token. Let’s also post some feedback.

Based on what we have experienced, that JSON web token library used by Juice Shop is vulnerable. Next we will discuss what makes the application vulnerable and how to prevent it.