Всем привет! Это Сергей Зюкин, разработчик экспертизы runtime-radar — опенсорсного продукта, обеспечивающего безопасность контейнерной среды выполнения. Я подготовил для вас статью, в которой расскажу, как можно обнаружить инфостилер, встроенный в библиотеку LiteLLM в результате ее недавней компрометации. Помимо этого, мы, конечно же, рассмотрим и боковое перемещение внутри Kubernetes-инфрастуктуры, которое происходит, если скрипт инфостилера запускается в поде с достаточными привилегиями.
Мы не смогли удержаться и проверили, что Runtime Radar может обнаружить при реализации подобной атаки.
Но обо всем по порядку.
Общий обзор атаки
Поскольку многие исследователи уже подробно разобрали как саму атаку, так и предысторию, то я не буду подробно останавливаться на этом и ограничусь лишь коротким обзором, чтобы было проще понимать контекст обнаружения.
Если разобрать атаку по шагам, то происходит примерно следующее:
При запуске litellm_init.pth декодирует полезную нагрузку (обычный Python-скрипт) из Base64 и запускает ее.
Первый скрипт запускает инфостилер и отправляет собранные им данные на C2-сервер злоумышленника.
Инфостилер собирает чувствительные данные и по возможности закрепляется через systemd-сервис, оставляя бэкдор для удаленного управления.
Если инфостилер в процессе работы находит токен доступа Kubernetes, он использует его, чтобы запустить вредоносный контейнер на каждой доступном узле кластера.
Сам под, в свою очередь, создается с максимальным доступом к ОС узла (privileged, hostPID, hostNetwork) и смонтированным корневым каталогом узла кластера, на котором он был запущен.
При запуске он закрепляется на узле с помощью бэкдора и systemd-сервиса.
Инфостилер реализован по принципу матрешки — состоит из нескольких Python-скриптов, обфусцированных в Base64 и запускаемых последовательно.
Поэтому я разделил работу по обнаружению на два этапа:
На стадии запуска скрипта инфостилера.
На стадии перемещения в Kubernetes-кластер.
Для каждого этапа я продемонстрирую результаты работы экспертизы текущей версии Runtime Radar, а также дам небольшие рекомендации по поиску угроз с помощью нашего опенсорсного инструмента. Погнали.
Особенности запуска в тестовой среде и демонстрация работы скрипта
Опишу некоторые нюансы запуска скрипта, если кто-то захочет повторить и самостоятельно изучить результаты работы Runtime Radar.
Думаю, стоит упомянуть, что все описанное ниже стоит выполнять только в тестовой, изолированной среде.
Я немного упростил себе процесс воспроизведения (да простит меня читатель) и запустил самый первый скрипт вручную. Считаю, что это в целом ни на что не влияет, поскольку самое интересное все равно происходит в двух других скриптах.
А еще я внес небольшие изменения в разные части скриптовой матрешки — прежде всего для своего удобства и безопасности:
заменил эндпоинт подключения для отправки итогового архива на свой внутренний;
изменил эндпоинт для получения команд в скрипте бэкдора;
немного модифицировал команды для закрепления бэкдора на ноде Kubernetes-кластера.
Для запуска я использовал обычный python3.11 с модулями «из коробки», без какой-либо дополнительной настройки.
Чтобы скрипт смог сделать перемещение в Kubernetes, ему необходимы права на создание подов в текущем кластере, поэтому я подготовил сервисную учетную запись с нужными правами и запустил от ее имени под.
Если захотите повторить, можете воспользоваться следующими манифестами:
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-sa
namespace: default
automountServiceAccountToken: true
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-sa-cluster-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: admin-sa
namespace: default
apiVersion: v1
kind: Pod
metadata:
name: test-pod-debian-sa
spec:
serviceAccountName: admin-sa
containers:
- name: test-pod-debian-sa
image: debian:12.2-slim
command: ["sleep", "365d"]
resources: {}Что касается параметров самого Runtime Radar, то я использовал версию, которая сейчас доступна на GitHub без каких-либо дополнительных модификаций или обновлений экспертизы. Так что каждый может самостоятельно убедиться в результатах работы.
Теперь можно запускать и смотреть, как все горит проверять работу скрипта.
Ниже — несколько скриншотов, демонстрирующих результаты успешной эксплуатации.
Видим, что выполнен побег из контейнера на узел кластера Kubernetes.
Давайте теперь посмотрим, что обнаружил наш инструмент.
Обнаружение на этапе запуска инфостилера
После запуска инфостилер начинает искать и собирать множество различных чувствительных данных, при этом делает это смело и громко.
Наши детекторы аномальной активности отлично это демонстрируют: можно наблюдать множественные срабатывания, сигнализирующие о подозрительном запуске командной оболочки (CS_RT_SUSP_SHELL) и чтении данных (CS_RT_SUSP_FILE_READ), о запуске подключений к различным эндпоинтам (CS_RT_HACK_TOOLS_EXT, CS_RT_DOWNLOAD_TOOLS), о многочисленных запусках env, whoami.
На что стоит обратить внимание при поиске угроз и расследовании инцидентов, подобных кейсу с компрометацией LiteLLM. Как всегда, внимание к деталям — лучший друг любого специалиста по поиску угроз. Настораживает не факт запуска командной оболочки, а то, КАК это происходит. Мы видим:
множественные попытки запуска в течение короткого времени;
подозрительного родителя процесса командной оболочки.
Фильтры помогут нам выбрать необходимый детектор и посмотреть на всю активность целиком. В качестве подтверждения факта нелегитимности используются аргументы, наполненные различными командами и шаблонами для поиска чувствительных данных.
В параметрах фильтра включим отображение событий, в которых обнаружены угрозы (Events with threats only), укажем детектор CS_RT_SUSP_SHELL и применим изменения.
Детектор CS_RT_SUSP_SHELL отслеживает родителя процесса командной оболочки, поскольку в данном случае родительским процессом является /usr/bin/python3, он подсвечивает такую активность как угрозу.
Не так много легитимных приложений используют Python для запуска командной оболочки, а когда это происходит несколько раз подряд в продуктивной среде — стоит насторожиться.
Можем также изучить поведение процесса-родителя и посмотреть, какие подозрительные действия были обнаружены при его запуске. Напомню, что в нашей матрешке этим родителем будет второй Python-скрипт.
Возьмем любое событие из предыдущей выборки и в контекстном меню выберем Parent context.
Чтобы отобразить события, необходимо убрать фильтрацию по конкретному детектору.
Вот тут начинается интересное: мы видим срабатывания наших детекторов, связанные с обращением родительского процесса к чувствительным файлам (функция security_file_permission). Обратите внимание, что для этого скрипт не запускал никакие дочерние процессы — это было сделано в ходе работы кода.
Как раз в таких случаях помогает наша телеметрия на базе eBPF, которая позволяет отследить обращения к файлам на более низком уровне, избегая подмены и отслеживания конкретных системных вызовов.
Среди прочитанных файлов видим файл с хешами-паролей от учетных записей Linux (/etc/shadow) и токен учетной записи Kubernetes (той самой, которую мы специально создали с повышенными правами, чтобы сработало перемещение в кластер).
Давайте теперь посмотрим, что происходило после этого. Напомню, что основной скрипт нашей матрешки (тот, который запускается самым первым) должен еще отправить данные на внешний C2-сервер. Для просмотра этих событий воспользуемся еще одним контекстным фильтром — выберем параметр Same parent.
Видим сработавшие детекторы, которые указывают на создание и эксфильтрацию архива собранных данных.
Помимо этого, события также содержат один из важнейших индикаторов компрометации (IoC) — адрес и порт конечного C2-сервера.
В итоге Runtime Radar смог обнаружить:
поиск и сбор чувствительных данных,
эксфильтрацию полученных данных,
адрес С2-сервера злоумышленника.
Кажется, здесь мы обнаружили уже достаточно шагов. Теперь перейдем к этапу перемещения в Kubernetes-кластер и побега из контейнера.
Обнаружение на этапе перемещения в Kubernetes-кластер
Итак, для закрепления на узле кластера скрипт запускает под в пространстве имен kube-system, который монтирует корневой каталог узла и закрепляется на уровне службы systemd. Параметры сбора событий в Runtime Radar были настроены на частичный мониторинг kube-system, поэтому события можно получить с помощью простого фильтра. На скриншоте ниже мы видим, как при помощи Runtime Radar мы фильтруем события по пространству имен kube-system, также для лучшей читаемости оставляем только события с типом exec, исключая события завершения процесса и kprobe.
Фильтры помогают нам увидеть четкую последовательность команд, запущенных в контейнере для реализации побега и закрепления на узле кластера с помощью systemd-службы. Кроме того, Runtime Radar дает нам понять, что команды были запущены в поде с максимальными возможностями (CAP_SYS_ADMIN). Из детекторов сработал CS_RT_BASE64_DECODE_RUN, который обнаруживает использование средств дешифровки Base64-последовательности.
В таких случаях всегда стоит обращать внимание на любую подозрительную активность в kube-system-пространстве, поскольку злоумышленники часто используют его, чтобы замаскировать свою деятельность под легитимную.
Кажется, мы где-то потеряли еще один шаг, а именно обращения к API Kubernetes для запуска привилегированного пода. Детекторов таких подключений в текущей экспертизе инструмента пока что нет (ждем ваши PR 🙂), но события точно должны быть.
Итак, предположим, что мы не знаем конкретную реализацию этого шага, но мы точно знаем, что скрипт, инициировавший сбор секретов, запустил вредоносный под. Тогда попробуем посмотреть все сетевые соединения, которые были установлены в рамках работы скрипта. В фильтрах продукта выбираем дочерний контекст и функцию tcp_connect, которая используется для инициализации TCP-соединений.
Для этого сначала посмотрим сетевые соединения дочерних событий. Их нет, а это означает, что скрипт не использовал сторонние утилиты для обращения к API Kubernetes. Тогда логично предположить, что это обращение было реализовано в коде Python-скрипта. Немного изменим фильтр, выбрав параметр Same process, и проверим события.
И действительно, видим события, связанные с подключением к стандартным эндпоинтам kubernetes, доступным внутри контейнера.
Итого обнаружили:
сетевые соединения с API Kubernetes;
запуск вредоносного пода;
закрепление на узле через команды в поде.
Основные выводы
Случай с LiteLLM доказывает необходимость обеспечивать защищенность и мониторинг среды выполнения в рамках процесса безопасной разработки. Это особенно ценно, когда ваш shift left еще недостаточно зрел или забуксовал в процессе интеграции. А для реализации такой защиты, базовой экспертизы нашего продукта более чем достаточно и это при том, что кейс не демонстрирует все ее возможности.
Пользуясь случаем приглашаю всех неравнодушных принять участие в разработке еще более продвинутых правил обнаружения для runtime-radar. Уверен, что вместе мы сможем сделать продукт еще эффективнее, а экспертизу точнее и шире.