Cisco Secure Email GatewayのSMTP密輸の脆弱性レポートへの応答

はじめに

このドキュメントでは、SEC Consultによって2023年12月18日に発行された『SMTP Smuggling - Spoofing E-Mail Worldwide』で説明されているタイプの攻撃に対してCisco Secure Emailがどのように動作するかについて詳しく説明します。

SEC Consult Vulnerability Labと共同で行った研究プロジェクトの中で、Timo Longin(@timolongin)は、さらに別のインターネットプロトコルであるSMTP(Simple Mail Transfer Protocol)の新しいエクスプロイト技術を発見しました。脅威アクターは、世界中の脆弱なSMTPサーバを悪用して任意の電子メールアドレスから悪意のある電子メールを送信し、ターゲットを絞ったフィッシング攻撃を可能にする可能性があります。この脆弱性は、不正利用の性質上、SMTPの密輸と呼ばれていました。

シスコでは、このドキュメントで説明されている攻撃が、設定されたセキュリティフィルタをバイパスするために使用される可能性があるという証拠を見つけていません。

技術背景

SMTPプロトコルとメッセージ形式の詳細を取り上げることなく、コンテキストを取得するためにRFC 5322のいくつかのセクションを確認することが重要です。

セクション2.1では、メッセージの異なるセクション間で使用される区切り文字としてCRLF文字シーケンスを定義しています。

メッセージは文字の行に分割されます。行は、キャリッジリターンとラインフィードの2文字で区切られた一連の文字です。つまり、キャリッジリターン(CR)文字（ASCII値13）の直後に、ラインフィード(LF)文字（ASCII値10）が続きます。 （通常、このドキュメントでは、キャリッジリターン/ラインフィードのペアは「CRLF」と記述されます）。

セクション2.3では、メッセージ本文の形式について詳しく説明します。CRとLF文字が本体の一部として独立して送信されるべきではないことを明確に規定しています。このような設定を行っているサーバは、RFCに準拠していません。

メッセージの本文は、US-ASCII文字の行です。体に関する2つの制限は次のとおりです。

• CRおよびLFはCRLFとして同時に出現する必要があります。また、CRおよびLFが独立して体内に出現してはなりません。
• 本文の文字行は998文字に制限する必要があり、CRLFを除き78文字に制限する必要があります。

ただし、同じドキュメントのセクション4.1では、以前のリビジョンのRFCで採用されている古い構文のうち、それほど限定的ではない構文に言及して、フィールドでの多くの実装が正しい構文を使用していないことを認めています。

Bare CRとBare LFは、2つの異なる意味でメッセージに表示されます。多くの場合、行区切りを示すためにCRLFの代わりにベアCRまたはベアLFが不適切に使用されます。また、単にUS-ASCIIの制御文字としてベアコードCRとベアコードLFを使用し、従来のASCIIの意味を使用する場合もあります。

要約すると、RFC 5322によれば、適切な形式のSMTPメッセージは次の例のようになります。

ehlo sender.example\r\n
mail FROM:<user@sender.example>\r\n
rcpt TO:<user@receiver.example>\r\n
data\r\n
From: <user@sender.example>\r\n
To: <user@receiver.example>\r\n
Subject: Example\r\n
\r\n
lorem ipsum\r\n
\r\n. \r\n

この文書では、RFCのセクション4.1で説明されている例外を利用して、送信サーバまたは受信サーバのセキュリティ対策をバイパスするために、新しいメッセージを本文の一部として挿入または「密輸」することを試みます。目的は、セキュリティチェックをバイパスする密輸メッセージです。これらのチェックは、ベアラインフィードの前にメッセージの一部でのみ実行されるためです。例：

ehlo sender.example\r\n
mail FROM:<user@sender.example>\r\n
rcpt TO:<user@receiver.example>\r\n
data\r\n
From: <user@sender.example>\r\n
To: <user@receiver.example>\r\n
Subject: Example\r\n
\r\n
lorem ipsum\r\n
\n. \r\n
mail FROM:<malicious@malicious.example>\r\n
rcpt TO:<user@receiver.example>\r\n
data\r\n
From: <malicious@malicious.example>\r\n
To: <user@receiver.example>\r\n
Subject: Malicious\r\n
\r\n
Malicious content\r\n
\r\n. \r\n

Cisco Secure Mailの動作

Cisco Secure MailでSMTPリスナーを設定する際には、ベアCRおよびLF文字の処理方法を決定する3つの設定オプションがあります。

ベアCRおよびLF文字のクリーンメッセージ（デフォルト）

デフォルトのオプションが選択されている場合、Cisco Secure Mailは着信メッセージ内のすべてのCR文字とLF文字を正しいCRLFシーケンスに置き換えます。

例に示すような密輸コンテンツを含むメッセージは2つの個別のメッセージとして扱われ、すべてのセキュリティチェック(Sender Policy Framework(SPF)、ドメインベースのメッセージ認証、レポートと適合性(DMARC)、スパム対策、ウイルス対策、高度なマルウェア防御(AMP)、コンテンツフィルタなど)がそれぞれで独立して実行されます。

注：この設定では、攻撃者が別のユーザになりすましてメッセージを密輸できる可能性があることに注意してください。送信元サーバが複数のドメインをホストしている状況では、攻撃者がサーバでホストされている他のドメインの1つからユーザになりすまして密輸された電子メールのSPFチェックを通過させるため、攻撃者の影響が大きくなる可能性があります。

CR文字またはLF文字を含むメッセージの拒否

この設定オプションは、RFCへの準拠を厳密に強制します。CR文字またはLF文字が含まれていないメッセージは拒否されます

この設定では密輸のシナリオは防止されますが、RFCに準拠していないサーバからの正当な電子メールもドロップされます。

CR文字またはLF文字を含まないメッセージを許可する（非推奨）

最終的な設定により、Cisco Secure MailはCR文字とLF文字のベアをASCIIの意味で処理します。メッセージ本文は、密輸されたコンテンツを含め、現状のまま配信されます。

密輸されたメッセージは本体の一部として扱われるため、密輸されたメッセージの一部として含まれる添付ファイルがCisco Secure Mailで検出されない場合があります。これにより、ダウンストリームデバイスでセキュリティの問題が発生する可能性があります。このオプションは廃止されたため、使用しないでください。

推奨設定

シスコでは、デフォルトの「Clean messages of bare CR and LF characters」オプションを使用することを推奨しています。このオプションを使用すると、セキュリティと相互運用性の間で最適な妥協が可能になるためです。ただし、この設定を使用するお客様は、密輸コンテンツに関するセキュリティの影響を認識する必要があります。RFCへの準拠を求めるお客様は、相互運用性の問題の可能性を認識したうえで、「Reject messages with bare CR or LF characters」を選択する必要があります。

いずれの場合でも、着信メッセージの送信者を検証するために、SPF、DomainKeys Identified Mail(DKIM)、DMARCなどの機能を設定して使用することを強く推奨します。

よく寄せられる質問（FAQ）

Cisco Secure Mailは説明されている攻撃に対して脆弱ですか。
技術的には、はい。メールにCR文字やLF文字が含まれていると、メールの一部を2番目のメールとして扱うことができます。ただし、2番目の電子メールは独立して分析されるため、動作は2つの異なるメッセージを送信することと同じです。シスコでは、このドキュメントで説明されている攻撃が、設定されたセキュリティフィルタをバイパスするために使用される可能性があるという証拠を見つけていません。

バイパスされたSPFおよびDKIMチェックの例を示します。シスコはなぜフィルタがバイパスされていないと言うのですか。
これらの例では、SPFチェックは期待どおりに実行されますが、送信側サーバが複数のドメインを所有しているため、チェックに合格することになります。

推奨される設定は何ですか。
お客様にとって最も適切な選択は、お客様固有の要件に依存します。推奨されるオプションは、デフォルトの「クリーン」構成または「拒否」代替です。

Rejectオプションを選択すると、誤検出が発生しますか。
「拒否」機能は、電子メールがRFC標準に準拠しているかどうかの評価を開始します。電子メールがRFC標準に準拠していない場合、電子メールは拒否されます。正当な電子メールであっても、電子メールがRFC標準に準拠していない場合は拒否できます。

この問題をカバーするソフトウェアの不具合はありますか。
Cisco Bug ID CSCwh10142に記載されています。

このトピックに関する詳細情報を入手するには、どうすればよいですか。
フォローアップの質問は、Technical Assistance Center(TAC)のケースを通じて行うことができます。