免責事項: 前述のとおり、これはすべてのエクスプロイトを検出するわけではありませんが、攻撃者が公開エクスプロイトを変更しておらず、かつ/または痕跡を消していない場合に、いくつかの異常を検出するのに役立つ可能性があります。ほとんどの攻撃者はデフォルトのエクスプロイトを使用します。以下は、残される可能性がある文書化されたアーティファクトの一部です。このコマンドリストは多くのソースから収集されたものであり、他の亜種、回避策、新たな動向が出現するにつれて非常に流動的になります。感染が増え、より大きなサンプルセットでさらなるフォレンジックが完了するにつれて、これは常に変化すると考えてください。

まず、自分が行っていない操作を確認してください。通常ADCであまり操作を行わないのであれば、これらのログは非常に静かであるはずです。ただし、最後に操作した数週間前、数か月前、あるいは数年前のエントリが存在する可能性もあります。すぐ下に、より正確なクエリがあります。また、このブログ自体がいたちごっこであることを理解してください。私たちが目撃した内容や攻撃者を見つける方法を公開すると、彼らは検出を避けるために戦術を変えて、この情報を私たちに対して利用します。

エクスプロイトチェック クイックチェックリスト v1

• 1. ライセンスを確認してください。デバイスを再起動したところ、実際にはライセンスが失効していたという話を聞いたことがあります。
• 2. サポートファイルを取得してください。別名バックアップ: システム -> 診断 -> サポートファイルの取得で、そのファイルを保存します。
• 3. 以下のすべてのコマンドはNSCLI内にあります。SSHでボックスに接続してShellを使用する場合は、Shellプレフィックスを省略できます。
• 4. デバイスの日付を確認して、ログの調査結果を関連付けるのに役立ててください
  • a. shell date
• 5. 設定変更日を確認してください
  • a. Shell ls -l /netscaler/ | grep netscaler
  • b. Shell ls -l /nsconfig | grep netscaler
    • i. netscaler.confの日付はいつですか?
    • ii. それは正しいように見えますか? 他の場所へのファイルリンクを確認してください。
• 6. ローカルアカウントのパスワードファイルを確認してください
  • a. Shell ls -lh /etc/passwd
    • i. ファイルがいつ変更されたかを確認してください。エクスプロイト後で、自分が変更していないのであれば、できるだけ早くそのパスワードを変更する必要があります。
    • ii. エクスプロイトが検出された場合は、nsrootまたは任意のローカルアカウントのパスワードを変更することをお勧めします。多くの場合
  • b. Shell cat /etc/passwd
    • i. どのアカウントがそこにあるか確認してください。
    • ii. Root、nsroot、daemon、operator、bin、nobody、sshd、nsmonitorがデフォルトです。
• 7. ログを確認してください
  • a. shell ls -lh /var/logfile
    • i. ファイルはありますか? それらは非常に小さいですか?
    • ii. https://support.citrix.com/article/CTX121898
• 8. 不正ファイルのチェック
  • 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
    • i. このディレクトリは存在しないはずです。
• 9. Cronジョブ(永続化手法)
  • a. shell cat /etc/crontab
  • b. shell crontab -l -u nobody
• 10. 暗号通貨チェック
  • a. shell top -n 10
    • i. NSPPE-xx(パケットエンジン)は100%またはそれに近い値である必要があります。別のプロセスが存在する場合、マイニングされている可能性があります。
• 11. PCAP
  • a. Shell find / -name “*.cap”
  • b. 取得された可能性のある紛失したキャプチャファイルを見つけるのに役立ちます。
  • c. これは、スニッフィングを行った可能性のあるより高度な攻撃者の兆候です。
• 12. シェルログ
  • a. shell cat /var/log/bash.log | grep nobody
    • i. nobodyユーザーからのユーザーアクセスを探します。
  • b. shell gzcat /var/log/bash.*.gz | grep nobody
    • i. 圧縮されたログ内のnobodyユーザーからのユーザーアクセスを探します。
• 13. 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. これはファイルの生の内容を全体的に確認しており、他に目立つ項目を探すためのものです。
• 14. 永続化スクリプト
  • a. shell ps -aux | grep python
  • b. shell ps -aux | grep perl
  • c. shell ps -auxd | grep nobody
    • i. これらはどちらも、リバースシェルやその他のタスクを実行するスクリプトを使用する既知の永続化手法です。このプロセスリストにはgrepコマンドのみが表示されるはずです。
    • ii. これは別の永続化手法の調査結果の一部を説明しています。このエクスプロイトは、Nobodyユーザーによって実行された悪意のあるプロセスを使用しました。 https://soolidsnake.github.io/2020/01/17/citrix_malware.html
• 15. パスワード\アカウントの確認
  • a. shell ls -l /etc/passwd
    • i. 最近何かが追加されている場合は、ファイルの日付も確認してください。
  • b. shell cat /etc/passwd
    • i. 疑わしいもの、ローカルアカウントはありますか?
• 16. TCP接続を確認してください
  • a. Shell netstat -natu
  • b. VLAN内の非ローカルIPアドレスを探してください。別のボックスが侵害された場合に備えて、内部IPも確認する必要があります。
• 17. 認証プロファイルを確認してください
  • a. TLSまたはSSLに設定されていたのに、現在は平文(PlainText)になっていませんか?
    • i. 一部の監査やオンラインで変更されたケースを見たことがあります。
    • ii. これも上級攻撃者の兆候です。
  • b. これは、設定ファイルns.confが変更されたかどうかに関係します。幸いなことに変更されていない場合があります。
  • c. 以前に平文だった場合は、エクスプロイトの兆候が見つかるかどうかに関係なく、できるだけ早くTLSとSSLに設定する作業を行う必要があります。
• 18. 証明書を確認してください
  • a. これらはSSL証明書であり、特にボックスがエクスプロイトされている場合は、再キー生成を検討する必要があります。
  • b. エクスプロイトの兆候が少しでもあれば、SSL証明書を再キー生成することをお勧めします。大規模な展開では、証明書がバインドされている他の場所の数や、SSL証明書の変更によって発生する可能性のある停止\混乱のために、より困難な道のりになる可能性があります。
  • c. エクスプロイトを実行する以外に何もしておらず、システム設定にピボットしなかったことを証明できる優れたログを持っていたため、再キー生成をしなかったクライアントを見たことがあります。ほとんどのクライアントは、わずか数日分の
• 19. 潜在的な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ターゲット)にある証拠に基づいて、リスクを軽減してそこから進めば問題ないかもしれません。

• 緩和策: これは何があっても開始すべき場所です。新しいファームウェアまたはレスポンダーポリシーを使用します。
• 監査中に検出されたエクスプロイト。
  • インシデント対応プロセスを開始します。
• 優れたデバイスロギングがある場合
  • 高度な攻撃または永続化の兆候がある場合
    • 新規構築して移行
  • 高度な攻撃または永続化の兆候がない場合
    • 修復して稼働継続
• デバイスロギングがない場合
  • 高度な攻撃または永続化の兆候がある場合
    • 新規構築して移行
    • ファクトリーリセット
  • 高度な攻撃または永続化の兆候がない場合
    • 新規構築して移行
    • ファクトリーリセット
• 優れたTier 1ターゲットロギングがある場合
  • 高度な攻撃または永続化の兆候がある場合
    • 新規構築して移行
    • ファクトリーリセット
  • 高度な攻撃または永続化の兆候がない場合
    • 修復して稼働継続
• Tier 1ターゲットロギングがない場合
  • 高度な攻撃または永続化の兆候がある場合
    • 新規構築して移行
    • ファクトリーリセット
  • 高度な攻撃または永続化の兆候がない場合
    • 新規構築して移行
    • ファクトリーリセット

対応の定義と考察

• 新規構築して移行 – インシデント対応プロセスを開始してから、このプロセスを開始できます https://docs.citrix.com/en-us/citrix-hardware-platforms/mpx/migrating-configuration-of-existing-appliance-to-another-appliance.html。これは、仮想的な性質と構成プラットフォームの柔軟性により、VPXおよびSDXのお客様にとって比較的簡単です。MPX移行は、ファクトリーリセットの仕組みとベースイメージが維持される方法のため、別の話です。上級攻撃者によるファームウェアアップグレードやファクトリーリセットを介した永続化のリスクは非常に低い可能性があります。可能性は低いかもしれませんが、それでも可能です(サイバー世界の何と同様に)。
• ファクトリーリセット – インシデント対応プロセスを開始し、.xmlファイルとその他検出されたものを削除して再起動し、永続化を再度確認します。その後、ファクトリーリセットを実行するプロセスを開始します。このプロセスを実行するスクリプトはCitrixから入手できます。これは、オペレーティングシステムを再ロードする前にシステムを最下位レベルまで消去しますが、これまでのところ、脅威環境に基づいてこの方法を信頼する人は皆、さらに多くのことを求めるかもしれません。
  • 最も抜本的な方法は、デバイスをRMAしてドライブを再ロードすることです。これは、ライフサイクル、プラットフォーム、冗長化計画によっては、良い考えでも悪い考えでもあり得ます。高度な技術が使用されているのを確認し、その技術に基づいて横方向の移動が確認された場合にのみ、このパスを進めることをお勧めします。Citrixが「what if」オプションに取り組んでいることは知っていますし、
• 修復 – インシデント対応プロセスを開始し、.xmlファイルとその他検出されたものを削除して再起動し、永続化を再度確認します。優れたログがあれば、何かが行われたかどうかがわかります。ない場合は、脅威環境を確認し、Tier 1ターゲットまたはその他のログがあるかどうかを確認して、ファクトリーリセットが必要かどうか、または新規構築して移行する必要があるかどうかを判断します。

ロギングの階層

• 優れたローカルロギング
  • ローカルで何が起こったかを確認し、横方向の移動の試みがあったかどうか、またはほとんどの場合のようにエクスプロイトが単に実行されただけかを知るのに最適な立場にいます。
• 優れたTier 1ターゲットロギング
  • 横方向の移動が発生したか、試行されたかを確認するのに最適な立場にいます。これらは最初に標的になる可能性が高いものです。横方向の移動が成功したのを確認した場合は、最も懸念し、修復パスでより慎重に進める必要があります。そうでない場合は、脅威のリスクを下げて修復パスを進めることができます。
• ローカルロギングなし
  • ローカルで何が起こったかを確認し、横方向の移動の試みがあったかどうか、またはほとんどの場合のようにエクスプロイトが単に実行されただけかを知るのに最悪の立場にいます。修復パスではより慎重に進める必要があります。
• Tier 1ターゲットロギングなし
  • 横方向の移動が発生したか、試行されたかを確認するのに最悪の立場にいます。これらは最初に標的になる可能性が高いものです。横方向の移動が成功したのを確認した場合は、最も懸念し、修復パスでより慎重に進める必要があります。

人々が感染を除去し、もはや侵入されていないと確信できる十分なロギングを持ち、これらの手順のいくつかを踏まずに通常の活動を再開できることを願っています。

その他の優れたフォローアップ手順

エクスプロイトの痕跡がある場合に決定する必要がある主な事項が2つあります。

• 1. NSROOTパスワードを変更する
  • a. 何が見つかろうと、どのようなログを持っていようと、これを実行することをお勧めします。これは、パスワード変更のローテーションにnsrootを含める機会です。ADC管理はLDAPにバインドし、NSROOTは緊急時のみ使用する必要があります。
• 2. LDAPサービスアカウント(または別の認証サービス)を変更する
  • a. このパスワードを変更するとともに、可能であれば別のアカウントに変更することをお勧めします。そうすれば、異なるSIDも得られます。これは、ロールアウト前にテストすれば誰にも気づかれずに実行できる受動的な変更です。
• 3. SSLキーを変更する
  • a. 優れたロギングがある場合
    • i. ログが100%良好であると確信できるなら、問題ないかもしれません。
    • ii. すべてを再キー生成すべきと言いたい気持ちもありますが、大規模な環境ではそれがどれだけの作業になるかわかっています。
  • b. ロギングがない場合
    • i. そこにあるすべてを再キー生成する必要があると思います。PEMおよびPFX保護がありますが、それらに非常に単純なパスワードを使用し、オフラインでブルートフォースされる可能性がある場所を多く見てきました。私たちは会社を保護する必要があるかどうかわからないからです。

パスワードに関する考察

エクスプロイトが成功した兆候が少しでもある場合は、ボックス上のすべてのローカルアカウントのパスワードを変更することをお勧めします。ためらわずに変更してください。多くの展開では、4〜7年前に最初に展開されてから一度も変更されていない可能性があるからです。コマンドラインアクセスや改ざんの兆候が見られる場合、攻撃者はPre 11.0ファームウェアのパスワードを解読できる可能性が高いと考えるべきです。Pre 11.0ではAES256で、後のビルドではAES512を使用していますが、これも解読に対して脆弱である可能性があります。また、LDAPに安全にバインドされていること、NSROOTログインのアラートを設定していることを確認してください。

LDAPに関する考察

何らかのレベルのエクスプロイトを確認した場合は、Citrix ADC設定内で定義されているすべてのサービスアカウントを変更することも確認してください。最も一般的なのはLDAP\Kerberosバインドアカウントです。Citrix ADCでエクスプロイトを実行できたからといって、その人物がドメイン管理者であるとは限りませんが、あなたのコントロールとロギングによっては、それほど時間がかからないかもしれません。これは非常に簡単な変更であり、テストすればユーザーにシームレスです。

証明書に関する考察

監査で何が見つかったかによって、これも判断できます。優れたログがあり、このファイルへのアクセス要求を確認できる場合は、再キー生成が必要です。優れたログがない場合も、再キー生成する必要があります。ワイルドカード証明書を使用している場合も、それはもう1つの大きな問題です。バインドされているサイトが多いほど、リスクと露出が大きくなります。最悪の事態は、問題ないと判断して、攻撃者があなたの証明書を使用してフィッシングサイトを立ち上げ、トレーニングではクリックを防げないことです。誰かがあなたの証明書にアクセスできる場合、これはさらに大きな問題につながる可能性があるため、慎重に進めて再キー生成を行うことをお勧めします。現在の証明書の有効期限によっては、これは良いタイミングかもしれません。このプロセスで別の証明書登録機関に切り替えて変更する人を見たことがありますが、彼らはファイルがアクセスされダウンロードされたというログとともに、他の高度な技術が検出されていました。

クレジット ###最後になりましたが、この問題が最初に発生して以来取り組んできた方々への謝辞をいくつか述べます。リストに載せていない、舞台裏で支えてくれた方々も大勢いますが、私もその全員を把握しているわけではありません。

• Citrix Team – 新しいファームウェアへの対応と並行して、情報を発信するために取り組んでいます。コードファミリーごとの差異に基づき、同時に5つのパッチを扱わなければならず、その分困難さが増しています。
• Daniel Weppeler @_DanielWe – プローブ\攻撃を検出するためのレスポンダーポリシーのログ記録
• Florian Roth @cyb3rops – 不正利用検出のためのNessus YARファイル
• CTP Anton van Pelt @AntonvanPelt & CTA Mads Petersen @mbp_netscaler & Jan Tytgat @jantytgat – CTP\CTAおよびCitrixチームとともに、多方面で絶え間なく活動
• KevTheHermit @KevTheHermit – CVEに加えて、AWSインスタンスのパスワード脆弱性の開示
• Bad Packets Report @bad_packets – Bad Packetsチーム全体 https://badpackets.net
• Kevin Beaumont @GossiTheDog – 観察された問題を数多く広めるとともに、自身のハニーポットとそこで見られた内容についての詳細も提供
• Mpgn @mpgn_x64 – エクスプロイトとその亜種の詳細
• Nick Carr @ItsReallyNick – エクスプロイトの詳細とインシデント対応のヒント
• Digi Cat u/digicat – Redditユーザー、素晴らしい速報ニュースブログ
• Ben Sadeghipour @NahamSec – DFIR YouTubeビデオおよびその他の貢献
• SANs Team – 記事、DFIR、ディープダイブビデオ
• Craig Dods @0xCraig – パスワードへの影響と調査
• Manuel Kolloff @manuelkolloff – ポストエクスプロイトのウォークスルー
• FireEyeおよびMandientのチームチーム。最初の検出カバレッジを作成してくれたRick Cole氏、このブログへのインプットを提供してくれたMandiantのインシデントレスポンダーチーム（特にAustin Baker氏、Brandan Schondorfer氏、John Prieto氏）に感謝します。また、この脆弱性からクライアント環境を対応・保護しているすべてのコンサルタントにも感謝します。さらに、このブログの開示とツーリングのタイムラインを洗練させるのを支援してくれたVulnerability IntelligenceチームのNicholas Luedtke氏にも感謝します。