大まかなパッチ: 200 OK になることを約束します (Citrix ADC CVE-2019-19781)

2019 年 12 月 17 日、Citrix はセキュリティ情報CTX267027をリリースし、Citrix Application Delivery Controller (ADC) および Citrix Gateway の脆弱性を特定しました。 CVE-2019-19781が割り当てられたこの脆弱性により、認証されていない攻撃者がディレクトリ トラバーサルを介して任意のリモート コードを実行できる可能性があります。この脆弱性のスコアは 9.8 で、重大と見なされました。 2020 年 1 月 8 日に、Tripwire は CVE の非常に詳細な説明を提供しました。

この背景に基づいて、多くの攻撃的なセキュリティ プロフェッショナルは、CVE-2019-19781 を兵器化する能力について説明しましたが、防御者にスキャナーを提供することを支持して、エクスプロイト コードを非公開にする計画を示しました。しかし、2020 年 1 月 10 日、FireEye は、この脆弱性の悪用を支援および自動化する概念実証 (PoC) コードを含むコード リポジトリが公開されていることを確認しました。専用ツーリング。その夜の時点で、FireEye ネットワーク アプライアンスのテレメトリは、Tor などのアノニマイザーとブラックリストに登録されている既知の IP アドレスから実行された、脆弱な Citrix インスタンスの偵察を示しました。他の組織も同様の傾向を示すハニーポット データを公開しています。その後まもなく、このエクスプロイトの武器化されたバージョンが、被害者の組織に足場を築くために使用されることを確認しました。図 1 は、この脆弱性が成熟するまでのタイムラインを示しています。

このブログ投稿の時点で、 Mandiant Incident Response チームは現在、この脆弱性が環境内での攻撃者の活動の最も初期の証拠であることを示す複数のインシデントに対応しています。当社のMandiant Managed Defense SOC も、この脆弱性を侵入経路とする侵入の試みを観測しています。私たちの検出は、主に脆弱なシステムを探すスキャンに集中しています。ただし、旅行、法律、金融、および教育の分野では、悪用の試みが繰り返し行われています。

この脆弱性に対する Citrix の緩和策を強くお勧めします。 Citrix は、2020 年 1 月 20 日以降、脆弱な製品のパッチ スケジュールもリリースしました。

また、脆弱なデバイスの可視性を再確認することをお勧めします。境界アプライアンスはネットワーク セキュリティ監視ツールの前に配置されることが多く、ネットワーク セキュリティ監視の有効性が制限されるためです。さらに、これらの攻撃が暗号化されたチャネルを介して行われる可能性があり、可視性がさらに制限されます。

技術や検出に頭を悩ませるな

残念ながら、多くのネットワークベースのエクスプロイトは、暗号化されたチャネルなどの利点を享受しており、ネットワーク セキュリティの監視を妨げる可能性があります。ただし、トラフィックが暗号化されていない場合、Snort などの検出エンジンは非常に貴重なリソースであることがわかります。検出を可能な限り徹底するために、エクスプロイトの試みを探すために公開されている検出ルールから始めました。ディレクトリ トラバーサルやよく悪用される Perl スクリプトへのアクセスなど、POST の悪用例は次のようになります。

POST /vpn/../vpns/portal/scripts/newbm.pl

最初に分析したルールの多くは、次の 2 つの要素に依存していました。

• エクスプロイト試行の特定の URI (/vpns/)
• ディレクトリトラバーサル (「/…/」)

ロジックのこれら 2 つの部分を分割して、ルールをまとめてみましょう。

最初のルールは、負の距離を持つ Snort の距離演算子を使用して、トラバーサル バックスラッシュが重複する可能性があることを示しますが、重複しない可能性もあります (この機能を持たないレガシー環境では、http_uri 後処理も使用していないことに気付くかもしれません)。

自分たちの検出を回避することに常に興味を持っていた私たちは、ラボでセットアップをいじり始めました。まず、インスタンスが脆弱であることを GET リクエストで確認しましょう。

一部のセキュリティ研究者は、HTTP の HEAD メソッドに基づくスキャナーを投稿していることに注意してください。これにより、機密情報の漏洩が回避されます (そして、テストに必要な帯域幅の量が制限されます!)。この方法には、 Robert (@x1sec)のcitrixmash_scannerをお勧めします。

公開ルールセットの多くが /vpns/ で大文字と小文字を区別していることに早くから気付きました。つまり、Snort の nocase 演算子は存在しません。したがって、この攻撃が大文字と小文字を区別するかどうかを判断する必要がありました (これは、ディレクトリ トラバーサルによるものであると仮定しました)。

確かに、大文字と小文字の区別は重要です。

次のテストでは、基本的な ASCII テキストを拡張しました。つまり、リクエストの一部を、検出ロジックを回避する文字エンコーディングに変換できますか?これにより、公開されたルールを回避できる可能性があります。さらに、2020 年 1 月 12 日に、攻撃者が実際に URL エンコードされた文字を利用して被害者の環境にマルウェアを展開していることを確認しました。次の要求は、環境への最初の要求でした。

続いて (2 つのディレクトリのトラバーサルに注意してください):

このアクティビティに触発されてさらにテストを行った結果、トラバーサルとリソース アクセスの両方をエンコードされた文字に置き換えることができることが示されました。

この時点で、これらの順列を考慮して Snort ルールを構築する方法を検討し始めました。多くの場合、検出シグネチャに組み込むロジックが増えるほど、検出の計算コストが高くなります。さらに、多くの攻撃者は、厳格すぎる検出を回避することに長けています。幸いなことに、Citrix はすでにこの方法で私たちを助けてくれています。

Citrix の軽減策を実装しましたが、バイパス技術が機能しないことに気付きました。そのため、緩和手法をさらに検討しました。次の軽減コマンドは、脆弱なデバイスで入力することを意図しており、現在のエクスプロイトを軽減するためのおそらく最も重要な手順が含まれています。

これらの緩和手順で参照される DECODE_USING_TEXT_MODE 関数の詳細については、 Citrix の高度なポリシー式リファレンス を参照してください。

きちんとした！ Citrix のこの小さな機能により、文字の難読化が軽減策を回避し、おそらく最初の検出を回避しているという心配が減りました。

パケット アップ、パケット イン: Snort ルール セクション

このセクションでは、悪用の試みの範囲がすべての難読化および置換方法をカバーするわけではないため、より回復力のあるルールに関するいくつかの考慮事項を検討します。最初に起動する他のルールに依存するルールに対処する適切な方法は、フロービットを使用することです。たとえば、悪用を試みた場合は、次のように設定します。

フロー:確立された、to_server;フロービット: cve201919781を設定します。

その後、成功したエクスプロイト応答を探すなどのフォローアップ ルールで flowbit を使用できます。

フロー:確立された、to_server;フロービット: isset ,cve201919781;

組織がスキャンで非難されている場合は、ルールを変更して、スキャンの試行で flowbits:noalert を利用し、悪用の成功に基づいてアラートのみを表示することができます。この脆弱性に対してこの方法をさらに一歩進めるために、これまでに観察された脅威アクターの悪用手法を想定すると、noalert を使用して .xml ファイルのフォローアップ GET/HEAD/OPTION メソッドの 2 番目のフロービットを連鎖させることができます。ただし、この手法は依然として、最初のルール ロジックでエクスプロイトの試みをキャプチャすることに依存しており、エンコードまたは難読化が使用されている場合、上記で示したように困難になる可能性があります。幸いなことに、このエクスプロイトでは、脆弱なサーバーの応答は一意であり、フロービットを設定する必要がなく、応答を確認できます。

これらすべての要素が整ったら、次の予備ルールに到達します。

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:”潜在的な CVE-2019-19781 脆弱な .CONF 応答”; flow: Established,to_client; content:”HTTP/1.”; depth:7; content:”200 OK “; 距離:1; コンテンツ:”|0d0a|サーバー: Apache”; 距離:0; コンテンツ:”al]|0d0a|”; 距離:0; コンテンツ:”パスワードの暗号化”; 距離:0; コンテンツ:”名前注文を解決する”; 参照:cve,2019-19781; 参照:url,https://www.fireeye.com/blog/products-and-services/2020/01/rough-patch-promise-it-will-be- 200-ok.html; sid:201919781; rev:1;)

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:”潜在的な CVE-2019-19781 脆弱な .PL 応答”; flow: Established,to_client; content:”HTTP/1.”; depth:7;
content:”200 OK”;距離:1; content:”|0d0a|サーバー: Apache”;距離:0; content:”|0d0a|接続: Keep-Alive”;コンテンツ:”|0d0a0d0a3c48544d4c3e0a3c424f44593e0a3c534352495054206c616e67756167653d6
a61766173637269707420747970653d746578742f6a6176617363726970743e0a2f2f706172656e74
2e77696e646f772e6e735f72656c6f616428293b0a77696e646f772e636c6f736528293b0a3c2f534
3524950543e0a3c2f424f44593e0a3c2f48544d4c3e0a|”; 参照:cve,2019-19781; 参照:url,https://www.fireeye.com/blog/products-and-services/2020/01/rough-patch-promise-it-will-be- 200-ok.html; sid:201919781; rev:1;)

最初の署名が citrixmash_scanner で使用される応答サイズ メソッドと類似していることに注意してください。

検出ルールを記述することは、防御側が既知のものから防御するために習得できる最も重要なスキルの 1 つです。残念ながら、厳格すぎる検出ルールはバイパスの可能性を簡単に提供してしまいますが、あいまいな検出ルールは誤検知に溺れてしまいます。検出を記述するときは、分析するのと同じ順序でデータを構造化する方法を探すことをお勧めします。上記のフロービットとコンテンツ文字列で行ったことなど。実際、悪用を成功させるための他の創造的なルールを見たいと思っています。なぜなら、私たちのルールがテスト済みの環境に固有のものである可能性があることを認識しており、ネットワークセンサーフリートから独自のルールに関するデータをまだ収集しているからです.

これを支援するために、このブログ投稿で次の PCAP を共有しています。

• 200 OK 応答の .conf ファイルをチェックするための GET 要求
• 公開されているツールを使用して脆弱性を悪用する POST リクエスト

この脆弱性に関する情報が公開されたら、調査結果を引き続き観察し、文書化します。多くのセキュリティ研究者が同じことを行っており、そのほとんどは、この脆弱性の武器化や悪用から防御しようとしています。実際、この投稿を書いているときに、Twitter ユーザー「mpgn」は、悪用される可能性のある他の Perl スクリプトに加えて、ディレクトリトラバーサルは必要ない可能性があることを確認しました。

鼻を鳴らさず、手がかりもありません—問題ありません！

侵害後のアクティビティといくつかの調査のヒントについての洞察を提供する時が来ました。

このエクスプロイトが環境に対して使用された疑いがあり、ネットワーク セキュリティの監視が実施されていない場合は、このエクスプロイトに関連する主要なアーティファクトを保存するためにフォレンジック手順を実行する必要があります。 NetScaler デバイスに組み込まれている Web サーバーは Apache であり、フォレンジック分析中に利用できる最小限のログ記録を提供します。

進行中の Mandiant IR 調査中に、次の簡単な grep 検索を開発して、/var/log/httpaccess.log にある被害者サーバーの HTTP アクセス ログ内のエクスプロイト アーティファクトを特定できるようにしました。

これらの grep 検索は、この脆弱性に対する最近の変更の一部も捕捉します。たとえば、悪用のために追加の Perl スクリプトに依存するものや、初期アクセスのために XML ファイルをドロップするものなどです。

Mandiant のインシデント レスポンダーは、複数のクライアントで観察された CVE-2019-19781 を悪用する少なくとも 1 つのグループからの最初の悪用後の一部として、持続性が crontab に追加されたことを指摘しています。

cron ジョブは、侵害された可能性のある WordPress インスタンスにホストされている悪意のあるペイロードを永続的にダウンロードし、httpd としてディスクに保存する方法を提供します。 Mandiant チーム以外の個人も、インシデント対応中に同様の活動に気付いています。

この特定の日和見主義者の攻撃者は、nsconfig をダミーのネットスケーラー テンプレート ファイルに追加して盗み出すことも確認されています。

そして、おそらく自動化されたスクリプトを使用して、侵害後の活動のいくつかの証拠をクリーンアップします。

cron ジョブに加えて、システム トリアージ中にキャプチャするその他の貴重なライブ レスポンス データには、実行中のプロセス (ユーザー nobody によって開始されたプロセスに注意してください)、攻撃者のコマンド (bash.log など) をキャプチャするアーティファクトへの焦点、およびドロップされた追加のファイルが含まれます。ポストエクスプロイト中。 TrustedSec (別名UNC1194 ) で私たちの友人が提供した最初のフォレンジック アーティファクトの調査と、x1sec のCVE-2019-19781 DFIR ノートを読むことを強くお勧めします。ノイズがあると、攻撃者はそのノイズの中に隠れます。私たちの主な懸念は、より高度な攻撃者がこの脆弱性を悪用して影響力のある侵入操作を実行する可能性があることです。そのため、徹底的な分析を実施し、必要に応じて追加の専門知識を求めることをお勧めします。

謝辞

最も初期の検出カバレッジを作成してくれたRick Coleと、このブログ投稿に情報を提供してくれた Mandiant インシデント対応者のチーム (特にAustin Baker 、 Brandan Schondorfer 、John Prieto)、およびクライアント環境に対応または保護しているすべてのコンサルタントに感謝します。この脆弱性から。また、脆弱性インテリジェンス チームのNicholas Luedtke 氏には、このブログ投稿の開示とツールのタイムラインの改善に協力していただき、感謝しています。

また、TrustedSec の人々にも特別な感謝の意を表したいと思います。彼らは、役立つスキャナを共有し、その後、互いに数分以内にエクスプロイトと検出技術の両方を共有しました!

CVE-2019-19781 に取り組んでいるすべての防御者の幸運を祈ります。私たちは喜びと悲しみ、Citrix と健康の最前線であなたと一緒にいることを約束します。

バックドアを維持しながら CVE-2019-19781 エクスプロイトの試みをブロックしているアクターに関するフォローアップ ブログ投稿を確認してください。これに関するオンデマンドの要約と、今年のマネージド ディフェンス攻撃トップ 5をご覧ください。