## page was copied from DnsTemplate ##master-page:HelpTemplate <> <> [[/2]] https://sec--consult-com.translate.goog/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/?_x_tr_sl=en&_x_tr_tl=ja&_x_tr_hl=en&_x_tr_pto=wapp SMTP密輸? この研究の当初の目標は、HTTP などの他のプロトコルで機能するいくつかの一般的かつ特殊な攻撃に対して SMTP プロトコルをテストすることでした。多くの優秀な頭脳の貢献のおかげで、さまざまな*HTTP*攻撃から選択できるようになりました。ただし、SMTP のコンテキストでは、そのうちの 1 つがまさに要件に適合します。*HTTP リクエストの密輸*! ここで、*送信 SMTP サーバーと受信 SMTP サーバーがデータの終わりのシーケンス (.) を異なる解釈をした場合はどうなるでしょうか? * まさに、*SMTP密輸です！ * SMTP サーバーがメッセージデータの終わりについて異なる認識を持っている場合、攻撃者がメッセージデータを突破する可能性があります。さらに悪いことに、これにより、任意の SMTP コマンドを指定したり、個別の電子メールを送信したりすることが可能になる可能性があります (図 8 を参照)。送信 SMTP サーバーを分析するための SMTP 分析セットアップ図 9: アウトバウンド SMTP サーバーを分析するための SMTP 分析セットアップこれが SMTP 密輸の基本的な考え方です。しかし、実際に効果があるのでしょうか？ ---- *次に、これらのプロバイダーの送信 SMTP サーバー経由*で電子メールを送信し、*受信 SMTP 分析サーバー*で受信すると、これらの SMTP サーバーでの SMTP プロトコルの実装の違いが最初にわかります。 *SMTP 分析クライアント*を見ると、一部の SMTP 製品が他の製品とは「異なる」動作をしていることがすぐにわかります。たとえば、*DATA*SMTP コマンドを送信した後に電子メールプロバイダーから受信した応答の一部を次に示します。 - 250 でデータを終了します。 - 250 メール入力を開始します。.で終わる - 250 .で終わるデータを送信しますこれは、SMTP コマンドを密輸する計画にとっては好ましくありません。同じテキストを別の方法で記述したものではなく、SMTP の異なる解釈を探しているからです。右？しかし、メッセージが来たからといって手を引くつもりはありませんね。さらに分析した結果、一部の SMTP サーバーは次の応答を返しました。これはもう少し有望に見えます。 - メッセージを「.」で終わるメッセージを入力します。単独の行に - mail を入力し、「.」で終わります。単独の行にあるしかし、なぜその方が有望なのでしょうか? *まあ、オペレーティングシステムが異なれば、「行自体*」に対する理解も異なります。「。」*Windows では、単独の行は 2 つのキャリッジリターン改行 ( .*または*\r\n. \r\n*)で区切られますが、「.」は Linux では、単独の行は 2 つの改行 (. または \n.\n) で区切られます。そこで、メールのメッセージデータを*.で終わらせてみてはいかがでしょうか。*したがって、これは図 10 のようになります。 \n.\n をデータ終了シーケンス #2 として使用します図 11: データ終了シーケンス #2 として \n.\n を使用するここで、SMTP サーバーが . をデータの終わりのシーケンスとして考慮しない場合、実際の .< を待っているため、接続はハングしたままになります。 LF＞。したがって、図 11 に示すように、以下を追加します。 . シーケンスで電子メールを配信する送信電子メールプロバイダー (脆弱ではありません) 図 12: . シーケンスを持つ電子メールを配信する送信電子メールプロバイダー (脆弱ではありません) これにより、. が受信 SMTP サーバーによってデータの終わりシーケンスとしてサポートされるときは常に、「lorem ipsum」のみがメッセージデータの一部になります。それ以外の場合、メッセージには「このサーバーは行を無視しています」も含まれます。データの終わりのシーケンスとしてフィードします!」。しかし、これで実際に何が達成できるのでしょうか? さて、図 12 のように、 . がデータセクションを終了しない場合のメッセージ転送がどのようになるかを見てみましょう。 . シーケンスで電子メールを配信する送信電子メールプロバイダー (脆弱性) 図 13: . シーケンスで電子メールを配信する送信電子メールプロバイダー (脆弱性) しかし、受信 SMTP サーバーが . をデータの終わりのシーケンスとして解釈した場合はどうなるでしょうか? (図 13 を参照) Potential end-of-data sequence between START and END going through GMX's outbound SMTP server unchanged 図 14: GMX のアウトバウンド SMTP サーバーを変更せずに通過する START と END の間の潜在的なデータ終了シーケンスこの場合、「無害な」. がメッセージデータから抜け出し、「このサーバーはデータの終わりのシーケンスとして改行を無視しています。」*SMTP コマンド*として解釈されるようになりました。これには、受信サーバーが複数の SMTP コマンドをバッチで受け入れること (いわゆる SMTP パイプライン) が必要であることに注意してください。幸いなことに、現在ではほとんどのサーバーがこれをサポートしています。ただし、*送信 SMTP サーバーは*通常、このような「面倒な」 . シーケンスを別の方法で処理します。ただし、*送信 SMTP サーバーは*通常、このような「面倒な」 . シーケンスを別の方法で処理します。 * ドット詰め (単一のドットを別のドットでエスケープする): .. * に置き換えます。 * それをエンコードする (例: quote-printable 経由): =0A.=0A * シーケンス全体を削除する * メッセージを送信していないしかし、場合によっては、*まったく何もしないこともあります*。以下、未訳 == whois == {{{ }}} == history == {{{ }}} ---- CategoryDns CategoryWatch CategoryTemplate