テクニカル分析Barracuda Email Security Gateway

2023年11月7日
クエンティン・オラーニュ
独立系セキュリティリサーチャー
テクニカル分析Barracuda Email Security Gateway

2023年5月23日、バラクーダは、同社のメールセキュリティゲートウェイアプライアンスに脆弱性(CVE-2023-2868)があり、2022年10月の時点で悪用されていたことを発表しました。2023年6月15日、Mandiantは、CVE-2023-2868を積極的に悪用していたキャンペーンに関与していた活動および脅威アクターの詳細な分析を発表しました。その後、Proofpoint の Emerging Threats チームは、報告された脆弱性の悪用の試みを検出するための Suricata 検出ルール(SID 2046280)をリリースしました。 Vectra AI クライアントとのミーティング中に、既存のルールが期待通りに機能していないのではないかという懸念が提起されました。初期テストを実施した結果、このルールは、エクスプロイトのペイロードの配信に成功したにもかかわらず、特定の概念実証のエクスプロイトに関するアラートに失敗することがわかりました。  

私たちは、このルールと関連するエクスプロイトを分析し、エクスプロイトのペイロード内のエクスプロイトに関連するコンテンツの順序が非決定的であることが原因となっている特定の検出ギャップを特定しました(詳細については、以下の「概念実証のエクスプロイトを簡単に見てみる」のセクションで説明します)。ギャップを特定したことで、必要な検出カバレッジを提供するルールを書き換えることができました。ProofpointのEmergingThreatsチームに調査結果を提出したところ、新しいM2検出ルールがリリースされました。このレポートでは、確認された偽陰性を排除したM2検出ルールに使用された分析とルール作成プロセスについて説明します。 

TL;DR

Proofpoint社のETルールは、ルールに従わない人であっても、誰もがルールに従うという前提が組み込まれているため、欠陥があります。今回の分析では、操作された TAR アーカイブに遭遇し、ペイロードが CVE-2023-2868 に対する ET の検出ルールをすり抜けてしまいました。そして、改善された検出ルールが導入されたとしても、懸念は残ります:明日、別の操作されたファイル構造に遭遇した場合、ETの検出ルールを再び迂回する可能性はあるのでしょうか?

1.CVE-2023-2868の構造

Mandiantのレポートには脆弱性の説明が記載されていますが、便宜上、以下の図にまとめました。ご覧のとおり、Barracuda Email SecurityApplianceの特定のバージョンには、インジェクションの脆弱性があります。

この悪意のあるペイロードを特定するために、Emerging Threats Research Team は、特定のパケットタイプにおける「'`」(シングルクォート、バックティック)と「`'」(バックティック、シングルクォート)を検索する検出ルームを開発しました。(バックティック、シングルクォート)を特定のパケットタイプで検索する検出室を開発した。後述するように、彼らのルール構築方法によって、いくつかの Proof of Concepts は検出されないままになっていました。

2.概念実証のエクスプロイトを簡単に見る

ここで入手可能な概念実証脆弱性(PoC)エクスプロイトに注目し、どのような基本的なペイロードが使用され、Emerging Threats検出ルールをトリガーすべきかを特定し始めました。以下に示すように、"CMD" 変数は、Mandiantのレポートで説明されたのと同じ基本的なコマンド構造を使用しています。

変数 "PAYLOAD "はシングルクォートとバックティックで始まり、変数 "CMD "はバックティックとシングルクォートで終わることに注意してください。これがコマンド・インジェクションのトリガーとなる。

六角形のワイヤーでPoCを見る

ここに、上に示したペイロードを含む生成されたtarアーカイブの16進数表現の出力がある:

インジェクション・パターンである "PAYLOAD "は赤くハイライトされている。CMD "変数に割り当てられたコマンド文字列は青くハイライトされている。]

アーカイブの一番上に、CMD変数が残っていることと、インジェクション・パターン(back tick, single quote)があることを観察する。この重要な部分には後で戻る。

通常のTarアーカイブ構造

検出ルールの欠陥に飛び込む前に、通常のtarアーカイブの構造を理解することが重要である。tarアーカイブは512バイトのブロックに編成されている。基本的に、tarアーカイブの形式は次のとおりである:

  • 「ヘッダー "には、ファイル名といくつかの追加メタデータが含まれる。
  • 「コンテンツ」には、ファイル内の実際のデータが含まれる。

通常のタール・アーカイブを16進数で覗く

通常の」tarアーカイブとみなされるものは、UNIXシステムのTARフォーマット、またはPOSIX 1003.1標準によって定義されたUSTARフォーマットのどちらかを尊重し、ルールに従っているユーティリティによって作成されたファイルです。これは、1、2、3という名前の3つの通常のファイルを含む通常のtarアーカイブをtarユーティリティで16進ダンプしたものです:

1という名前のファイルがあり、その後にいくつかのバイトコードが続き、「hello 1」というファイル・コンテンツがあり、その後に2という名前のファイルが続く、といった具合である。明らかに、tarアーカイブ作成ユーティリティは、ファイル名に基づいてヘッダーとコンテンツのデータを降順に配置します。言い換えれば、ファイル・フォーマット標準によって規定された規則に留意し、それを尊重しているのである。

注意すべき点は、ファイル構造が、エクスプロイトによって生成され、最初のセクションで紹介したものとは異なることです。PoCエクスプロイトには、予想されるファイル名の代わりに、ヘッダーに一連のコマンドが含まれています。これを可能にするために、エクスプロイト作成者は少し狡猾になる必要がありました。

R7エクスプロイトの解剖

Rapid7セキュリティ・リサーチャー・チームによって書かれたエクスプロイトには、Rubyの "TarWriter "クラスにコメント付きの専用部分がある:

この悪用は"split_name() "関数が本来行うファイル名のサイズチェックを上書きする:

元の関数から3つの "if "文が削除された。これらの3つの文は、ifを検証するために "TooLongFileName "を発生させる:

1.ファイルパスが長すぎる。

2.ファイル名が長すぎる。

3.ファイルのベースパスが長すぎる。

エクスプロイトのペイロードを見て、文字を数えると129バイトになる:

PoCのコードに基づくと、実行するコマンドが100バイトを超える場合、コマンドはtarアーカイブ内の複数の「ファイル・エントリ」に分割される。ファイル・エントリ」を二重引用符で囲んだのは、悪意のあるtarアーカイブには実際にはファイルが含まれておらず、エスケープシーケンスと攻撃者が実行したい埋め込みコマンドが含まれているからです。

悪意のあるtarアーカイブのhexdumpを再確認すると、なぜtarアーカイブの最初のエントリーが、コマンドの最後に来るはずの`'(バックティック、シングルクォート)とCMD変数の最後がぶら下がっているのかが理解できる。

このコマンドはファイル名の構造上、ファイルのヘッダーに課せられる100バイトの 制限を超えているため、コマンドは2つのファイルエントリーに分割され、2つ目の ファイルエントリーは末尾のp"`'(p文字、ダブルクォート、バックティック、シング ルクォート)だけを含む。これは、tarアーカイブの内容が降順でソートされ、降順でソートされたときにp"`'(p文字、ダブルクォート、バックティック、シングルクォート)文字列が'`s(シングルクォート、バックティック、文字s)文字列の前に来るためである:

tarアーカイブ内の順序は一貫していますが、エクスプロイトのペイロードのエスケープシーケンスとコマンドコンテンツの順序は、ペイロードに埋め込まれたコマンドで使用される文字の長さと組み合わせによって異なるため、検出ルールの観点からは非決定的です。

3.検出ルールのハイレベルな説明:

脆弱性、それを悪用するために必要なこと、そして悪用の中でどのようなパターンを判別する必要があるかについて理解を深めたところで、emerging-exploit.rulesファイルの検出ルールに目を向けた:

簡単に説明すると、このルールは3つのパターンを探す:

1.SMTP_SERVERSマッピングに含まれるSMTPサーバを宛先とする、どこからでも来るSMTPパケット。デフォルトでは、SURICATAは$SMTP_SERVERSを$HOME_NETにマッピングするので、内部SMTPサーバはすべてルールの対象になることに注意してください。

a.有効なtarアーカイブの添付ファイルが含まれている。添付ファイルはTARアーカイブのファイルマジック番号と一致していなければならない。

b.その中には、"|27 60|"と"|60 27|"という2つのパターンが含まれている。

検索されるキーワードは、以下のASCII文字の16進数表現である。(バックティック、シングルクォート)。文字"'`"(シングルクオート、バックティック)は、先に説明したように、コマンド実行のトリガーとして使用される。以下は、検出ルールが探している3つのパターンを強調表示したエクスプロイトの16進数表現です:

ルールを振り返ってみると、「distance(距離)」と「within(範囲内)」というパラメータもあり、これらをペアにしてルールを微調整することができる。パラメータは以下のように使用する:

  • Distance(距離):カーソルを分析開始地点に合わせる。
  • 距離:0は、パターンが前のマッチの+0バイト後のどこにでもあることを意味する。だから、上の例では˶x27˶x60のすぐ後。
  • Within:最後の試合からどの程度先までルールが必要かを制限する。
  • 以内:500は、コンテンツが500バイト以内のペイロードと一致した場合のみ一致することを意味する。

withinとdistanceのパラメーターはSURICATAのドキュメントで説明されている。

4.オリジナル・ルールとわれわれの悪用で観察された欠陥

百聞は一見にしかず」という格言があるように、Rapid7のエクスプロイトに対する検出ルールの動作を以下のダンプで紹介する:

このルールの一部である:

上のダンプは、なぜ検出ルールが発動しないかを簡単に示している。このサンプルでは、アーカイブの先頭に配置されているため、他のパターンを見つけることはできない。

5.この未検出のエクスプロイトに対する変形M2検出ルール

上記の調査結果を踏まえ、Proofpoint の Emerging Threats チームは 9 月 29 日、新たな検出ルール M2 のリビジョン 2 を SID 2048146 として発表しました:

以下は、以前と同じtarアーカイブのエクスプロイトの同じ16進数表現を使用した、M2検出ルールのチェック内容の概略である:

6.決議

プルーフポイント社のオリジナルのETルール(SID 2046280)の明らかな欠点を考慮すると、固定的なルールや標準だけに頼るのは、進化し続けるサイバーセキュリティの世界では限界があることが明らかになる。マッカーサー元帥の不朽の名言「ルールは大抵破られるために作られる」は、悪意のある行為者は、硬直したルール・セットも含め、あらゆる脆弱性を悪用するということを痛感させる。

この分析を通じて、我々は、ペイロードがCVE-2023-2868に対するETの最初の検知をすり抜けることを可能にしたTARアーカイブ構造の操作を通じて、このアプローチの限界の典型的な例を目撃しました。この出来事は、より適応性が高く、動的なセキュリティ戦略を採用することの緊急性を強調しています。

明日を見据えるとき、硬直的なセキュリティから脱却し、より全体的でプロアクティブなセキュリティのパラダイムを受け入れることが不可欠である。また新たなルール違反が発生する可能性を考えるだけでなく、検知と防御のメカニズムを常に進化させることで、サイバーセキュリティ対策の強化に積極的に取り組むべきである。固定されたルールの限界を認識することで、サイバー脅威が絶えず進化する不確実な未来によりよく備えることができる。そうすることで、セキュリティポスチャを強化し、ルールの迂回を執拗に試みる悪意のあるアクターからよりよく守ることができる。ルールベースのテクノロジーだけに依存しない戦略を採用することは、Defense-in-Depthの多層的なアプローチに合致するだけでなく、ゼロトラスト・モデルを含む現在最も効果的な戦略を取り入れることを読者に促している。

即座に実行可能な勧告を提供するために、我々は以下の指針を提示する:

emerging-all.rulesファイルを使用し、ルールセットのアップデートを自動管理しているSURICATAのデプロイメントでは、アップデータが9/29/23以降に実行されたと仮定すると、改訂された検出ルールはすでに配置されているはずです。現在適用されているルールセットに改訂された検知ルールが含まれていることを確認するには、ローカルのルールセットファイルで「2048146」を検索します。現在適用されているルールセットのいずれにも SID 2048146 が存在しない場合は、ルールセットを Emerging Threats から入手可能な最新のソースに更新してください。

タイムライン

  • 9/19/23: ETポータルを通じて調査結果を提出。提出を認める返事はない。
  • 9/21/23:support@emergingthreats.netに電子メールを送信し、投稿を記録し、Emerging Threat チームに Google の責任ある情報公開ポリシーに従うことを伝えた。
  • 9/21/23:ETセキュリティ・リサーチャーから返信があり、本日午後7時(米国東部時間)に日刊の一部としてM2バージョンの検知ルールを公開することに同意した。
  • 9/21/23: 新たに公開されたM2亜種検出ルールがR7エクスプロイトに対するアラートをトリガーしないことに気づきました。
  • 9/21/23: 新たにリリースされたM2検出ルールでエクスプロイトのペイロードが検知 、失敗したことについてET Securityのリサーチャーにメール。
  • 9/29/23: 午後7時(米国東部時間)にリリースされたM2亜種ルールのリビジョン2は、R7エクスプロイトペイロードの検出に成功しました。

参考までに

スリカータのドキュメント https://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords

html#withinhttps://docs.suricata.io/en/suricata-6.0.1/rules/payload-keywords.html#distance

Github POC エクスプロイト https://github.com/cfielding-r7/poc-cve-2023-2868/blob/main/poc_cve_2023_2868.rb

エクスプロイトの説明https://www.mandiant.com/resources/blog/barracuda-esg-exploited-globally

https://www.ic3.gov/Media/News/2023/230823.pdfhttps://www.barracuda.com/company/legal/esg-vulnerability

ETルール http://rules.emergingthreats.net/open/suricata-5.0/emerging-all.rules

よくあるご質問(FAQ)