Attention! Hacking JSON Web Tokens (JWT)

The paper contains 4545 words and is expected to last 13 minutes

Imagine, you are lying at home comfortably brush the public account, suddenly, your mobile phone beeps, a large sum of money from your card disappeared, anxious you start to panic straight stamp feet, how to return a responsibility? !

Suddenly you think of the “JSON Web Token” article you just saw at Core-Reading.

Ll: Well, it turns out that someone forged a token to log on to the bank’s website and withdraw money.

Understand, relieved… Damn it. Call the police.

Here, We’ll take you through this JWT article to explore the security pitfalls of using JWT (and signature-based tokens in general) and the ways attackers can use them to circumvent access control.

Is JSONWeb Token?

JSON Web Token is an access Token that is widely used in commercial applications. It is based on JSON format and includes a signature to ensure the integrity of the token.

How does JWT work?

The JWT consists of three parts: header, payload, and signature.

The head

The header of the JWT declares the signature algorithm. The following code is the base64URL-encoded string header of a JSON blob object:

{

“alg” :”HS256″,

“typ” : “JWT”

}base64url encoded string: eyBhbGcgOiBIUzI1NiwgdHlwIDogSldUIH0K

Base64 URL encoding is a modified version of Base64 URL encoding in THE URL format. It is very similar to Base64, but it uses different symbolic characters and omits padding.

The most commonly used JWT algorithms are HMAC (Hash-based Message Authentication Code) and RSA (asymmetric encryption algorithm).

load

The payload contains information for access control. This section is also encoded using base64URL before being used to generate the token.

{

“user_name” :”admin”,

}base64url encoded string: eyB1c2VyX25hbWUgOiBhZG1pbiB9Cg

The signature

The signature is used to verify that the token has been tampered with. Its calculation method is: the encoded header and the payload are connected in series, and then the header declaration algorithm is used to sign.

signature= HMAC-SHA256(base64urlEncode(header) + ‘.’ + base64urlEncode(payload),secret_key)// Let’s just say the value of secret_key is “key”.->signature function returns 4Hb/6ibbViPOzq9SJflsNGPWSk6B8F6EqVrkNjpXh7M

The token using the key for the “key” HS256 algorithm for string “eyBhbGcgOiBIUzI1NiwgdHlwIDogSldUIH0K. EyB1c2VyX25hbWUgOiBhZG1pbiB9Cg” signature. Encoded string “4 hb / 6 ibbvipozq9sjflsngpwsk6b8f6eqvrknjpxh7m”.

Complete the token

Replace the header, payload, and signature with “. These can be linked together to form a complete token. As follows:

eyBhbGcgOiBIUzI1NiwgdHlwIDogSldUIH0K.

eyB1c2VyX25hbWUgOiBhZG1pbiB9Cg.

4Hb/ 6ibbViPOzq9SJflsNGPWSk6B8F6EqVrkNjpXh7M

How do I bypass JWT access control

Normally, since the JWT payload data cannot be tampered with, it provides a secure way to identify the user (since the user does not have access to the key, she cannot sign the token).

However, if JWT is abnormal, an attacker can bypass its security mechanisms in a number of ways to forge tokens.

Changing the algorithm type

One way an attacker can forge a token is by tampering with the ALG field in the header. If the application does not limit the type of algorithm used by JWT, an attacker may compromise token security by specifying an algorithm.

1. Do not use encryption algorithms

JWT supports setting the algorithm to “None”. If the “ALG” field is set to “None”, the signature is left blank so that any token is valid. Such as:

eyAiYWxnIiA6ICJOb25lIiwgInR5cCIgOiAiSldUIiB9Cg.

eyB1c2VyX25hbWUgOiBhZG1pbiB9Cg.

This token is simply the base64URL-encoded value of the following bloB objects; it does not provide a signature.

{

Alg: None,

“Typ” : “JWT”

} {

“User” : “admin”

}

The original purpose of this feature was to facilitate debugging. However, if this feature is not turned off in a production environment, attackers can forge any token they want by setting the ALG field to “None,” and then use the forged token to impersonate any user to log on to the site.

2. The HMAC algorithm

The two most common JWT algorithms are HMAC and RSA. HMAC uses the same key to sign and authenticate the token. RSA requires two keys. The private key is used to encrypt the token and the corresponding public key is used to authenticate the token.

HMAC->

signed with a key, verified with the same keyRSA ->

signed with aprivate key,

verified with the corresponding public key

Be careful to protect the HMAC key and RSA private key information, as they are both signed to tokens.

Now, suppose you have an application signed with RSA. These tokens are signed with private key A, which is kept secret from the public. This is verified using public key B, which anyone can obtain. The token is valid as long as the token’s algorithm is not changed.

Token signed with key A -> Token verified with key B (RSA scenario)

However, if an attacker changes the algorithm to HMAC, he can use the public key B under the original RSA to sign the forged token, which will also be valid.

This is because when RSA is initially used to sign the token, the application uses public key B to authenticate the user. When the algorithm is changed to HMAC, RSA’s public key B is still used for authentication, but this time, public key B can also be used for signing (because HMAC is symmetric encryption).

Token signed with key B -> Token verified with key B (HMAC scenario)

Providing invalid signatures

Once it reaches the application, the token signature may never be authenticated. This allows an attacker to simply bypass the security mechanism by providing invalid signatures.

Brute force key

An attacker can also brute force crack the JWT key used for signing.

In the first step, the attacker needs to know some information: the algorithm used for the token signature, the encrypted payload, and the resulting encrypted string. If the key is not complex enough, an attacker could easily brute force it.

Leaking key

Assuming the attacker can’t brute force the key, he might find a way to get it out. If an attacker uses document vulnerabilities (such as directory traversal, XXE and SSRF vulnerabilities) to read a document that stores the key value, he can steal the key and sign any token.

Manipulation of the KID

KID stands for Key ID. It is an optional field in the JWT header that a developer can use to identify a key for an authentication token. The correct use of the KID argument is as follows:

{

“alg”: “HS256”,

“typ”: “JWT”,

“kid”: “1” // use key number 1 to verify the token

}

Because the field is controlled by the user, it could be manipulated by an attacker, with dangerous consequences.

1. Directory traversal

Because KID is commonly used to retrieve key files from a file system, if KID is not cleaned before use, the file system may be vulnerable to directory traversal attacks. In this way, an attacker can specify any file in the file system as the key for authentication.

“Kid” : “.. /.. // Publicly/CSS /main. CSS “// Use the publicly available file main. CSS to verify the token

For example, an attacker could force an application to use a publicly available file as a key and sign an HMAC-encrypted token with that file.

2. SQL injection

KID can also be used to retrieve keys in a database. In this case, an attacker would most likely use SQL injection to bypass JWT security mechanisms.

If SQL injection can be made on the KID parameter, the attacker can use that injection to return arbitrary values.

“The kid” : “aaaaaaa ‘UNION the SELECT’ key ‘; –“// use the string “key” toverify the token

The above injection causes the application to return the string “key” (because there is no key named “aaaaAAA” in the database). The token is then authenticated using the string “key” as the key.

Control head parameter

In addition to KID, the JWT standard lets developers specify keys through urls.

1. JKU header parameters

JKU, which stands for “JWKSet URL,” is an optional field in the header that specifies the URL to link to a set of cryptographic token keys. If this field is allowed without qualification, an attacker can host its own key file and specify an application with which to authenticate tokens.

jku URL -> file containing JWK set -> JWK used to verify the token

2. JWK header parameters

The optional header parameter JWK (JSON Web Key) enables an attacker to embed the authenticated Key directly into the token.

3. Manipulate X5U and X5C urls

Similar to the JKU or JWK headers, the X5U and X5C header parameters enable an attacker to specify a public key certificate or certificate chain for authentication. X5U specifies information in the form of a URI, while X5C allows certificate values to be embedded in tokens.

Other Security risks

If the JWT security mechanism does not work properly, other security risks may arise. These issues are uncommon, but definitely worth paying attention to:

Information leakage

Because JWT is used for access control, it usually contains information about the user.

If the token is not encrypted, anyone can decode and read the payload information on the token through Base64. Therefore, if a token contains sensitive information, it can be a source of information leakage. Normal token signatures only guarantee data integrity, not confidentiality.

The command injection

Sometimes, passing the KID argument directly to an insecure file read operation can cause commands to be injected into the code stream.

Some functions, such as Ruby Open (), allow this type of attack. An attacker can execute system commands by simply adding commands after the entered KID file name:

“Key_file” | whoami;

This is just one example of many similar situations. In theory, this vulnerability can occur whenever an application passes an uncensored header file parameter to a function such as System (), exec ().

In essence, JWT is just another form of user input. JWT should be used with caution and strictly vetted by application developers.

Disclaimer: This article is intended to draw attention to JWT security vulnerabilities and to help developers become aware of common pitfalls. Please do not use this information to attack websites or impersonate others.

It is illegal to try this operation on a system that you do not have test permissions on. If you find a security breach, be sure to disclose it to your provider to help create a more secure Internet environment. Everyone is a good boy ~

Leave a comment like follow

We share the dry goods of AI learning and development. Welcome to pay attention to the “core reading technology” of AI vertical we-media on the whole platform.

(Add wechat: DXSXBB, join readers’ circle and discuss the freshest artificial intelligence technology.)