Инцидент SolarWinds в контейнерном мире
Неприятная история случилась с Kong Ingress Controller (довольно популярный Ingress Controller для Kubernetes, поставляется в виде docker образа) в конце прошлого года – в прод попал образ, содержащий в себе майнер XMRig. Эта история сильно напоминает инцидент с SolarWinds, который случился в 2020 году. Тогда злоумышленники снабдили платформу Orion для Windows, предназначенную для централизованного мониторинга и управления, вредоносным обновлением. В результате множество клиентов SolarWinds установили зараженную версию платформы и, сами того не зная, впустили хакеров в свои сети.
Мы решили подсветить кейс с Kong Ingress Controller через призму Luntry и показать наши возможности, как мы это уже делали с инцидентом в xz-utils, прогремевшем в прошлом году. Но для начала восстановим таймлайн.
- 1. 28 августа 2024 года разработчики из Kong исправляют свои пайплайны меняя pull_request на pull_request_target
- 2. 25 ноября 2024 года они получают анонимный отчет от исследователя безопасности о том, что их репозиторий подвержен атаке Pwn request. После этого мейнтейнеры провели ротацию всех секретов в репозитории и вернули триггерное событие обратно на pull_request. Но только для главной ветки. Так что старые неиспользуемые ветки продолжили использовать pull_request_target, а значит были уязвимы.
- 3. Спустя почти два месяца, а именно 23 декабря 2024 года атакующие начали разведку – они получили доступ к секретам, в том числе к персональному токену доступа GitHub, проэксплуатировав уязвимость в одном из репозиториев.
- 4. Примерно через 22 часа – 24 декабря злоумышленники перешли на основной репозиторий с полученным на предудыщем шаге access token. Они запушили образ io/kong/kubernetes-ingress-controller на Dockerhub с тегом 3.4.
- 5. 29 декабря 2024 года 4 пользователя отметили в issue на GitHub, что запуск Kong Ingress Controller приводит к аномально высокой нагрузке на CPU.
- 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. Безопасность цепочки поставки становится все актуальнее и на нее нужно обращать внимание. Так как даже легитимные компоненты могут нести вредоносную функциональность или содержать НДВ (недекларированные возможности).
- 2. Для обеспечения безопасности цепочки поставки нужно использовать комплексный подход контроля на всех жизненных стадиях приложения: от сборки до запуска в runtime.
- 3. Решение Luntry предоставляет полный перечень механизмов для контроля безопасности микросервисных приложений с гибкими возможностями настройки под себя: от создания собственных правил детектирования до формирования моделей поведения.
Узнать больше об использовании Luntry для расследования инцидентов и контроля Kubernetes-ресурсов можно в нашем Telegram-канале. Подписывайтесь, чтобы узнавать актуальные новости о безопасности контейнерных сред.