SMTP Smuggling

Reading time: 7 minutes

tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Основна інформація

This type of vulnerability was originally discovered in this post were it's explained that It's possible to exploit discrepancies in how the SMTP protocol is interpreted when finalising an email, allowing an attacker to smuggle more emails in the body of the legit one, allowing to impersonate other users of the affected domain (such as admin@outlook.com) bypassing defenses such as SPF.

Чому

Це тому, що в протоколі SMTP дані повідомлення, які відправляються в листі, контролюються користувачем (атакуючим), який може надіслати спеціально сформовані дані, зловживаючи відмінностями в парсерах, що дозволить підмішувати додаткові листи в те, що отримує приймаючий сервер. Подивіться на цей ілюстрований приклад з початкової публікації:

https://sec-consult.com/fileadmin/user_upload/sec-consult/Dynamisch/Blogartikel/2023_12/SMTP_Smuggling-Overview__09_.png

Як

Щоб експлуатувати цю вразливість, атакуючому потрібно надіслати такі дані, які вихідний SMTP‑сервер вважатиме одним листом, але вхідний SMTP‑сервер вважатиме за кілька листів.

Дослідники виявили, що різні вхідні сервери вважають різні символи кінцем даних повідомлення, тоді як вихідні сервери — ні.
Наприклад, звичайним кінцем даних є \r\n.\r. Але якщо вхідний SMTP‑сервер також підтримує \n., атакуючий може просто додати ці дані в свій лист і почати вказувати SMTP‑команди нового повідомлення, щоб прокрасти його, як показано на попередньому зображенні.

Звісно, це спрацює лише якщо вихідний SMTP‑сервер також не трактує ці дані як кінець даних повідомлення, бо в такому випадку він побачить 2 листи замість одного — саме ця десинхронізація й використовується у вразливості.

Можливі послідовності, що викликають десинхронізацію:

  • \n.
  • \n.\r

Зверніть також увагу, що SPF обходиться, бо якщо ви прокрадаєте лист від admin@outlook.com всередині листа від user@outlook.com, відправник все одно буде outlook.com.


Контрольний список атакуючого (які умови мають виконуватись?)

Щоб успішно прокрасти другий лист, зазвичай потрібно:

  • Вихідний сервер A, через який ви можете відправляти (часто з дійсними обліковими даними), який пересилає нестандартну послідовність кінця DATA без змін. Багато сервісів історично пересилали варіанти на кшталт \n.\r\n або \n.\n.
  • Сервер-приймач B, який інтерпретує цю нестандартну послідовність як кінець DATA і потім розпарсить те, що йде далі, як нові SMTP‑команди (MAIL/RCPT/DATA...).
  • Вихідний трафік має дійсно відправлятися через DATA (не BDAT). Якщо A підтримує CHUNKING/BDAT, smuggling працює тільки якщо він падає назад на DATA (наприклад, B не оголошує CHUNKING), інакше фреймування довжини в BDAT усуває неоднозначність.
  • PIPELINING не є обов’язковим, але допомагає приховати інжектовані команди в одному TCP‑записі, щоб проміжні пристрої не ресинхронізувалися.

Типові варіанти кінця DATA, які варто протестувати (залежить від приймача):

  • \n.\n
  • \n.\r\n
  • \r.\r\n
  • \r\n.\r (bare CR at end)

Примітка: Працює перетин “що A пересилає” ∩ “що B приймає”.


Ручний приклад експлуатації (одна сесія)

Наведене ілюструє ідею з використанням raw STARTTLS SMTP сесії. Після першого блоку DATA ми вставляємо нестандартний термінатор, а потім ще один SMTP‑діалог, який сервер-приймач може трактувати як нове повідомлення.

Manual smuggling session (STARTTLS) ``` $ openssl s_client -starttls smtp -crlf -connect smtp.example.com:587 EHLO a.example AUTH PLAIN MAIL FROM: RCPT TO: DATA From: User To: victim Subject: legit

hello A \n.\r\nMAIL FROM:admin@target.com RCPT TO:victim@target.com DATA From: Admin admin@target.com To: victim victim@target.com Subject: smuggled

hello B \r\n.\r\n

</details>

Якщо A пересилає `\n.\r\n`, а B сприймає це як кінець DATA, повідомлення “hello B” може бути прийняте як другий лист від `admin@target.com`, при цьому проходячи SPF (вирівняне з IP-адресами A).

Tip: When testing interactively, ensure `-crlf` is used so OpenSSL preserves CRLF in what you type.

---

## Автоматизація та сканери

- hannob/smtpsmug: надсилає повідомлення, яке завершується кількома некоректними послідовностями end‑of‑DATA, щоб побачити, що приймає приймач.
- Example: `./smtpsmug -s mail.target.com -p 25 -t victim@target.com`
- The‑Login/SMTP‑Smuggling‑Tools: сканер для вхідної та вихідної сторін, а також аналізуючий SMTP‑сервер, щоб точно побачити, які послідовності проходять від відправника.
- Швидка перевірка вхідного трафіку: `python3 smtp_smuggling_scanner.py victim@target.com`
- Вихід через relay: `python3 smtp_smuggling_scanner.py YOUR@ANALYSIS.DOMAIN --outbound-smtp-server smtp.relay.com --port 587 --starttls --sender-address you@relay.com --username you@relay.com --password '...'
`

Ці інструменти допомагають зіставити пари A→B, де smuggling справді працює.

---

## CHUNKING/BDAT проти DATA

- DATA використовує маркер-термінатор `<CR><LF>.<CR><LF>`; будь-яка невизначеність у нормалізації CR/LF або dot‑stuffed призводить до десинхронізації.
- CHUNKING (BDAT) обрамляє тіло точною довжиною в байтах і тому запобігає класичному smuggling. Однак, якщо відправник повертається до DATA (тому що приймач не оголошує CHUNKING), класичний smuggling знову стає можливим.

---

## Зауваги щодо уразливого програмного забезпечення та виправлень (для таргетингу)

- Postfix: до 3.9 за замовчуванням дозволяв bare LFs; починаючи з 3.5.23/3.6.13/3.7.9/3.8.4 адміністратори могли увімкнути `smtpd_forbid_bare_newline`. Нинішня рекомендація — `smtpd_forbid_bare_newline = normalize` (3.8.5+/3.7.10+/3.6.14+/3.5.24+) або встановити `reject` для суворого дотримання RFC.
- Exim: виправлено в 4.97.1 (і пізніших) для варіантів, що покладалися на змішані end‑of‑DATA послідовності при використанні DATA. Старіші 4.97/4.96 можуть бути експлуатовані залежно від PIPELINING/CHUNKING.
- Sendmail: виправлено в 8.18; старіші 8.17.x приймали деякі нестандартні термінатори.
- Різні бібліотеки/сервери (наприклад, aiosmtpd before 1.4.5, деякі vendor gateways і певні SaaS relays) мали схожі проблеми; сучасні версії зазвичай приймають DATA лише з суворим `<CR><LF>.<CR><LF>`.

Використовуйте наведені сканери, щоб перевірити поточну поведінку; багато постачальників змінили значення за замовчуванням на початку 2024–2025 років.

---

## Поради для red team ops

- Віддавайте перевагу великим комерційним відправникам для A (історично Exchange Online, shared hosters тощо). Якщо вони все ще пересилають деякі нестандартні EOM і вони входять у SPF жертви, ваш smuggled MAIL FROM успадкує їхню репутацію.
- Перелічіть SMTP‑розширення B: банер `EHLO` на предмет PIPELINING/CHUNKING; якщо CHUNKING відсутній, у вас кращий шанс із відправниками, які використовують BDAT першими. Поєднуйте з некоректними EOM, щоб перевіряти прийняття.
- Слідкуйте за заголовками: smuggled повідомлення зазвичай створює окремий ланцюжок Received, що починається від B. DMARC часто пройде, оскільки MAIL FROM вирівняний з IP‑простором A.

---

## **References**

- [https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/](https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/)
- [https://www.postfix.org/smtp-smuggling.html](https://www.postfix.org/smtp-smuggling.html)

<div class="mdbook-alerts mdbook-alerts-tip">
<p class="mdbook-alerts-title">
  <span class="mdbook-alerts-icon"></span>
  tip
</p>


Вивчайте та практикуйте AWS Hacking:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
Вивчайте та практикуйте GCP Hacking: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
Вивчайте та практикуйте Azure Hacking: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://training.hacktricks.xyz/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">

<details>

<summary>Підтримайте HackTricks</summary>

- Перевірте [**плани підписки**](https://github.com/sponsors/carlospolop)!
- **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи telegram**](https://t.me/peass) або **слідкуйте** за нами в **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
- **Діліться хакерськими трюками, надсилаючи PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв на github.

</details>

</div>