SMTP Smuggling
Last updated
Last updated
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：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だからです。
AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE) GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE)
