CSIフォレンジック：Kubernetesの犯罪現場を解き明かす

By 清水 孝郎 - OCTOBER 23, 2024
Topics: コンテナ、Kubernetes、ホストのセキュリティ, 脅威リサーチ

SHARE:

本文の内容は、2024年10月23日に Alberto Pellitteri が投稿したブログ(https://sysdig.com/blog/csi-forensics-unraveling-kubernetes-crime-scenes/)を元に日本語に翻訳・再構成した内容となっております。

これは、 CloudNativeSecurityCon 2024で公開および発表されたCSI コンテナシリーズの 2 番目のエピソードです。このエピソードでは、Kubernetes CSI、K8s およびコンテナでの DFIR アクティビティの実施方法、静的および動的分析の実行方法に焦点を当てます。

最初のエピソードで説明したように、DFIR はデジタルフォレンジック (DF) とインシデント対応 (IR) を組み合わせたものです。また、コンテナ環境での DFIR アクティビティの実施が、ホスト環境での通常の DFIR とどのように異なるかについても説明しました。コンテナの特殊性により、効果的に動作するには特定のツールが必要です。

この記事では、以前に説明した k8s チェックポイントと呼ばれる Kubernetes 機能について再度取り上げます。Falco コンポーネントを使用してこれを自動化し、デジタルフォレンジックとインシデント対応 (DFIR) 分析に非常に役立つコンテナスナップショットを作成する方法を説明します。

K8s チェックポイントの自動化

別のブログで説明したように、コンテナ チェックポイント機能を使用すると、実行中のコンテナのチェックポイントを作成できます。つまり、実行中のプロセスや保存されたデータに関する情報を失うことなく、現在のコンテナの状態を保存して後で再開できる可能性があります。 

この機能はまだ開発の初期段階にあり、さまざまな制限がありますが、DFIR のユースケースにとっては非常に興味深いものです。この機能を使用してコンテナの状態をスナップショットし、サンドボックス環境に復元してフォレンジック分析を進めることができたらどうでしょうか?

私たちが直面しなければならない最初の問題は、コンテナが短命であるということです。コンテナのスナップショットを作成するには、コンテナが存在している必要があります。さらに、攻撃中にできるだけ早くコンテナのスナップショットを作成して、復元時にさらに監視できるようにする必要があります。したがって、次の Kubernetes レスポンスエンジンは、私たちのユースケースにぴったりです。

Falcoによる検出と対応

Falco、Falcosidekick、および Argo を使用すると、アクションを実行できるレスポンスエンジンを設定できます。この場合、主な目的は、特定の悪意のある Falco ルールがトリガーされるとすぐに K8s チェックポイントを実行することです。その後、チェックポイントを使用してさらに分析を行うことができます。

実際のシナリオ

その動作を理解するために、実際のシナリオで自動化がどのように機能するかを調べてみましょう。 

このシナリオでは、攻撃側では、よく知られているチャットボット、特に IRC チャットボットを使用します。このチャットボットは、影響を受けるコンテナにダウンロードされて実行されると、既知の C2 サーバーに接続します。詳しく知りたい場合は、Github に Perl ボットのサンプルが多数ホストされています。これらは時代遅れの手法のように見えるかもしれませんが、近年、多くのキャンペーンでさまざまなコンテナ化されたサービスが収集されています。   

防御側では、悪意のあるアクティビティを検出するのではなく、次の Falco ルールを使用して、よく知られている IP への悪意のある接続を識別することに重点を置きます。  

# List of IPs provided by a threat intelligence feed

   - list: malicious_ips

     items: [‘“ip1”’, ‘“ip2”’, …]

   - rule: Detect Outbound Connection to Malicious IP

     desc: This rule detects outbound connections to known malicious IPs according to threat intelligence feeds. Interactions with such machines may compromise or damage your systems.

     condition: >

       (evt.type in (connect) and evt.dir=<

         and fd.net != "127.0.0.0/8" )

         and container

         and fd.sip in (malicious_ips)

     output: An outbound connection to %fd.sip on port %fd.sport was initiated by %proc.name and user %user.loginname and was flagged as malicious on %container.name due to Threat Intelligence feeds 

     tags: [host, container, crypto, network]

悪意のある Perl ボット スクリプトをダウンロードして実行すると、Kubernetes レスポンスエンジンがどのようにトリガーされ、侵害されたコンテナのチェックポイントがどのように正しく実行されるかを確認できます。 

デフォルトでは、チェックポイント tar ファイルは、影響を受けるコンテナをホストする Kubernetes ノードのファイルシステムに保存されます。ただし、より現実的なシナリオでは、チェックポイントアーカイブをクラウドバケットや外部ストレージなどのより安全な場所に移動することを検討する必要があります。コンテナが侵害された場合、攻撃者はホスト上で横方向に移動している可能性があるため、ファイルをホストファイルシステムに残しておくことは賢明な選択ではないことに注意してください。

DFIR分析

コンテナチェックポイントの準備ができたので、そのファイルを使用して、攻撃中に何が起こったのか、攻撃者の目的を調査して理解することができます。 

コンテナ チェックポイントアーカイブを使用して、静的および動的分析をフィードできます。次のファイルは、コンテナ チェックポイント tar ファイルにあります。

静的分析の場合、コンテナのファイルシステム内の変更されたファイルは、特に攻撃者がドロップしたバイナリやスクリプトを使用することで非常に役立ちます。動的分析の場合、コンテナを復元し、適切なツールを使用して実行を分析すると、意図された動作を理解するのに非常に効果的です。

上記で報告した実際のシナリオを使用して分析を開始し、以前に取得したチェックポイントを使用して調査を進めましょう。 

実際のシナリオ: 静的解析

静的分析で最初にできることは、攻撃者がファイルシステムにバイナリやスクリプトを残しているかどうかを確認することです。チェックポイントは攻撃者がバイナリを実行してから数秒後に実行されたため、これは非常に可能性が高いです。

上記のスクリーンショットで確認したように、コンテナチェックポイントには rootfs-diff.tar アーカイブが含まれており、これにはベースイメージと比較して以前にチェックポイントされたコンテナで変更されたファイルが含まれています。

perlbot.plファイルは興味深いものなので、このファイルを保存して、フォレンジックの世界で提供されている広く知られているすべてのテクニックとツールを適用し、さらに静的分析とリバース エンジニアリングを行うことができます。 

もう 1 つのオプションは、 checkpointctl を使用することです。このツールを使用すると、以前に取得したチェックポイントをさらに深く調べることができます。 

特に、プロセス ツリーを調べることで、チェックポイントが設定されたコンテナに何があったかを調べることができます。たとえば、このケースでは、悪意のある [systemd] プロセスによって確立された C2 との TCP 接続が簡単に確認できます。 

コンテナがチェックポイントされたときのコンテナ メモリを確認し、興味深いパターンを探すこともできます。

たとえば、この場合、ボットと同じ IRC チャネルに接続されている他のマシン間で交換される非常に疑わしい文字列やメッセージを簡単に識別できます。

さらに、checkpointctl を使用すると、コンテナに割り当てられ、攻撃者が権限をクラスタに昇格するために悪用した可能性のあるコンテナマウントをすばやく特定できます。

この場合、唯一興味深いマウントは、Kubernetes ポッドのコンテナにアタッチされた Kubernetes サービスアカウントであり、これにより、攻撃者は Kubernetes API サーバー、さらにはクラスター全体にアクセスできる可能性があります。ただし、このシナリオでは、それがデフォルトのサービスアカウントであり、その権限は非常に制限されていたため、これについては詳しく説明しません。 

ただし、ベストプラクティスでは、影響を受けるコンテナで機密マウントが見つかった場合は、調査範囲をクラスター全体またはホスティングしている Kubernetes ノードにまで拡大して、さらに詳細に調査することを推奨しています。 

静的分析用のもう 1 つのツールはCRITです。これは、チェックポイントアーカイブに保存されている CRIU イメージ ファイルを分析します。これらを使用すると、checkpointctlで確認したものと同様の結果を得ることができます。たとえば、プロセス ツリーを取得したり、タスクで使用されるファイルを表示したり、メモリ マッピング情報を取得したりすることができます。 

> crit x checkpoint ps

    PID   PGID    SID   COMM

      1      1      1   tini

      7      7      1       sudo

     20      7      1           jupyter-lab

     77     77     77               bash

    102    100     77       [systemd]

チェックポイントに保存されたコンテンツは、調査にとって貴重な情報となる可能性があります。たとえば、生のメモリページを読み取ることで、悪意のあるプロセスに関連する環境変数や実行結果を確認することができます。 

ここでは、たとえば、被害者のボットとサーバーの間で交換されたメッセージを取得し、バイナリ実行に関連する出力を出力しました。 

これにより、影響を受けたコンテナで何が実行されたかを把握できます。また、被害者に送信されたメッセージや、同じ IRC チャネルに接続された他のマシンによって要求されたコマンドを直接特定することもできます。

動的分析の準備

動的分析を進める場合は、特定の閉じた環境で以前に実行されたチェックポイントの復元を開始して、マルウェアを分析し、その動作を監視することができます。 

先に進む前に、現在のチェックポイント機能と復元機能の制限に注意することが重要です。コンテナは他の場所でもチェックポイントを作成して復元できますが、よりスムーズに復元するには、影響を受けるマシンと分析マシンの両方で同じコンテナエンジンと CRIU バージョンを使用することを強くお勧めします。この記事の執筆時点では、この機能は containerd に統合されておらず、crun などの一部のインターフェースでは信頼性が低いままでした。そのため、より信頼性の高いプロセスを実現するために、CRIO と runc に依存していました。

そうは言っても、復元プロセスはどのように達成できるのでしょうか?

最初に行うことは、以前に取得したチェックポイントアーカイブを安全なストレージに移動することです。このベスト プラクティスにより、証拠を安全に保管でき、元のチェックポイントが紛失、削除、または改ざんされた場合でも、常にバックアップを頼りにすることができます。

次に、 buildahユーティリティを使用して、以前にチェックポイントされたコンテナ アーカイブから新しいコンテナイメージをビルドできます。この手順は、前述のレスポンスエンジンを拡張して自動化することもできます。ただし、一般的に、イメージ構築プロセスは次のように実現できます。

newcontainer=$(buildah from scratch)

buildah add $newcontainer /var/lib/kubelet/checkpoints/checkpoint-<pod-name>_<namespace-name>-<container-name>-<timestamp>.tar /

buildah config --annotation=io.kubernetes.cri-o.annotations.checkpoint.name=<container-name> $newcontainer

buildah commit $newcontainer checkpoint-image:latest

buildah rm $newcontainer

buildah push localhost/checkpoint-image:latest container-image-registry.example/user/checkpoint-image:latest

…ここでの /var/lib/kubelet/checkpoints/checkpoint-<pod-name>_<namespace-name>-<container-name>-<timestamp>.tar  は、チェックポイントがディスクに書き込まれた場所です。

これを行うことで、新しいコンテナイメージをコンテナレジストリにプッシュし、後で他のマシンにプルして実行できるようになります。 

コンテナチェックポイントからコンテナイメージをビルドしたら、完全に分離された Kubernetes クラスターに復元し、以前にフリーズしたコンテナを単純なポッドとしてデプロイして再現します。yaml テンプレートは次のようになります。

apiVersion: v1

kind: Pod

metadata:

 name: restored-pod

spec:

 containers:

 - name: <container-name>

   image: <container-image-registry.example/user/checkpoint-image:latest>

…ここでのイメージは、以前にコンテナレジストリにプッシュしたものとまったく同じです。 

その yaml ファイルを適用すると、新しく復元されたポッドが現在実行されていることがわかります。コンテナ内でインタラクティブ シェルを開くと、以前とまったく同じプロセス ツリーが同じ PID で表示されます。

さらに驚くべきことに、IRC ボットチャネルへの接続も復元されました。ここでは、コンテナが復元されると、チェックポイントが設定される前と同じボットニックネームで IRC サーバーに自動的に再接続されたことがわかります。これは、以前凍結した実行を復活させたかのようです。

このシナリオは、コンテナのチェックポイントと復元の可能性を明確に示しています。また、隔離された制限された環境で悪意のある実行を再現して分析することも可能になり、よりプロアクティブでフォレンジックなアプローチを採用できます。 

実際のシナリオ: 動的解析


動的解析の詳細に入る前に、まずこのようなシナリオで守るべきベストプラクティスと必要な要件についてしっかり押さえておくことが大切です。 

悪意ある挙動を安全に再現するためには、コンテナのエスケープや権限昇格を防ぐような強力な制約を設定することが不可欠です。適切なマシン設定を行い、機密情報を保護し、制約が有効であることを確認することが、効果的なフォレンジックのために必要です。さらに、動的解析を行い、マシン上で発生するイベントを低レベルで把握するためには、適切なツールを使用することも重要です。

Wireshark、Sysdigオープンソース、straceなどのツールを使用すれば、全てのイベントを確認することができます。すべての発生した事象を記録し、収集することで、調査を正しい方向へ導く手がかりとなり、攻撃の詳細を特定する助けとなります。

私たちのケースでは、Sysdigオープンソースを使用して、コンテナが実行されている間のシステムコール（syscall）をキャプチャしました。コンテナを復元した直後に必要な時間だけキャプチャを収集することで、コンテナ内で発生する悪意ある実行を監視することができます。

キャプチャが完了した後は、Lograyを使用してイベントを迅速にフィルタリングし、悪意ある実行中に何が起こったかを慎重に分析しました。Lograyを知らない方のために説明すると、Wiresharkの「いとこ」のような存在です。Sysdigオープンソースで取得したシステムコールのキャプチャを調べることができ、Wiresharkがネットワークパケットのトラフィックを検査するのと同様です。

両者は同じUIを持ち、同じフィルタリングロジックを備えているので、ほとんどの方にとって親しみやすいはずです。

たとえば、この場合、私たちは execve システムコールを調査しました。これにより、攻撃者が復元されたコンテナに対して実行したすべてのコマンドを確認することができました。


その後すぐに、ネットワークトラフィックに関連するイベントを調査しました。ここでは、攻撃者が要求したコマンドの後に、被害を受けたコンテナに対する応答がどのように続いているかを確認できます。これらの外向きネットワークパケットは、被害を受けたコンテナが任意のコマンドの結果を攻撃者に返送するために送信したものです。特に、 `id`  や  `ls /` の結果が含まれていました。

最終的に、攻撃者は特定の IP アドレスのポートスキャンも実行するように要求したため、関連する IP を調べてイベントをフィルタリングしました。以下は、関与した Perl ボットによってポートスキャンコマンドがどのように実行されたかを示す、関連するすべてのシステム コールです。

ツールの要約

調査中に使用されたツールの簡単な要約を以下に示します。

ツール理由
チェックポイント自動化
Falco + Falcosidekickランタイム検知+通知ツール
Argoオープンソースの Kubernetes ネイティブ ワークフロー、イベント、CI、CD
criuチェックポイント/復元機能を提供します 
動的解析
wiresharkネットワークキャプチャとネットワーク分析を生成する
lograyキャプチャイベント分析
sysdig、strace などイベント/システムコールキャプチャを生成する
tcpdumpパケットアナライザーツール
htopインタラクティブなプロセスビューアツール
静的分析
checkpointctlコンテナチェックポイントツールの詳細な分析
critCRIU イメージファイル解析ツール
criu coredumpイメージファイルをコアダンプに変換する
gdb (または類似のもの)バイナリ解析ツール

まとめ

この記事では、新しいリサーチトピックを取り上げ、コンテナのチェックポイント/復元機能をフォレンジック分野にどのように適用できるかを示しました。特に、いくつかの悪意のあるルールに依存する Kubernetes レスポンスエンジンを使用してコンテナチェックポイントを自動的に作成する方法と、新しく作成されたチェックポイントアーカイブを処理する方法について説明しました。 

これを踏まえて、以前に作成したチェックポイントを使用してさらに深く掘り下げるさまざまな方法を紹介しました。コンテナチェックポイント用に特別に考案された旧式の手法やツールを採用した静的分析と、攻撃の詳細を抽出するためのベストプラクティスや実用的なヒントを網羅した動的分析です。

クレジットと参考文献