SMTP Smuggling

Reading time: 12 minutes

tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！
**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。
HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

基本情報

この種の脆弱性はこの投稿で最初に発見されましたで説明されており、メールを確定する際のSMTPプロトコルの解釈の不一致を悪用することで、攻撃者が正当なメール本文に追加のメールを密輸し、影響を受けるドメインの他のユーザ（例: admin@outlook.com）になりすまして SPF のような防御を回避できることを示しています。

理由

これは、SMTPプロトコルでは送信されるメールのメッセージデータがユーザ（攻撃者）によって制御され、パーサの差異を悪用する特殊なデータを送ることで受信側に追加のメールを密輸できるためです。元の投稿の図解例を見てください：

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

仕組み

この脆弱性を悪用するには、攻撃者は Outbound SMTP サーバはそれを1通のメールだと扱うが Inbound SMTP サーバは複数のメールだと扱う ようなデータを送る必要があります。

研究者らは、異なる受信（Inbound）サーバがメールメッセージのデータ終了を示す文字列を Outbound サーバと異なって扱うことを発見しました。
例えば、通常のデータ終端は \r\n.\r です。しかし受信側の SMTP サーバが \n. もサポートしている場合、攻撃者はそのデータをメールに追加して新しい SMTP コマンドの指示を開始することで、前の図のようにメールを密輸することができます。

もちろん、これは Outbound SMTP サーバが同じシーケンスをメッセージ終端として扱わない場合にのみ機能します。もし Outbound 側も終端と扱うなら、2通のメールとして扱われてしまいます。要するにこの脆弱性は解析の非同期化（desynchronization）を悪用しています。

潜在的な非同期化シーケンス:

\n.
\n.\r

また、SPF が回避される点にも注意してください。例えば user@outlook.com のメール内に admin@outlook.com を密輸すると、送信元は依然として outlook.com と見なされます。

攻撃者チェックリスト（どの条件が必要か）

セカンドメールを正常に密輸するには通常、以下が必要です：

送信に使える outbound サーバ A（しばしば有効な認証情報が必要）で、非標準の end‑of‑DATA シーケンスを変更せずに転送すること。多くのサービスは歴史的に \n.\r\n や \n.\n のようなバリアントを転送してきました。
受信サーバ B がその非標準シーケンスを DATA 終端として解釈し、その後に続くものを新しい SMTP コマンド（MAIL/RCPT/DATA...）として解析すること。
Outbound は実際に DATA で送信すること（BDAT ではない）。A が CHUNKING/BDAT をサポートする場合、B が CHUNKING を広告しないなどして DATA にフォールバックしない限り、BDAT の長さ指定により曖昧さは生じないため、密輸は成立しない。
PIPELINING は必須ではありませんが、注入したコマンドを単一の TCP 書き込みに隠すことで中間機器が再同期するのを防ぎやすくなります。

受信側依存でテストすべき一般的な end‑of‑DATA バリアント:

\n.\n
\n.\r\n
\r.\r\n
\r\n.\r（末尾が裸の CR）

注：実際に動作するのは「A が転送するもの」∩「B が受け入れるもの」の交差部分です。

手動での悪用例（単一セッション）

以下は生の 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

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.

---

## 自動化とスキャナー

- hannob/smtpsmug: 複数の不正な end‑of‑DATA シーケンスで終わるメッセージを送信し、受信側がどれを受け入れるか確認する。
- Example: `./smtpsmug -s mail.target.com -p 25 -t victim@target.com`
- The‑Login/SMTP‑Smuggling‑Tools: inbound と outbound の両側をスキャンするツールと、送信側でどのシーケンスが生き残るかを正確に確認するための解析用 SMTP サーバ。
- 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 '...'
`

これらのツールは、smuggling が実際に機能する A→B のペアをマッピングするのに役立ちます。

---

## CHUNKING/BDAT vs DATA

- DATA はセントネル終端子 `<CR><LF>.<CR><LF>` を使用するため、CR/LF の正規化や dot‑stuffing の扱いに曖昧さがあると desync が発生します。
- CHUNKING (BDAT) は本文を正確なバイト長でフレーム化するため、古典的な smuggling を防ぎます。ただし、送信側が CHUNKING を広告していない受信側にフォールバックして DATA を使うと、再び古典的な smuggling が可能になります。

---

## 影響を受けるソフトウェアと修正について（ターゲティング向け）

- Postfix: 3.9 より前はデフォルトで bare LF を許容していました；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+）か、厳格な RFC 準拠を求めるなら `reject` に設定することです。
- Exim: DATA を使用する際に混在した end‑of‑DATA シーケンスに依存するバリアントについては 4.97.1（およびそれ以降）で修正されました。古い 4.97/4.96 は PIPELINING/CHUNKING の状況によっては悪用可能な場合があります。
- Sendmail: 8.18 で修正されました；古い 8.17.x はいくつかの非標準な終端子を受け入れていました。
- 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>`.

上記のスキャナーを使って現在の挙動を検証してください；多くのベンダーが 2024〜2025 年初頭にデフォルトを変更しています。

---

## レッドチーム運用のヒント

- A には大規模な汎用送信者を使うのが有利です（歴史的に Exchange Online、共有ホスティングなど）。彼らがまだ非標準の EOM を転送しており、かつ被害者の SPF に含まれていれば、あなたの smuggled MAIL FROM は彼らの評判を引き継ぎます。
- B の SMTP 拡張を列挙する：PIPELINING/CHUNKING があるかは EHLO バナーで確認；CHUNKING が無ければ BDAT‑first の送信者からの試行で成功しやすくなります。malformed EOM と組み合わせて受け入れを探ってください。
- ヘッダを監視する：smuggled メッセージは通常 B で始まる別の Received チェーンを生成します。MAIL FROM が A の IP 空間と整合すれば DMARC は通過することが多いです。

---

## 参考

- [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ハッキングを学び、実践する：<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ハッキングを学び、実践する：<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ハッキングを学び、実践する：<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)または[**テレグラムグループ**](https://t.me/peass)に参加するか、**Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**をフォローしてください。**
- **[**HackTricks**](https://github.com/carlospolop/hacktricks)および[**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud)のGitHubリポジトリにPRを提出してハッキングトリックを共有してください。**

</details>

</div>