На последней кибербитве Standoff 12, которая проходила в ноябре 2023 года, впервые был представлен вымышленный финтех — Global Digital Bank, максимально автоматизированный, с облачными приложениями на основе микросервисов «под капотом». Задачей команд атаки (red team) было реализовать недопустимые события, в случае с финтехом — остановить работу банка, выкрасть базу данных клиентов, взломать новостной портал. Назначение PT Container Security — защитить контейнерные среды и помочь синим командам отследить действия атакующих. Что из этого получилось? Рассказываем!
Global Digital Bank
Все банковские приложения Global Digital Bank работают в контейнерах — изолированных экземплярах пространства пользователя на одном ядре ОС.
Стек задач red team:
-
Получить доступ к административной панели Kubernetes (control plane).
-
Выполнить вредоносный код в контейнере Kubernetes (получить шелл в поде с сервисом банка).
-
Реализовать утечку данных клиентов Global Digital Bank.
Контейнерные технологии, такие как Docker и Kubernetes, — это основа процессов DevOps. По результатам опроса CNCF Annual Survey 2022, уже около 81% организаций в каком-либо виде используют контейнеризацию. При этом, если проанализировать информацию из открытых источников, почти в каждой компании сталкивались с атаками на контейнеры.
За чем мы наблюдали
Целью «красных» было исследовать инфраструктуру кластера Kubernetes и выполнить атаки на его микросервисы. Всего мы проанализировали 480 618 036 событий, собранных за первые три дня мероприятия, среди них — 21 974 срабатываний наших детекторов. На начальном этапе подготовили несколько детекторов (которые впоследствии расширили по результатам разбора событий) для выявления:
-
подозрительных подключений к СУБД;
-
эскалации привилегий;
-
отладки внутри контейнера (ptrace).
С их помощью нам удалось не потонуть в тысячах событий, которые появились после начала кибербитвы, и подготовить еще один детектор — для выявления популярных инструментов, используемых в атаках на контейнеры и Kubernetes.
Обнаруженные скрипты запуска реверс-шеллов
До того как попасть в контейнер, исследователям нужно было захватить управление им. Мы внимательно следили за этим, используя политику мониторинга системного вызова TCP connect, — за время Standoff 12 зарегистрировали 2000 уникальных попыток установить реверс-шелл с использованием как кода на Python, так и других инструментов. Но и тут мы получили больше: проанализировав использованные команды и аргументы, выявили запросы на загрузку инструментария внутрь контейнеров.
Реверс-шеллы по командам выполнения
Однако факт использования таких команд не дает достаточной информации о том, что происходило в системе (об этом расскажем чуть позже) и откуда шла атака. Использование технологии eBPF позволяет нам отслеживать не только команды создания обратных туннелей, но и события с информацией о сетевых соединениях с контейнерами. Таким образом мы смогли определить, с каких IP-адресов устанавливались соединения с уязвимым контейнером, что дало нам возможность дойти до конкретных узлов из подсетей красных команд — отследить атаку до конечного узла.
Реверс-шеллы по IP-адресу назначения
Кроме того, можно выявить взаимодействия с С2-серверами. Отфильтровав данные по конкретной подсети, мы видим более точную картинку: например, взаимодействия с внешними сетями. В дальнейшем такие подключения можно проверить с использованием репутационных баз, например через сервис PT Threat Analyzer.
Внешние подключения из кластера
Доставка
Попав в среду выполнения контейнера, исследователь в первую очередь должен понять, где находится, собрать информацию об инфраструктуре. Для этого команды использовали и уже существующие средства для разведки внутри контейнеров, и самописные поисковые скрипты. Нашей командой был оперативно подготовлен детектор для выявления таких инструментов, и у нас получилось собрать статистику их применения. На наше удивление, Peirates, трендовая утилита для анализа безопасности контейнеров, не пользовалась популярностью у участников Standoff. Наиболее очевидным и одним из самых используемых способов ожидаемо оказался анализ переменных окружения, однако некоторые исследователи применяли и совсем не профильные инструменты, как, например, LinPEAS. Для обнаружения таких действий в дальнейшем наша команда расширила уже упомянутый детектор. Итоговая статистика, которую мы смогли собрать с его помощью, представлена ниже.
Потенциально опасные инструменты
Можно возразить, что при попытках злоумышленника маскировать свои действия такой подход не сработает. Как правило, такое возражение справедливо при использовании в анализе событий сигнатурных подходов, например по именам бинарных файлов известных вредоносных программ. Однако при низкоуровневом подходе, мониторя такие компоненты ядра Linux, как kernel probe, syscall, tracepoint, и адаптируя политики под работу контейнеризированных приложений, можно добиться необходимого уровня безопасности контейнерной инфраструктуры.
Выполнение и извлечение
При мониторинге контейнеров много внимания уделяется поведенческим подходам, упор делается на наблюдаемость (observability), выявление аномалий. Обсуждаются также подходы, в которых используется машинное обучение. Однако, с нашей точки зрения, мало значения придается анализу политик мониторинга ядра на базе eBPF, анализу паттернов атак и настройке периодичности профилирования микросервисов.
В качестве примера рассмотрим один из контейнеров с нашего стенда на Standoff 12. Напомним, что профиль снимался в течение трех дней. Мы отслеживали:
-
TCP-подключения из контейнеров;
-
файловую активность внутри контейнеров (в критически значимых файлах в каталогах etc, opt, dev, var, proc);
-
запуск процессов в контейнерах;
-
использование механизмов повышения привилегий.
Что же у нас получилось?
Дерево процессов, запущенных в контейнере за три дня
Для отображения нам потребовалось ограничиться 10 000 уникальными событиями. Как мы видим, даже для одного активно работающего контейнера (не пытайтесь повторить это дома), а тем более — для находящегося в среде постоянно подверженной внешнему воздействию исследователей, может возникнуть ситуация, когда потребуется ряд усилий, чтобы определить паттерны легитимного поведения. Алгоритмам машинного обучения в такой ситуации потребуется больше времени на создание модели.
Что, если мы упростим задачу, используя сигнатурный подход?
Построим граф только для тех событий, которые были зафиксированы детекторами, и проанализируем результат. Для примера возьмем события от детектора, выявляющего подозрительные подключения к базе данных в контейнерах. Это позволит нам построить цепочку событий, которые предшествовали соединению, начиная от подключения с использованием Chisel и заканчивая установкой реверс-шелла из родительского процесса контейнера.
Дерево процессов для событий, обнаруженных детекторами на Standoff 12 (схема в полном размере доступна здесь )
Как можно увидеть, получившийся граф — большой. Перерисуем его часть, в которой исследователи использовали инструмент Chisel, обозначив ребра бинарными файлами и их аргументами, чтобы посмотреть на активность внутри контейнера и оценить ее с точки зрения легитимности.
Аргументы процессов в контейнерах
Теперь граф значительно проще анализировать — можно получить как данные для отчета о расследовании (бизнес-результат аналитики ИБ), так и дополнительные артефакты в виде новых сигнатур для детектирования недопустимых событий (например, использования инструмента Chisel, Nmap, установки реверс-шелла).
Цель статьи — не показать превосходство одного или другого метода выявления атак над другими, а продемонстрировать возможности нашего инструмента и призвать сообщество к совместному развитию практик защиты контейнеров.
В своем продукте — PT Container Security — мы объединяем подходы по безопасности контейнеризации в одной системе, а не зацикливаемся на каком-то одном.
Защитники могут быстро, на ходу, дополнять экспертизу в продукте, реализуя сложные сценарии выявления атак на контейнеры. Мы используем технологии, которые позволят интегрировать PT Container Security с инструментами безопасности контейнеров (создавать кастомные правила, запрашивать контекстную информацию об образах и контейнерах, подключать сторонние eBPF-сенсоры) и с существующей инфраструктурой ИБ (отправлять события в SOC, встраиваться в DevSecOps-пайплайны и взаимодействовать с системами оркестрации).
Михаил Бессараб, Руководитель продукта PT Container Security
