На последней кибербитве 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-адресов устанавливались соединения с уязвимым контейнером, что дало нам возможность дойти до конкретных узлов из подсетей красных команд — отследить атаку до конечного узла.
Кроме того, можно выявить взаимодействия с С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 и заканчивая установкой реверс-шелла из родительского процесса контейнера.
Как можно увидеть, получившийся граф — большой. Перерисуем его часть, в которой исследователи использовали инструмент Chisel, обозначив ребра бинарными файлами и их аргументами, чтобы посмотреть на активность внутри контейнера и оценить ее с точки зрения легитимности.
Теперь граф значительно проще анализировать — можно получить как данные для отчета о расследовании (бизнес-результат аналитики ИБ), так и дополнительные артефакты в виде новых сигнатур для детектирования недопустимых событий (например, использования инструмента Chisel, Nmap, установки реверс-шелла).
Цель статьи — не показать превосходство одного или другого метода выявления атак над другими, а продемонстрировать возможности нашего инструмента и призвать сообщество к совместному развитию практик защиты контейнеров.
В своем продукте — PT Container Security — мы объединяем подходы по безопасности контейнеризации в одной системе, а не зацикливаемся на каком-то одном.
Защитники могут быстро, на ходу, дополнять экспертизу в продукте, реализуя сложные сценарии выявления атак на контейнеры. Мы используем технологии, которые позволят интегрировать PT Container Security с инструментами безопасности контейнеров (создавать кастомные правила, запрашивать контекстную информацию об образах и контейнерах, подключать сторонние eBPF-сенсоры) и с существующей инфраструктурой ИБ (отправлять события в SOC, встраиваться в DevSecOps-пайплайны и взаимодействовать с системами оркестрации).
Михаил Бессараб
Руководитель продукта PT Container Security