Инцидент SolarWinds в контейнерном мире

Конференция по БЕзопасности

КОНтейнеров и контейнерных сред

5 июня

Организатор
Блог
Новости, прогрессивные идеи и рекомендации по обеспечению безопасности в инфраструктуре Kubernetes
9.2.2025

Инцидент SolarWinds в контейнерном мире

Неприятная история случилась с Kong Ingress Controller (довольно популярный Ingress Controller для Kubernetes, поставляется в виде docker образа) в конце прошлого года – в прод попал образ, содержащий в себе майнер XMRig. Эта история сильно напоминает инцидент с SolarWinds, который случился в 2020 году. Тогда злоумышленники снаб­дили плат­форму Orion для Windows, пред­назна­чен­ную для цен­тра­лизо­ван­ного монито­рин­га и управле­ния, вре­донос­ным обновле­нием. В резуль­тате мно­жес­тво кли­ентов SolarWinds уста­нови­ли заражен­ную вер­сию плат­формы и, сами того не зная, впус­тили хакеров в свои сети.

Мы решили подсветить кейс с Kong Ingress Controller через призму Luntry и показать наши возможности, как мы это уже делали с инцидентом в xz-utils, прогремевшем в прошлом году. Но для начала восстановим таймлайн.

  1. 1. 28 августа 2024 года разработчики из Kong исправляют свои пайплайны меняя pull_request на pull_request_target
  2. 2. 25 ноября 2024 года они получают анонимный отчет от исследователя безопасности о том, что их репозиторий подвержен атаке Pwn request. После этого мейнтейнеры провели ротацию всех секретов в репозитории и вернули триггерное событие обратно на pull_request. Но только для главной ветки. Так что старые неиспользуемые ветки продолжили использовать pull_request_target, а значит были уязвимы.
  3. 3. Спустя почти два месяца, а именно 23 декабря 2024 года атакующие начали разведку – они получили доступ к секретам, в том числе к персональному токену доступа GitHub, проэксплуатировав уязвимость в одном из репозиториев.
  4. 4. Примерно через 22 часа – 24 декабря злоумышленники перешли на основной репозиторий с полученным на предудыщем шаге access token. Они запушили образ io/kong/kubernetes-ingress-controller на Dockerhub с тегом 3.4.
  5. 5. 29 декабря 2024 года 4 пользователя отметили в issue на GitHub, что запуск Kong Ingress Controller приводит к аномально высокой нагрузке на CPU.
  6. 6. 2 января 2025 мейнтейнеры подтвердили, что образ был скомпрометирован, а вунтри него содержался XMRig.

Более подробно о всей ситуации можно почитать в блоге KIC по ссылке. Также было опубликовано YARA правило для обнаружения таких нагрузок.

Воспроизведение окружения

Мы хотели воспроизвести это у себя, но столкнулись с некоторыми сложностями. В ходе расследования образ был удален, и в публичном доступе найти его не представлялось возможным. Однако, авторы поделились YARA правилом для обнаружения вредоносной версии. В самом правиле они оставили хэш:

rule u42_crime_win_kongtrojan : critical
{
    meta:
        author = "Kong"
        date = "2025-01-09"
        description = "Detects the trojanized Kong manager binary."
        hash = "e164e6e21c661679c556d16638300c25e16d86bb2d567ad66b4181f1a65f4788"
    strings:
        $golang = "golang.org"
        $v1 = "Kong does not care about security"
        $v2 = "KongIngress"
        $v3 = "f0VMR"  // start of b64 XMrig
    condition:
        $golang and (all of ($v*))
}

По этому хэшу файл достаточно легко ищется на Virus Total:

Стоит отметить, что злоумышленники модифицировали оригинальный код, таким образом чтобы прекомпилированный майнер загружался напрямую в память, используя memfd.

Из интересного, атакующие оставили пасхалку для всех, кто посмотрит логи контейнера, запущенного на базе вредоносного образа:

info setup Starting controller manager. Kong does not care about security. {"v": 0, "release": "3.4.0", "repo": "https://github.com/kong/kubernetes-ingress-controller.git", "commit": "92a6761ac1c94ecd202571cbf84de860336664f3"}

Скачав бинарь с VT, нам осталось воспроизвести оригинальный образ. Для этого обратимся к Dockerfile из репозитория kubernetes-ingress-controlller. Этапы сборки самого бинаря нам не интересны, так что можем их пропустить. Останавливаемся на последнем этапе и подменяем в Dockerfile инструкцию COPY, так чтобы там оказался вредоносная нагрузка с VT. Итоговый Dockerfile будет выглядеть так:

FROM gcr.io/distroless/static:nonroot@sha256:6ec5aa99dc335666e79dc64e4a6c8b89c33a543a1967f20d360922a80dd21f02
WORKDIR /
COPY manager .
USER 1000:1000
ENTRYPOINT ["/manager"]

Взгляд Luntry

Теперь мы можем собрать образ, запушить его в registry и посмотреть на него в интерфейсе Luntry. Для начала перейдем на вкладку Settings->Registry и добавим новый registry.

Заполним необходимые поля и нажмем кнопку “Test”, чтобы проверить соединение с Registry. Мы получили сообщение Success, а значит можно добавлять Registry и двигаться дальше.

Далее переходим на вкладку Settings->Scheduler и задаем настройки сканирования по расписанию для конкретного образа в интересующем нас Registry.

Помимо создания SBOM, сканирования на известные уязвимости, мисконфигурации, чувствительную информацию в образах, в Luntry, есть также функциональность для поиска вредоносных файлов и файлов двойного назначения, которая сделана специально с учетом Linux и контейнерной специфики. Это сделано для того, чтобы негативно не влиять на рабочее окружение и пользовательские приложения. Эта возможность базируется на YARA правилах, где можно использовать как наш собственный feed, так и добавлять собственные проверки.

Для того чтобы добавить свое YARA правило необходимо перейти на вкладку Settings->Malware и выбрать “Add rule +”. Теперь необходимо указать некоторые метаданные, а также MD5 hash для определения вредоносной нагрузки.

После запуска сканирования по расписанию результаты сканирования можно посмотреть на вкладке Images -> Registry Images

Ранее мы уже упоминали о том, что злоумышленники используют memfd для запуска майнера. memfd (memory file descriptor) — это механизм в Linux, позволяющий создавать анонимные временные файлы в оперативной памяти, которые не отображаются в файловой системе. Эти файлы создаются с помощью системного вызова memfd_create, поддерживаемого начиная с ядра Linux 3.17, и предоставляют удобный способ работы с данными как с файловыми объектами без записи их на диск. Файлы, созданные с помощью memfd, автоматически удаляются при закрытии дескриптора. Использование такого способа запуска процесса (прямиком из памяти) позволяет обойти большинство традиционных антивирусных решений, поэтому пользуется популярностью у злоумышленников, например при Fileless Attack. Важно понимать, что легитимное ПО вряд ли будет использовать этот механизм.

В Luntry, использование memfd можно обнаружить как на базе поведенческого движка, так и на базе сигнатурных правил. Так это выглядит в нашей модели поведения, обученной на вредоносном образе:

А так выглядит модель поведения оригинального образа:

 

Выводы:

  1. 1. Безопасность цепочки поставки становится все актуальнее и на нее нужно обращать внимание. Так как даже легитимные компоненты могут нести вредоносную функциональность или содержать НДВ (недекларированные возможности).
  2. 2. Для обеспечения безопасности цепочки поставки нужно использовать комплексный подход контроля на всех жизненных стадиях приложения: от сборки до запуска в runtime.
  3. 3. Решение Luntry предоставляет полный перечень механизмов для контроля безопасности микросервисных приложений с гибкими возможностями настройки под себя: от создания собственных правил детектирования до формирования моделей поведения.

Узнать больше об использовании Luntry для расследования инцидентов и контроля Kubernetes-ресурсов можно в нашем Telegram-канале. Подписывайтесь, чтобы узнавать актуальные новости о безопасности контейнерных сред.

Читать по теме
15.6.2023

20 июня состоится вебинар «Безопасность K8s на практике: возможности и инструменты». В рамках мероприятия Алексей Волков, менеджер продукта VK Cloud, и Дмитрий Евдокимов, основатель и технический директор Luntry, обсудят новые возможности Kubernetes as a Service в VK Cloud, безопасный запуск приложения в Kubernetes, а также продвинутые инструменты контроля безопасности, такие как Runtime Security и соответствие прав доступа […]

4 и 5 марта в Москве состоится DevOpsConf 2024 — конференция для инженеров и всех, кто должен понимать инженеров. В ней примет участие основатель и технический директор Luntry Дмитрий Евдокимов с докладом «Безопасность Kubernetes кластеров: вредные советы». 4 марта в 15:50 вы узнаете, как на самом деле эффективно и безопасно работать с Kubernetes-кластерами сегодня и […]

Хотите быть в курсе последних обновлений?

Подпишитесь на наш блог, тогда вы точно ничего не пропустите!

    *Нажимая на кнопку, я даю согласие на обработку моих персональных данных
    Используя данный сайт, вы даете свое согласие на использование файлов cookies, помогающих сделать его удобнее для вас. Подробнее
    ОК