# notes

### What are JWTs?

* JSON web tokens (JWTs) - standarized format for sending cryptographically signed JSON data between systems
* contain any kind of data but are most commonly used to send information ("claims") about users as part of authentication, session handling and access control mechanisms

#### JWT format

* 3 parts: `header`, `payload` and `signature` separated by dot
* header and payload parts of a JWT are just base64url-encoded JSON objects
*   header contains metadata about the token itself, while the payload contains actual claims about the user

    eg -

```
eyJraWQiOiI5MTM2ZGRiMy1jYjBhLTRhMTktYTA3ZS1lYWRmNWE0NGM4YjUiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJwb3J0c3dpZ2dlciIsImV4cCI6MTY0ODAzNzE2NCwibmFtZSI6IkNhcmxvcyBNb250b3lhIiwic3ViIjoiY2FybG9zIiwicm9sZSI6ImJsb2dfYXV0aG9yIiwiZW1haWwiOiJjYXJsb3NAY2FybG9zLW1vbnRveWEubmV0IiwiaWF0IjoxNTE2MjM5MDIyfQ.SYZBPIBg2CRjXAJ8vCER0LA_ENjII1JakvNQoP-Hw6GG1zfl4JyngsZReIfqRvIAEi5L4HV0q7_9qGhQZvy9ZdxEJbwTxRs_6Lb-fZTDpW6lKYNdMyjw45_alSCZ1fypsMWz_2mTpQzil0lOtps5Ei_z7mM7M8gCwe_AGpI53JxduQOaB5HkT5gVrv9cKu9CsW5MS6ZbqYXpGyOG5ehoxqm8DL5tFYaW3lB50ELxi0KsuTKEbD0t5BCl0aCR2MBJWAbN-xeLwEenaqBiwPVvKixYleeDQiBEIylFdNNIMviKRgXiYuAvMziVPbwSgkZVHeEdF5MQP1Oe2Spac-6IfA
```

* header part is decoded as follow

```json
{ "kid": "9136ddb3-cb0a-4a19-a07e-eadf5a44c8b5", "alg": "RS256" }
```

* payload part

```json
{
  "iss": "portswigger",
  "exp": 1648037164,
  "name": "Carlos Montoya",
  "sub": "carlos",
  "role": "blog_author",
  "email": "carlos@carlos-montoya.net",
  "iat": 1516239022
}
```

* security of any JWT-based mechanism is heavily reliant on the cryptographic signature

### JWT attacks

* user sending modified JWTs to the server in order to achieve a malicious goal
* goal is to bypass authentication and access controls by impersonating another user who has been authenticated
* impact - severe

#### Exploiting flawed JWT signature verification

* by design, servers don't store any information about the JWTs that they issue and instead each token is an entirely self-contained entity
* one problem is that server doesn't know anything about the original contents of the token or even what the original signature was
* if the server doesn't verify the signature properly, the attacker can chage the rest of the token

1. Accepting arbitary signatures

* the application doesn't verify the signature part at all
* just change the payload parameters and it works

1. Accepting tokens with no signature

* in header part, it looks like :

```json
{
  "alg": "HS256",
  "typ": "JWT"
}
```

* "alg" parameter is set to `none` -> `unsecured JWT`
* servers usually reject tokens with no signature
* but this kind of filtering relies on string parsing, and can bypass by using classic obfuscation techniques such as mixed capitalization and unexpected encodings

1. Brute-forcing secret keys

* some signing algorithms such as HS256 (HMAC + SHA-256) use an arbitary standalone string as the secret key like password and this secret can't be easily guessed or brute-forced by an attacker
* otherwise, they may be able to create JWTs with any header and payload values and use that key to resign the token with a valid signature
* sometimes, develpers make mistakes like forgetting to change default or placeholder secrets, or copy and paste code snippets they find online
* an attacker can brute-force a server's secret using [wordlist of well-known secrets](https://github.com/wallarm/jwt-secrets)
* use `hashcat` to burte-force

```
hashcat -a 0 -m 16500 <jwt> <wordlist>
```

#### JWT header parameter injections

* only `alg` header is mandatory
* but JWT header (JOSE header) often contain several other parameters
* eg - `jwk` (JSON Web Key) - provides an embedded JSON object representing the key
  * `jku` (JSON Web Key Set URL) - provides URL from which servers can fetch a set of keys containing the correct key
  * `kid` (Key ID) - provides an ID that servers can use to identify the correct key in cases where there are multiple keys to choose from

**Injecting self-signed JWTs via jwk**

* JWK - standarized format for representing keys as a JSON object eg -

```json
{
  "kid": "ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG",
  "typ": "JWT",
  "alg": "RS256",
  "jwk": {
    "kty": "RSA",
    "e": "AQAB",
    "kid": "ed2Nf8sb-sD6ng0-scs5390g-fFD8sfxG",
    "n": "yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9m"
  }
}
```

* ideally, servers should only use a limited whitelist of public keys to verify JWT signature
* but, misconfigured servers sometimes use any key that's embedded in the `jwk` parameter
* exploit by signing a modified JWT using your own RSA pirvate key, then embedding the matching public key in the jwk header

**Injecting self-signed JWTs via jku parameter**

* instead of using the jwk header parameter, some servers let you use the jku (JWK Set URL) header parameter to reference a JWK Set containing the key
* JWK Set - JSON object containing an array of JWKs representing different keys

```json
{
  "keys": [
    {
      "kty": "RSA",
      "e": "AQAB",
      "kid": "75d0ef47-af89-47a9-9061-7c02a610d5ab",
      "n": "o-yy1wpYmffgXBxhAUJzHHocCuJolwDqql75ZWuCQ_cb33K2vh9mk6GPM9gNN4Y_qTVX67WhsN3JvaFYw-fhvsWQ"
    },
    {
      "kty": "RSA",
      "e": "AQAB",
      "kid": "d8fDFo-fS9-faS14a9-ASf99sa-7c1Ad5abA",
      "n": "fc3f-yy1wpYmffgXBxhAUJzHql79gNNQ_cb33HocCuJolwDqmk6GPM4Y_qTVX67WhsN3JvaFYw-dfg6DH-asAScw"
    }
  ]
}
```

* JWK Sets are sometimes exposed publicly via a standard endpoint `/.well-known/jwks.json`
* more secure websites will only fetch keys from trusted domains, and can bypass like SSRF bypass

**Injecting self-signed JWTs via the kid parameter**

* header of JWT may contain a `kid` (Key ID) parameter, which helps the server to identify which key to use when verifying the signature
* Verification keys are often stored as a JWK Set
* the server may simply look for the JWK with the same `kid` as the token
* `kid` was not defined a concrete structure
* developers might use the `kid` parameter to point to a particular entry in a database, or even the name of a file
* if this parameter is also vulnerable to directory traversal, an attacker can potentially force the server to use an arbitary file from its filesystem

```json
{
  "kid": "../../path/to/file",
  "typ": "JWT",
  "alg": "HS256",
  "k": "asGsADas3421-dfh9DGN-AFDFDbasfd8-anfjkvc"
}
```

* if the server supports JWTs signed using symmetric algorithm, it is dangerous
* one simplest methods is in Linux server use `/dev/null` path, which is an empty file and fetching it return null and signing the token with a Base64-encoded null byte will result a valid signature

#### Other JWT header parameters

* `cty` (Content Type) - to declare a media type for the content in the JWT payload; if you found a way to bypass signature verification, you can try injecting a `cty` header to change the content type to `text/xml` or `application/x-java-serialized-object` which can enable new vectors for XXE and deserialization attacks
* `x5c` (X.509 Certificate Chain) - can be used to inject self-signed certificates similar to the jwk header injection (CVE-2017-2800, CVE-2018-2633)

### JWT algorithm confusion

* known as key confusion attacks
* occur when an attacker is able to force the server to verify the signature of a JSON web token using a different algorithm than is intended by the developers

#### Symmetric Vs Asymmetric

* JWT can be signed using different algorithms
* eg - HS256 (HMAC + SHA256) use a symmetric key means the server uses a single key to both sign and verify the token

!\[\[Pasted image 20221101205841.jpg]]

* other algorithms such as RS256 (RSA + SHA256) uses asymmetric key pairs which contains a private key which the server uses to sign the token and a mathematically related public key that can be used to verify the signature

!\[\[Pasted image 20221101210036.jpg]]

#### Performing algorithm confusion attack

1. Obtain the server's public key
2. Convert the public key to a suitable format
3. Create a malicious JWT with a modified payload and the alg header set to `HS256`
4. Sign the token with HS256, using the public key as the secret

Step 1. Obtain the server's public key

* servers sometimes expose their public keys as JSON Web Key (JWK) objects via endpoint such as `/jwks.json` or `/.well-known/jwks.json` and they may be stored in an array of JWKs called `keys` and known as `JWK Set`

```json
{
	"keys": [
		{
			"kty": "RSA",
			"e": "AQAB",
			"kid": "...",
			"n": "..."
		},
		{
			"kty": "RSA",
			"e": "AQAB",
			"kid": "...",
			"n": "..."
		}
	]
}
```

Step 2 - Convert the public key to a suitable format

* version of the key that you use to sign the JWT must be identical to the server's local copy and every signle byte must match including any non-printing characters
* In Burp
  1. In JWT Editor Keys tab, `New RSA` > paste the JWK that was obtained earlier
  2. Select the `PEM` radio button and copy the resulting PEM key
  3. in Decoder Tab, `Base64-encode` the PEM
  4. in JWT Editor Keys, `New Symmetric Key` > `Generate`
  5. replace the generated value for the `k` parameter with a Base64-encoded PEM key that was copied and save the key

Step 3 - Modify your JWT

* modify the JWT as you like and make sure the `alg` header to `HS256`

Step 4 - Sign the JWT using the public key

* Sign the token using the HS256 algorithm with the RSA public key as secret
