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