レスポンスアクションによるlog4jのブロック

本文の内容は、2021年12月21日にMichael Clarkが投稿したブログ(https://sysdig.com/blog/blocking-log4j-response-actions/）を元に日本語に翻訳・再構成した内容となっております。

log4j ( log4shell ) の脆弱性に関する状況は、1週間以上前にリリースされて以来、急速に進展しています。最初の2.15.0パッチではカバーされていなかった新しいエクスプロイト、CVE-2021-45046が発見されました。2.16.0のパッチがリリースされて間もなく、CVE-2021-45105という別の問題が見つかり、2.17.0がリリースされました。log4jライブラリでは明らかに多くのことが起こっています。

このような非常にダイナミックなシナリオでは、標準的な「スキャン-パッチ」による脆弱性管理では、単純に十分ではありません。websocketを介したものなど、新しい攻撃ベクターが日々出現し、悪用の試みを検出することがさらに困難になる可能性があります。log4jを使用する攻撃者が変更するのが難しいことが1つあります。それは、彼らの悪用後の活動であり、防御者はこれを利用して有利にすることができます。

この記事では、Sysdig Secureを使用して、コンテナ化された環境でこれらの活動をブロックする方法を見ていきます。

対応策

Sysdig Secureは、レスポンスアクションを使用して、さらなる侵害を防ぐためのいくつかのオプションを提供します。

これには、電子メール、webhook、またはその他のサポートされている方法を使用した通知による、コンテナのKill、停止、または一時停止が含まれます。これらのレスポンスはポリシーに添付され、ポリシーにはルールのリストが含まれています。ポリシーのいずれかのルールがトリガーされると、影響を受けたコンテナを自動的にKillすることができ、侵害による被害が拡大するのを防ぐことができます。

レスポンスアクションは、インシデント対応プロセスに合わせてカスタマイズできます。

例えば、一時停止したコンテナを後から回収して、フォレンジック分析を行うことができます。コンテナ固有のアクションを取ることで、クリーンなバージョンを復元しながら、侵害された環境全体を簡単に封じ込めたり、根絶したりすることができます。

コンテナに対する対応を目的としたポリシーを作成する際には、「ワークロードポリシー」を選択します。ポリシーにインポートするルールを選択する際には、そのルールによってコンテナがKillされることを考慮してください。このポリシーでは、影響を受けていないワークロードを混乱させないように、信頼度が高く、誤検出が少ないルールのみを選択する必要があります。

この例では、ルール「Malicious C2 IPs or domains exploiting log4j」を使用します。これは、エクスプロイトのエグレスステージに使用される既知の不良IPアドレスに基づいており、侵害の忠実度の高い指標となるからです。

Sysdigのお客様であれば、log4jのIoCのリストは、
より多くの情報が集まると自動的に更新されます。

私たちのポリシーはこんな感じです：

Actionsの箇所で、「Kill」が選択されていることに注意してください。インシデント対応のワークフローで、コンテナを破壊する前に特定の状態で検査する場合は、StopやPauseもオプションとして用意されています。コンテナがKillされると、Kubernetesは多くの場合、侵害されていない新しいバージョンを開始しようとします。

log4j攻撃

レスポンスアクションを示すために、脆弱なコンテナに対してかなり典型的なlog4j攻撃を実行します。ポリシーのレスポンスアクションを実行するルールをトリガーするために、テストシステムのIPアドレスを一時的にIndicators of Compromiseのリストに追加しました。

これらのIoCは、JNDI攻撃文字列を送信していると見られるアドレスではなく、egress/C2 IPアドレスに基づいています。

上記のルールを時系列で説明します。

Log4j Post-Exploitationのブロック
これは、上記で作成したポリシーで、「log4jを悪用する悪意のあるC2 IPまたはドメイン」ルールと「コンテナをKillする」アクションの両方を含んでいます。悪意のあるIPが検出されてルールがトリガーされると、アクションが実行され、コンテナがKillされます。そして、Kubernetesのオーケストレーターが、破壊した危険なコンテナの代わりに新しいコンテナを起動します。
Log4J IoC
これは、「ブロッキング」バージョンと似ていますが、よりソフトなポリシーです。log4j IoCの発生を識別し、警告を発するルールが含まれています。このポリシーは通知を生成するように設定されているだけで、何かアクションを起こすわけではないので、このポリシーによってコンテナがKillされたり置き換えられたりすることはありません。
新しいコンテナの起動
このポリシーには、Kubernetesがポッド内に新しいコンテナを作成したときに検出するルールが含まれています。このポリシーの実行は、最初の例のポリシーで行われた「kill」アクションの結果であり、破壊されたコンテナを置き換えるために新しいコンテナがデプロイされたことを示しています。

また、Sysdig Monitorが有効になっている場合、コンテナのkillイベントは、以下のようにEventページで簡単に確認することができます。

ルール

- list: "malicious_log4j_c2"
  items:
  - "\"5.255.97.172\""
  - "\"18.228.7.109\""
  - "\"31.6.19.41\""
 …


- rule: "Malicious C2 IPs or domains exploiting log4j"
  desc: "Malicious commands detected in pod or host. The rule was triggered by IPs\
    \ or domains that exploit log4j"
  condition: "evt.type = connect and evt.dir = < and fd.sip in (malicious_log4j_c2)\n"
  exceptions: []
  output: "Malicious connections to C2 IPs or domains detected in pod or host exploiting\
    \ log4j. %proc.cmdline %evt.args"
  priority: "WARNING"
  tags: []
  source: "syscall"

malicious_log4j_c2 は、このgreynoise.ioのgistなどのOSINTソースを使って収集されたものです。

- rule: "Launch new container"
  desc: "Detect the initial process started in a new container. Exceptions are made\
    \ for known trusted images."
  condition: "evt.type=container and container and not falco_privileged_containers\
    \ and not user_privileged_containers
  output: "New container started (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline\
    \ %container.info image=%container.image.repository:%container.image.tag)"
  priority: "NOTICE"
  tags:
  - "container"

まとめ

パッチを当てて攻撃を防ぐことは、ゼロデイに対する理想的な対応ですが、log4jのようなケースでは、チームが対応するよりも早く脅威が進化してしまいます。

このような場合、侵入後の行動をきっかけとした対応を行うことで、攻撃者が与えるダメージを抑えることができます。侵入後の指標は、攻撃者が変更することがはるかに難しく、この防御戦術を回避することは困難です。

Sysdig Secureでは、システム全体を隔離するのではなく、影響を受けたコンテナだけをKillすることで、クラウドに適した方法で能動的な攻撃に対応することができます。

Sysdig Secureでは、他のオープンソース・プロジェクトとともに、アウトオブボックスのルールでFalcoを拡張しており、Kubernetesのセキュリティとの連携や管理がさらに容易になっています。30日間の無料トライアルに登録して、ご自身の目で確かめてください！