Hacking Json Web Token

What is JSON Web Token?

According to official website, JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

The Structure of JSON Web Token

The JSON Web Tokens consist of three parts separated by dots (.), which are:

• Header
• Payload
• Signature

The Header

The header consists of two parts: the type of the token, which is JWT, and the signing algorithm which is being used, viz. – HMAC SHA256 or RSA.

For example:

The Payload

The payload part contains the information which defines the claims or is used for access control.

For example:

The Signature

The signature part is created by taking the encoded header, the encoded payload, a secret, the algorithm specified in the header, and signing it.

For example, if we are using HMAC SHA256 algorithm, the signature will be created as follow:

The JWT that has the header and payload encoded, and it is signed with a secret will look like (The complete JWT token):

NOW, The Fun Part..

Let’s see how we can exploit JWT to HACK into victims account

Method UNO: “None algorithm Attack“

Some application supports NONE Algorithm, which makes signature pretty useless.

Step 1: The following screenshot shows the login page of our application. Login with the credentials and capture the request in proxy tool.

Step 2: The following screenshot shows captured request. Observe the highlighted JWT. Take the below request in the repeater:

Step 3: The following screenshot shows the current user: “qseap”

Step 4: We can manually decode the JWT header and payload with the help of decoder. Else, you can also use JWT Burp extension to make things easy as shown below:

Step 5: Now, Change the name from user “qseap” to “admin” and set the algorithm as “None” in JWT Burp extension. Forward the request in the repeater.

Step 6: BOOOOM!! We are now logged in as “admin”. Account takeover successful.“

Method DOS: “Changing the algorithm from ‘RS256’ TO ‘HS256’“

RS256 signs the token asymetrically. It uses private key to sign the token and public key to verify the token.

In case of – HS256 signs the token symmetrically. It uses same key to sign and verify the token. The HMAC key and RSA private key are secret, is not known to public but the RSA public key is known to public.

Now, if an application uses RS256, signs the token using the private key and verify using the public key. We can simply change the algorithm from “RS256“ to “HS256” and create our very own token by signing it with public key. It will be a valid token because HS256 uses same key to sign and verify the token.

Step 1: LogIn into the application. Observe the exposed public key which will be used to sign the token.

Step 2: Capture the request and send it to repeater. Observe the user “qseap”

Step 3: Select the payload and header, decode it (BASE64) and change the algorithm from “RS256” to “HS256”, user from “qseap” to “admin”. Sign it with the public key saved earlier using HS256 algorithm.

After signing, resulted JWT: eyJhbGciOiJIUzI1NiJ9.eyJuYW1lIjoiYWRtaW4ifQ.y65I9S3UiREQPUe0XREshv1sv0vyB0 E-kjW_o14gM3s

Step 4:Replace the resulted TOKEN in place of earlier TOKEN and forward the request. BOOOOOM!! We are Logged-IN as “admin” Account takeover successful.“

Method TRES: “When the Signature is not checked”

In this scenario, the signature is not checked or verified.

Step 1: Login into the application and capture the request in the proxy tool. Observe the following request.

Step 2: Send the request to the repeater and observe the current user in the response.

Step 3: With the help of JWT Burp Extension, Change the user to “admin” and delete the Signature.

Step 4:Forward the request and BOOOOM!! We are LoggedIN as “admin”. Account takeover successful.

NOTE: The above article is to create awareness about common JWT vulnerabilities. Please do not use the information to attack applications where you do not have permission to test. If you find any vulnerability, please disclose it responsibly to the respective application/program.