SMTP Smuggling
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
このタイプの脆弱性は、この投稿で最初に発見されました で説明されているように、メールを最終的に送信する際のSMTPプロトコルの解釈の違いを悪用することが可能であり、攻撃者が正当なメールの本文に他のメールを密輸することを可能にし、影響を受けたドメインの他のユーザー（例えば admin@outlook.com）を偽装することができ、SPFなどの防御を回避します。
これは、SMTPプロトコルでは、メールで送信されるメッセージのデータがユーザー（攻撃者）によって制御されており、特別に作成されたデータを送信することで、受信者に追加のメールを密輸するためのパーサーの違いを悪用することができるからです。元の投稿からのこの図解例を見てください：
この脆弱性を悪用するために、攻撃者はOutbound SMTPサーバーが1通のメールだと考えるデータを送信する必要がありますが、Inbound SMTPサーバーは複数のメールがあると考えます。
研究者たちは、異なるInboundサーバーがメールメッセージのデータの終わりとして異なる文字を考慮することを発見しましたが、Outboundサーバーはそうではありません。
例えば、データの通常の終わりは \r\n. です。しかし、Inbound SMTPサーバーが \n. もサポートしている場合、攻撃者はそのデータをメールに追加し、新しいメールを密輸するためのSMTPコマンドを指示し始めることができます。前の画像のように。
もちろん、これはOutbound SMTPサーバーがこのデータをメッセージデータの終わりとして扱わない場合にのみ機能します。そうでない場合、1通ではなく2通のメールとして認識されるため、最終的にはこの脆弱性で悪用されている非同期化が発生します。
潜在的な非同期化データ：
\n.
\n.
また、SPFが回避されることに注意してください。なぜなら、user@outlook.com から admin@outlook.com のメールを密輸すると、送信者は依然として outlook.com だからです。
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
