SMTP Smuggling
Reading time: 7 minutes
tip
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Ucz się i ćwicz Hacking Azure:
HackTricks Training Azure Red Team Expert (AzRTE)
Wsparcie dla HackTricks
- Sprawdź plany subskrypcyjne!
- Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @hacktricks_live.
- Dziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów na githubie.
Podstawowe informacje
Ten typ podatności został pierwotnie odkryty w tym wpisie, gdzie wyjaśniono, że możliwe jest wykorzystanie rozbieżności w interpretacji protokołu SMTP przy finalizowaniu wiadomości, co pozwala atakującemu przemycić więcej e‑maili w treści prawidłowej wiadomości, umożliwiając podszywanie się pod innych użytkowników dotkniętej domeny (np. admin@outlook.com) i obejście zabezpieczeń takich jak SPF.
Dlaczego
W protokole SMTP dane wiadomości przesyłane w e‑mailu są kontrolowane przez użytkownika (atakującego), który może wysłać specjalnie spreparowane dane wykorzystujące różnice w parserach, które przemycą dodatkowe wiadomości do odbiorcy. Zobacz ilustracyjny przykład z oryginalnego wpisu:
 (1) (1) (1) (1).png)
Jak
Aby wykorzystać tę podatność, atakujący musi wysłać dane, które serwer Outbound SMPT zinterpretuje jako jedną wiadomość, ale serwer Inbound SMTP uzna za kilka wiadomości.
Badacze odkryli, że różne serwery Inbound uznają różne znaki za koniec sekcji danych wiadomości, których serwery Outbound nie traktują w ten sposób.
Na przykład standardowym zakończeniem danych jest \r\n.\r
. Jeśli jednak serwer Inbound SMTP obsługuje także \n.
, atakujący może dodać tę sekwencję w swojej wiadomości i zacząć umieszczać polecenia SMTP rozpoczynające nową wiadomość, przemycając je tak jak na poprzednim obrazku.
Oczywiście, działa to tylko wtedy, gdy serwer Outbound nie traktuje tej samej sekwencji jako zakończenia danych — w takim wypadku zobaczy dwie wiadomości zamiast jednej, więc w grę wchodzi desynchronizacja, którą się tu nadużywa.
Potencjalne dane desynchronizacji:
\n.
\n.\r
Zauważ też, że SPF jest ominięty, ponieważ jeżeli przemycisz wiadomość z admin@outlook.com
z wiadomości wysłanej z user@outlook.com
, to nadawca nadal będzie należał do outlook.com
.
Lista kontrolna atakującego (jakie warunki muszą być spełnione?)
Aby pomyślnie przemycić drugą wiadomość, zwykle potrzebujesz:
- serwera outbound A, przez który możesz wysyłać (często z poprawnymi poświadczeniami), który będzie przekazywał niestandardową sekwencję końca DATA bez zmian. Wiele usług historycznie przekazywało warianty takie jak
\n.\r\n
lub\n.\n
. - serwera odbierającego B, który zinterpretuje tę niestandardową sekwencję jako koniec DATA, a następnie potraktuje to, co następuje po niej, jako nowe polecenia SMTP (MAIL/RCPT/DATA...).
- Outbound musi faktycznie wysyłać za pomocą
DATA
(nieBDAT
). Jeśli A obsługuje CHUNKING/BDAT, smuggling działa tylko wtedy, gdy nastąpi fallback do DATA (np. B nie reklamuje CHUNKING), w przeciwnym razie transmisja z długością (BDAT) eliminuje niejednoznaczność. - PIPELINING nie jest wymagany, ale pomaga ukryć wstrzyknięte polecenia w jednym zapisie TCP, tak aby urządzenia pośrednie nie zresynchronizowały połączenia.
Powszechne warianty końca DATA warte przetestowania (zależne od odbiorcy):
\n.\n
\n.\r\n
\r.\r\n
\r\n.\r
(bezpośrednie CR na końcu)
Uwaga: Działa to tam, gdzie zachodzi przecięcie: “co A przekazuje” ∩ “co B akceptuje”.
Przykład ręcznego wykorzystania (pojedyncza sesja)
Poniżej pokazana jest idea użycia surowej sesji STARTTLS SMTP. Po pierwszym bloku DATA wstawiamy niestandardowy terminator, a następnie drugie dialog SMTP, które serwer odbierający może potraktować jako nową wiadomość.
Manual smuggling session (STARTTLS)
``` $ openssl s_client -starttls smtp -crlf -connect smtp.example.com:587 EHLO a.example AUTH PLAINhello 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
Jeśli A przekaże `\n.\r\n` i B zaakceptuje to jako koniec DATA, wiadomość “hello B” może zostać przyjęta jako drugi e-mail od `admin@target.com` przy jednoczesnym przejściu SPF (zgodnym z IP A).
</details>
Tip: When testing interactively, ensure `-crlf` is used so OpenSSL preserves CRLF in what you type.
---
## Automation and scanners
- hannob/smtpsmug: wyślij wiadomość kończącą się wieloma nieprawidłowymi sekwencjami end‑of‑DATA, aby sprawdzić, które odbiorca zaakceptuje.
- Example: `./smtpsmug -s mail.target.com -p 25 -t victim@target.com`
- The‑Login/SMTP‑Smuggling‑Tools: skaner dla ruchu przychodzącego i wychodzącego oraz serwer SMTP do analizy, aby zobaczyć dokładnie, które sekwencje przetrwają po stronie nadawcy.
- Inbound quick check: `python3 smtp_smuggling_scanner.py victim@target.com`
- Outbound via a 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 '...'
`
These tools help you map the A→B pairs where smuggling actually works.
---
## CHUNKING/BDAT vs DATA
- DATA uses a sentinel terminator `<CR><LF>.<CR><LF>`; any ambiguity in how CR/LF are normalized or dot‑stuffed leads to desync.
- CHUNKING (BDAT) frames the body with an exact byte length and therefore prevents classic smuggling. However, if the sender falls back to DATA (because the receiver doesn’t advertise CHUNKING), classic smuggling becomes possible again.
---
## Uwagi o podatnym oprogramowaniu i poprawkach (dla targetowania)
- Postfix: przed wersją 3.9 domyślnie tolerowano gołe LFs; od 3.5.23/3.6.13/3.7.9/3.8.4 administratorzy mogą włączyć `smtpd_forbid_bare_newline`. Obecne zalecenie to `smtpd_forbid_bare_newline = normalize` (3.8.5+/3.7.10+/3.6.14+/3.5.24+) lub ustawienie na `reject` dla ścisłego egzekwowania RFC.
- Exim: naprawione w 4.97.1 (i nowszych) dla wariantów polegających na mieszanych sekwencjach end‑of‑DATA, gdy używane jest DATA. Starsze 4.97/4.96 mogą być podatne w zależności od PIPELINING/CHUNKING.
- Sendmail: naprawione w 8.18; starsze 8.17.x akceptowały pewne niestandardowe terminatory.
- Various libraries/servers (e.g., aiosmtpd before 1.4.5, some vendor gateways, and specific SaaS relays) had similar issues; modern versions tend to accept DATA only with strict `<CR><LF>.<CR><LF>`.
Use the scanners above to verify current behavior; many vendors changed defaults in early 2024–2025.
---
## Wskazówki dla operacji red team
- Favor large commodity senders for A (historically Exchange Online, shared hosters, etc.). If they still forward some non‑standard EOM and they’re in the victim’s SPF, your smuggled MAIL FROM will inherit their reputation.
- Enumerate B’s SMTP extensions: `EHLO` banner for PIPELINING/CHUNKING; if CHUNKING is missing you have a better chance from BDAT‑first senders. Combine with malformed EOMs to probe acceptance.
- Watch headers: the smuggled message will usually create a separate Received chain starting at B. DMARC will often pass because MAIL FROM aligns with A’s IP space.
---
## **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>
Ucz się i ćwicz Hacking AWS:<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;">\
Ucz się i ćwicz Hacking GCP: <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;">
Ucz się i ćwicz Hacking Azure: <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>Wsparcie dla HackTricks</summary>
- Sprawdź [**plany subskrypcyjne**](https://github.com/sponsors/carlospolop)!
- **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
- **Dziel się trikami hackingowymi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repozytoriów na githubie.
</details>
</div>