SMTP Smuggling

Reading time: 7 minutes

tip

AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE)
GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE) Azure Hacking'i öğrenin ve pratik yapın: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks'i Destekleyin

Temel Bilgi

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.

Neden

Bu, SMTP protokolünde gönderilecek mesajın verisinin bir kullanıcı (saldırgan) tarafından kontrol edilmesi ve özel olarak hazırlanmış veriler göndererek farklı parser'lardaki farklılıklardan faydalanıp alıcı tarafta ek e‑posta mesajları "smuggle" edilebilmesinden kaynaklanır. Orijinal yazıdaki bu görselliğe göz atın:

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

Nasıl

Bu açığı sömürmek için bir saldırganın, Outbound SMPT server'ın bunun sadece 1 e‑posta olduğunu düşünürken, Inbound SMTP server'ın bunun birden fazla e‑posta olduğunu düşünmesine yol açacak veri göndermesi gerekir.

Araştırmacılar, farklı Inbound sunucuların e‑posta mesaj verisinin sonu olarak farklı karakterleri kabul ettiğini keşfettiler; Outbound sunucuların kabul etmediği karakterleri bile. Örneğin normal bir veri sonlandırma \r\n.\r iken, eğer Inbound SMTP sunucusu \n. gibi bir şeyi de sonlandırma olarak kabul ediyorsa, saldırgan sadece bu veriyi e‑postasına ekleyip ardından yeni SMTP komutlarını başlatarak bir veya daha fazla e‑posta smuggle edebilir; önceki resimde olduğu gibi.

Örnek olarak, aşağıdaki terminator eklendikten sonra alıcı sunucunun yeni bir mesaj olarak yorumlayabileceği başka bir SMTP diyaloğu başlatılabilir.

Elbette, bu yalnızca Outbound SMTP server da aynı veriyi mesaj sonu olarak işlemezse işe yarar; aksi halde Outbound tarafı da bunu iki ayrı e‑posta olarak görecektir. Sonuçta istismar edilen şey bu desenkronizasyondur.

Olası desenkronizasyon verileri:

  • \n.
  • \n.\r

Ayrıca unutmayın ki SPF atlanır çünkü eğer user@outlook.com içinden admin@outlook.com olarak bir e‑posta smuggle ederseniz, gönderen hâlâ outlook.com olarak görünür.

Saldırganın kontrol listesi (hangi koşullar sağlanmalı?)

İkinci bir e‑postayı başarıyla smuggle edebilmek için genelde şunlar gerekir:

  • Üzerinden gönderim yapabileceğiniz bir outbound sunucu A (çoğunlukla geçerli kimlik bilgileriyle) ve bu sunucunun standart dışı bir end‑of‑DATA dizisini değişmeden iletmesi. Tarihsel olarak birçok servis \n.\r\n veya \n.\n gibi varyantları aktardı.
  • Bu standart dışı diziyi end‑of‑DATA olarak yorumlayıp ardından gelenleri yeni SMTP komutları (MAIL/RCPT/DATA...) olarak parse eden bir alıcı sunucu B.
  • Outbound aslında DATA ile göndermeli (BDAT ile değil). Eğer A CHUNKING/BDAT destekliyorsa, smuggling yalnızca DATA'ya düşerse çalışır (ör. B CHUNKING ilan etmiyorsa); aksi halde uzunluk‑çerçeveli BDAT belirsizliği önler.
  • PIPELINING gerekli değildir ama enjekte edilen komutları tek bir TCP write içinde gizlemeye yardımcı olur, böylece ara cihazlar yeniden senkronize olmazlar.

Alıcıya bağlı olarak denenmeye değer yaygın end‑of‑DATA varyantları:

  • \n.\n
  • \n.\r\n
  • \r.\r\n
  • \r\n.\r (sonda tek CR)

Not: İşe yarayan şey, “A'nın ilettikleri” ∩ “B'nin kabul ettikleri” kesişimidir.

Manuel exploitation örneği (tek oturum)

Aşağıda, ham bir STARTTLS SMTP oturumu kullanılarak fikri gösteren örnek var. İlk DATA bloğundan sonra standart dışı bir terminator ekliyoruz, sonra alıcı sunucunun yeni bir mesaj olarak değerlendirebileceği başka bir SMTP diyaloğu ekliyoruz.

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

If A forwards `\n.\r\n` and B accepts it as end‑of‑DATA, message “hello B” may be accepted as a second email from `admin@target.com` while passing SPF (aligned with A’s IPs).
</details>

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

---

## Otomasyon ve tarayıcılar

- hannob/smtpsmug: alıcının hangi sonlandırmaları kabul ettiğini görmek için çoklu hatalı end‑of‑DATA dizileri ile biten bir mesaj gönderir.
- Örnek: `./smtpsmug -s mail.target.com -p 25 -t victim@target.com`
- The‑Login/SMTP‑Smuggling‑Tools: hem inbound hem outbound taraflar için tarayıcı ve gönderenden hangi dizilerin geçtiğini tam olarak görebilmenizi sağlayan analiz SMTP sunucusu.
- Inbound hızlı kontrol: `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 '...'
`

Bu araçlar, smuggling'in gerçekten çalıştığı A→B çiftlerini haritalamanıza yardımcı olur.

---

## CHUNKING/BDAT vs DATA

- DATA, gövdeyi sonlandırmak için bir sentinel terminator olan `<CR><LF>.<CR><LF>` kullanır; CR/LF'in nasıl normalleştirildiği veya dot‑stuffing yapıldığı konusundaki herhangi bir belirsizlik desenkronizasyona yol açar.
- CHUNKING (BDAT) gövdeyi kesin bayt uzunluğu ile çerçeveler ve bu nedenle klasik smuggling'i engeller. Ancak, gönderen CHUNKING'i ilan etmediği için DATA'ya geri dönerse (fallback), klasik smuggling tekrar mümkün olur.

---

## Etkilenen yazılımlar ve düzeltmeler (hedefleme için)

- Postfix: 3.9 öncesinde varsayılan olarak bare LF'leri tolere ediyordu; 3.5.23/3.6.13/3.7.9/3.8.4 sürümlerinden itibaren yöneticiler `smtpd_forbid_bare_newline`'ı etkinleştirebilir. Mevcut öneri `smtpd_forbid_bare_newline = normalize` (3.8.5+/3.7.10+/3.6.14+/3.5.24+) veya katı RFC uygulaması için `reject` olarak ayarlamaktır.
- Exim: DATA kullanıldığında karışık end‑of‑DATA dizilerine dayanan varyantlar için 4.97.1 (ve sonraki) sürümlerde düzeltildi. Eski 4.97/4.96 sürümleri PIPELINING/CHUNKING'e bağlı olarak istismar edilebilir olabilir.
- Sendmail: 8.18'de düzeltildi; eski 8.17.x bazı standart dışı terminatörleri kabul ediyordu.
- Çeşitli kütüphaneler/sunucular (ör. aiosmtpd 1.4.5 öncesi, bazı vendor gateway'leri ve belirli SaaS relay'leri) benzer sorunlara sahipti; modern sürümler genellikle DATA'yı yalnızca sıkı `<CR><LF>.<CR><LF>` ile kabul ediyor.

Mevcut davranışı doğrulamak için yukarıdaki tarayıcıları kullanın; birçok vendor erken 2024–2025 döneminde varsayılanları değiştirdi.

---

## Tips for red team ops

- A için büyük ticari göndericileri tercih edin (tarihsel olarak Exchange Online, paylaşılan host sağlayıcıları vb.). Eğer hala bazı standart dışı EOM'ları iletiler ve hedefin SPF'inde bulunuyorlarsa, smuggled MAIL FROM onların itibarını devralır.
- B'nin SMTP uzantılarını listeleyin: PIPELINING/CHUNKING için `EHLO` banner'ı; CHUNKING yoksa BDAT‑first gönderenlerden şansınız daha yüksektir. Kabulü denemek için hatalı EOM'larla birleştirin.
- Header'ları izleyin: smuggled mesaj genellikle B'de ayrı bir Received zinciri oluşturur. DMARC genellikle geçer çünkü MAIL FROM A'nın IP alanıyla hizalanır.

---

## Referanslar

- [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'i öğrenin ve pratik yapın:<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'i öğrenin ve pratik yapın: <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'i öğrenin ve pratik yapın: <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'i Destekleyin</summary>

- [**abonelik planlarını**](https://github.com/sponsors/carlospolop) kontrol edin!
- **💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) katılın ya da **Twitter'da** bizi **takip edin** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
- **Hacking ipuçlarını paylaşmak için** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github reposuna PR gönderin.

</details>

</div>