アップデート 1-22-2020
現在、FireEyeが提供するツールがあり、以下の項目のスキャンに役立ちます。重要なのは、エクスプロイトが実行された後の行動を確認するために、2020年1月9日まで遡れる十分なログが必要であるということです。.XMLペイロードファイルが見つかった場合は、以下の情報を使用して対処方法を決定する必要があります。
https://www.fireeye.com/blog/products-and-services/2020/01/fireeye-and-citrix-tool-scans-for-iocs-related-to-vulnerability.html
ツールダウンロード
https://github.com/citrix/ioc-scanner-CVE-2019-19781
https://github.com/fireeye/ioc-scanner-CVE-2019-19781/
エクスプロイトの検出
現時点では、誰かが何をしたかを証明する簡単な方法はありません。4つの公開エクスプロイトはそれぞれ異なる痕跡\シグネチャを残すため、検出に役立ちますが、100%完全ではありません。覚えておくべき重要点は、これらは10日まで非公開だった公開エクスプロイトであり、それ以外にも、個人的な利益のために共有されていないものが世の中に存在する可能性があるということです。エクスプロイトはほとんどの場合編集可能であり、ドロップされるファイル名、ユーザーアカウント名、プロセス名、クエリのパス、その他多くのオプションを変更できるため、システムがエクスプロイトされている可能性は指数関数的に増大します。上級の攻撃者と初歩的な攻撃者の両方が存在します。上級の攻撃者は痕跡を消し、検知を逃れるために巧妙にシステム内に潜伏する方法を編み出します。
Nessusを実行している場合、以下の.YARファイルを使用して、一般的な検出方法を探す特権スキャンを実行できます。
https://github.com/Neo23x0/signature-base/blob/master/yara/exploit_shitrix.yar
エクスプロイト監査
この監査プロセスに関する優れたリンク。
https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/amp/
http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781/
免責事項: 前述のとおり、これはすべてのエクスプロイトを検出するわけではありませんが、攻撃者が公開エクスプロイトを変更しておらず、かつ/または痕跡を消していない場合に、いくつかの異常を検出するのに役立つ可能性があります。ほとんどの攻撃者はデフォルトのエクスプロイトを使用します。以下は、残される可能性がある文書化されたアーティファクトの一部です。このコマンドリストは多くのソースから収集されたものであり、他の亜種、回避策、新たな動向が出現するにつれて非常に流動的になります。感染が増え、より大きなサンプルセットでさらなるフォレンジックが完了するにつれて、これは常に変化すると考えてください。
まず、自分が行っていない操作を確認してください。通常ADCであまり操作を行わないのであれば、これらのログは非常に静かであるはずです。ただし、最後に操作した数週間前、数か月前、あるいは数年前のエントリが存在する可能性もあります。すぐ下に、より正確なクエリがあります。また、このブログ自体がいたちごっこであることを理解してください。私たちが目撃した内容や攻撃者を見つける方法を公開すると、彼らは検出を避けるために戦術を変えて、この情報を私たちに対して利用します。
エクスプロイトチェック クイックチェックリスト v1
-
- ライセンスを確認してください。デバイスを再起動したところ、実際にはライセンスが失効していたという話を聞いたことがあります。
-
- サポートファイルを取得してください。別名バックアップ: システム -> 診断 -> サポートファイルの取得で、そのファイルを保存します。
-
- 以下のすべてのコマンドはNSCLI内にあります。SSHでボックスに接続してShellを使用する場合は、Shellプレフィックスを省略できます。
-
- デバイスの日付を確認して、ログの調査結果を関連付けるのに役立ててください
-
- 設定変更日を確認してください
- a. Shell ls -l /netscaler/ | grep netscaler
- b. Shell ls -l /nsconfig | grep netscaler
- i. netscaler.confの日付はいつですか?
- ii. それは正しいように見えますか? 他の場所へのファイルリンクを確認してください。
-
- ローカルアカウントのパスワードファイルを確認してください
- a. Shell ls -lh /etc/passwd
- i. ファイルがいつ変更されたかを確認してください。エクスプロイト後で、自分が変更していないのであれば、できるだけ早くそのパスワードを変更する必要があります。
- ii. エクスプロイトが検出された場合は、nsrootまたは任意のローカルアカウントのパスワードを変更することをお勧めします。多くの場合
- b. Shell cat /etc/passwd
- i. どのアカウントがそこにあるか確認してください。
- ii. Root、nsroot、daemon、operator、bin、nobody、sshd、nsmonitorがデフォルトです。
-
- ログを確認してください
- a. shell ls -lh /var/logfile
-
- 不正ファイルのチェック
- a. これらのファイルのいずれかが8〜9文字以外でランダムなファイル名の場合、それは標準エクスプロイトを変更したより高度な攻撃者の兆候です。これが見つかった場合は、それに応じて修復手段を調整する必要があります。Pwnpzi1337.xmlはProject Indiaエクスプロイトのファイル名です。
- b. shell ls /netscaler/portal/templates/*.xml
- i. ここにはXMLファイルがないはずです。
- ii. 感染している場合は、ここのファイルの日付を確認してください。
- iii.shell ls -lh /netscaler/portal/templates/
- c. shell ls /var/tmp/netscaler/portal/templates
- i. このディレクトリは存在しないはずです。
- ii. 感染している場合は、ここのファイルの日付を確認してください。
- iii.shell ls -lh /var/tmp/netscaler/portal/templates
- d. shell ls /var/vpn/bookmark/*.xml
- i. 通常は存在しませんが、そこにもXMLファイルがあるべきではありません。
- ii. 感染している場合は、ここのファイルの日付を確認してください。
- iii.shell ls -lh /var/vpn/bookmark/
- e. shell ls /tmp/.init
-
- Cronジョブ(永続化手法)
- a. shell cat /etc/crontab
- b. shell crontab -l -u nobody
-
- 暗号通貨チェック
- a. shell top -n 10
- i. NSPPE-xx(パケットエンジン)は100%またはそれに近い値である必要があります。別のプロセスが存在する場合、マイニングされている可能性があります。
-
- PCAP
- a. Shell find / -name “*.cap”
- b. 取得された可能性のある紛失したキャプチャファイルを見つけるのに役立ちます。
- c. これは、スニッフィングを行った可能性のあるより高度な攻撃者の兆候です。
-
- シェルログ
- a. shell cat /var/log/bash.log | grep nobody
- i. nobodyユーザーからのユーザーアクセスを探します。
- b. shell gzcat /var/log/bash.*.gz | grep nobody
- i. 圧縮されたログ内のnobodyユーザーからのユーザーアクセスを探します。
-
- Apacheログの確認
- a. shell "cat /var/log/httperror.log | grep -B2 -A5 Traceback"
- b. shell "gzcat /var/log/httperror.log.*.gz | grep -B2 -A5 Traceback”
- c. shell grep -iE 'POST.*.pl HTTP/1.1" 200 ' /var/log/httpaccess.log -A 1
- d. shell grep -iE 'POST.*.pl HTTP/1.1" 200 143' /var/log/httpaccess.log -A 1
- e. shell grep -iE 'GET.*.xml HTTP/1.1" 200' /var/log/httpaccess.log -B 1
- f. shell grep -i '.pl HTTP/1.1" 200 143' /var/log/httpaccess.log | grep POST
- i. これらはすべて、.plファイルと.xmlファイルのシステム内外への移動に関する特定の項目を探しています。
- g. shell cat /var/log/httperror.log
- i. これはファイルの生の内容を全体的に確認しており、他に目立つ項目を探すためのものです。
-
- 永続化スクリプト
- a. shell ps -aux | grep python
- b. shell ps -aux | grep perl
- c. shell ps -auxd | grep nobody
-
- パスワード\アカウントの確認
- a. shell ls -l /etc/passwd
- i. 最近何かが追加されている場合は、ファイルの日付も確認してください。
- b. shell cat /etc/passwd
- i. 疑わしいもの、ローカルアカウントはありますか?
-
- TCP接続を確認してください
- a. Shell netstat -natu
- b. VLAN内の非ローカルIPアドレスを探してください。別のボックスが侵害された場合に備えて、内部IPも確認する必要があります。
-
- 認証プロファイルを確認してください
- a. TLSまたはSSLに設定されていたのに、現在は平文(PlainText)になっていませんか?
- i. 一部の監査やオンラインで変更されたケースを見たことがあります。
- ii. これも上級攻撃者の兆候です。
- b. これは、設定ファイルns.confが変更されたかどうかに関係します。幸いなことに変更されていない場合があります。
- c. 以前に平文だった場合は、エクスプロイトの兆候が見つかるかどうかに関係なく、できるだけ早くTLSとSSLに設定する作業を行う必要があります。
-
- 証明書を確認してください
- a. これらはSSL証明書であり、特にボックスがエクスプロイトされている場合は、再キー生成を検討する必要があります。
- b. エクスプロイトの兆候が少しでもあれば、SSL証明書を再キー生成することをお勧めします。大規模な展開では、証明書がバインドされている他の場所の数や、SSL証明書の変更によって発生する可能性のある停止\混乱のために、より困難な道のりになる可能性があります。
- c. エクスプロイトを実行する以外に何もしておらず、システム設定にピボットしなかったことを証明できる優れたログを持っていたため、再キー生成をしなかったクライアントを見たことがあります。ほとんどのクライアントは、わずか数日分の
-
- 潜在的なTier 1ターゲットについて設定ファイルを確認してください
- a. ns.confを表示すると、Tier 1ターゲットリストが作成されます。デバイスがエクスプロイトされた場合、そのリストが最初にアクセスされた可能性が最も高いです。
エクスプロイトされた場合
あなたの脅威環境に基づいて必要な対応は常に異なります。ここでは、エクスプロイトが実行された証拠を見つけた顧客に私が伝えてきたいくつかの考えを紹介します。
あなたのビジネスを対象とするコンプライアンス機関は何ですか? 金融\銀行、SOX、PCI、HIPPA、州\地方自治体および政府の法律。
これらのフレームワークのいずれかに該当する場合は、それらのコンプライアンス機関の手順に従う必要があります。また、インシデント対応と開示に関する規定がある認定や専門団体に所属している場合の倫理的考慮事項もあります。
以下は、よく知られた2つのインシデント対応プロセスガイドへのリンクです。
https://security.berkeley.edu/incident-response-planning-guideline
https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
これまでにわかっていることの1つは、2020年1月10日頃に最初の公開エクスプロイトがリリースされ、ちょうどその公開時期である9日に感染したという報告がいくつかあることです。ほとんどの場合、2020年より前にシステムにパッチを適用していれば、今月後半にパッチを適用した場合よりもリスクははるかに低くなります。
CVE-2019-19781 推定リスク脅威ランプ
12月17日〜12月31日 エクスプロイトのリスクが最も低い
1月1日〜8日 エクスプロイトのリスクが低い
1月9日〜13日 – エクスプロイトのリスクが高い
1月14日〜現在 – エクスプロイトのリスクが最も高い
これは次のステップのプロセスに組み込む必要があります。
エクスプロイトの痕跡を見つけました。さて、どうすればよいですか?
これは状況によります。ほとんどのCitrix ADC導入で構成されていないことの1つは、適切なSNMPおよびSYSLOGロギングです。また、アーティファクトが見つかった場合に検索、フィルタリング、またはアラートを行う適切な方法がない場合があります。完全なロギングがあり、彼らが何もしていないと確信できるなら、通常の業務を再開してもよいかもしれません。また、何かを見つけて、リモートアクセスを確実に排除できたなら、先に進むことができます。
しかし、ほとんどの場合、いくつかの痕跡が見つかり、何が行われたのか、どこに移動したのかの点を結び付けることができないかもしれません。検出後はデバイスをリセットする方が簡単な場合もあります。
私の次のアドバイスは、今後2週間で変更される予定です。
サンプルインシデント対応パス
誰の状況にも当てはまる正しく完璧な答えはありません。これらは現時点(2020年1月19日)の私の考えであり、次のステップについて学び、この脆弱性に関連する防御側または攻撃側の情報がリリースされるにつれて変更される可能性があります。正解はありません。ITセキュリティは、ほとんどの分野と同様に「状況による」という原則に支配されています。これらの3つのディレクトリにこれらのファイルのみが存在する以外に何かを見つけた場合は、そのボックスは侵害されていると見なし、より慎重なパスを進めることを強くお勧めします。これらのいくつかでは、特に彼らが何をしたか、何をしなかったかを確認するログがない場合は、より慎重なパスを取ることを提案しています。これはチームスポーツであるため、チームと協力して、あなたの状況に基づいて最善の行動方針を決定する必要があります。このような問題を修正するより良い方法は常に存在しますが、デバイス上およびデバイス周辺(Tier 1ターゲット)にある証拠に基づいて、リスクを軽減してそこから進めば問題ないかもしれません。