Что в контейнере? Анализируем уязвимости, риски и методы защиты с помощью Kaspersky Container Security и его ИИ-ассистента KIRA

Введение

Контейнеризация с помощью Docker прочно вошла в стандарты современной разработки, значительно увеличив скорость и удобство развертывания различных сервисов. Зачастую разработчики используют уже готовые Docker-образы, внося в них минимальные изменения. Крупнейшим репозиторием образов контейнеров является сервис Docker Hub.

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

При этом инфраструктура внутри контейнеров, как правило, реже обновляется и может содержать устаревшие и уязвимые версии ПО. При развертывании сторонних образов или модификации их под свое окружение легко допустить ошибки конфигурации, которые могут быть использованы атакующими. А ввиду архитектурных особенностей контейнеров во время подготовки образов разработчик зачастую сталкивается с ограничениями, для преодоления которых может применить небезопасные решения, найденные в сети.

Иными словами, инфраструктура в контейнерах может оказаться одновременно наиболее простой и наиболее выгодной целью для эксплуатации. Поэтому ее безопасности нужно уделять повышенное внимание. Чтобы минимизировать риски успешных атак на инфраструктуру контейнеров, обязательно нужно проверять итоговые docker-образы, включая все нижестоящие слои, на наличие уязвимостей и ошибочных конфигураций. Это удобнее всего делать, анализируя Dockerfile, однако он не всегда доступен для проверки, более того — обычно он содержит правила по сборке надстройки над образом из внешнего репозитория, надежность которого нельзя гарантировать.

Результаты анализа образов в продукте Kaspersky Container Security

Для помощи пользователям в поиске небезопасных конфигураций и потенциальных уязвимостей в них мы добавили в продукт Kaspersky Container Security нашего AI-ассистента. KIRA (так зовут ассистента) проанализирует образ при помощи искусственного интеллекта и подскажет, какие потенциальные проблемы присутствуют в образе и как их можно исправить.

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

Уязвимости ПО и компрометация источников обновлений

Одной из ключевых проблем безопасности при использовании готовых образов является их несвоевременное обновление разработчиками. Образ Docker по своей сути является снимком определенного Linux-дистрибутива после установки в него пакетов. При этом в большинстве случаев он не получает обновлений безопасности самостоятельно, в отличие от традиционных Linux-серверов, где такие обновления автоматически устанавливают специализированные сервисы, например unattended-upgrades в дистрибутивах на базе Debian и dnf-automatic в дистрибутивах на базе RedHat.

Для применения обновлений к Docker-образу необходимо его пересобрать и развернуть заново. Зачастую этот процесс не автоматизирован, а некоторые обновления требуют дополнительных усилий для отладки корректности их работы, изменения конфигурации при обновлении на новые версии ПО и т. п. Как результат, многие популярные образы не получают своевременных обновлений, что значительно увеличивает риски при их использовании.

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

Доступные из интернета уязвимые версии веб-приложений и сетевых сервисов немедленно становятся целью различных вредоносных кампаний. Например, уже на следующий день после выявления уязвимости CVE-2025-55182 в React Server Components наши ханипоты зарегистрировали множество попыток атак, связанных с этой уязвимостью. Ее взяли на вооружение операторы многих вредоносных кампаний, от классических майнеров криптовалюты до вариантов Mirai и Gafgyt. Злоумышленники постоянно добавляют новые методы распространения и могут использовать десятки эксплойтов к различным уязвимостям и ошибкам конфигурации в популярных сервисах. Нередко те же самые уязвимости применяются в механизмах самораспространения с уже скомпрометированных хостов. Так, во вредоносной кампании по распространению майнера Dero атакующие используют зараженные контейнеры для автоматического поиска и инфицирования новых целей.

Помимо уязвимостей, которые можно эксплуатировать удаленно, злоумышленники быстро добавляют в свой арсенал локальные уязвимости, используемые для получения прав root и выхода из контейнера. Во вредоносной кампании Kinsing атакующие использовали для повышения прав CVE-2023-4911 (Looney Tunables), а в кампании perfctl с этой же целью применялась уязвимость CVE-2021-4034 (PwnKit). Полученный доступ использовался для установки руткита, скрывающего присутствие perfctl в системе.

Чтобы оценить ситуацию с незакрытыми уязвимостями в контейнерах, мы взяли случайную выборку из 100 образов, куда были включены различные популярные решения, имеющие от десяти тысяч до миллиона скачиваний на Docker Hub. В 64 просканированных нами образах были обнаружены устаревшие версии ПО с критическими уязвимостями. Например, в некоторых образах присутствовали: уязвимость CVE-2025-49844 в сервере Redis, приводящая к RCE за счет эксплуатации уязвимости в парсере Lua; актуальная уязвимость CVE-2026-24061 в nginx, в некоторых конфигурациях приводящая к падению процесса сервера, а при отключенном ASLR — опять же, к RCE; уязвимости CVE-2025-32463 в sudo и CVE-2023-4911 в glibc, позволяющие атакующему получить root при наличии локального доступа. При этом в полностью актуальном состоянии поддерживается только каждый десятый Docker-образ из анализируемой выборки.

TOP 10 критических уязвимостей, для которых есть PoC/эксплойт, в информационной панели Kaspersky Container Security

Стоит отметить, что, конечно, не каждая обнаруженная уязвимость может быть непосредственно использована атакующими. Практический риск возникает, когда уязвимое приложение или библиотека действительно используются и имеются необходимые для эксплуатации условия, которые сильно разнятся от уязвимости к уязвимости. Тем не менее игнорировать обновления нельзя, так как риск эксплуатации уязвимостей, как по отдельности, так и в различных связках, в каждом конкретном случае предсказать невозможно и даже на первый взгляд неопасные уязвимости могут в конечном итоге создать серьезный риск компрометации.

Рекордное количество уязвимостей в одном из образов

Однако у частых обновлений есть и обратная сторона. Каждая пересборка, которая загружает новые пакеты из исходных репозиториев, приводит к дополнительному риску попасть под атаку на цепочку поставок — скомпрометированная зависимость или измененный базовый образ могут незаметно внедрить вредоносный код в вашу среду именно через обновление. В ходе анализа образов из выборки мы не обнаружили признаков атак на цепочку поставок, но, например, в марте 2026-го подобный инцидент произошел с проектами Trivy и LiteLLM, при этом в случае Trivy зараженный файл был внедрен непосредственно в образ контейнера в официальных репозиториях.

Детектирование потенциально вредоносного ПО на примере одного из образов

Это приводит к сложному выбору: редкие обновления оставляют в контейнере неустраненные известные уязвимости, а частые — увеличивают риск компрометации цепочки поставок. Поэтому, чтобы защитить свою инфраструктуру, нужно не только регулярно обновлять базовые образы, но и более комплексно подходить к вопросу, в частности закреплять зависимости на заведомо исправных версиях, а при обновлении сканировать получившиеся образы на вредоносное ПО.

Уязвимости конфигурации

Даже контейнер с полностью обновленным образом может быть скомпрометирован, если его неправильно настроить. Встраивание ключей и секретов в образ, отключение аутентификации в сетевых сервисах, пароли по умолчанию, небезопасная конфигурация прав доступа к файлам — все это может так или иначе использоваться атакующими для достижения их целей.

Небезопасные конфигурации образов, обнаруженные KCS на основе правил

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

Для анализа проблемных конфигураций зачастую не хватает обычных правил. Чтобы глубже изучить контекст и оценить возможные риски, можно использовать средства ИИ. Далее в этом разделе мы рассмотрим примеры типичных небезопасных конфигураций, обнаруженных нами при сканировании публичных образов из Docker Hub, и выдаваемые ИИ-ассистентом KIRA описания проблем и методов снижения рисков.

Пример анализа контейнера с помощью KIRA

Небезопасная работа с учетными данными

Использование паролей по умолчанию

В некоторых случаях в контейнерах могут использоваться пароли по умолчанию, задаваемые через переменные окружения или напрямую в Dockerfile. Если такие пароли не будут переопределены, злоумышленники смогут получить доступ к приложению по стандартному паролю.

Согласно анализу KIRA, пароль пользователя в открытом виде сохраняется в истории слоев образа. Любой, кто получит доступ к образу (например, через публичный реестр или скомпрометированную сборочную среду), сможет его извлечь. Если в контейнере включен SSH или иной вид интерактивного доступа, это может привести к его полной компрометации и обеспечить злоумышленникам горизонтальное перемещение в инфраструктуре.

Пароли могут встречаться в переменных окружения. Рассмотрим следующий фрагмент Dockerfile:

В нем переменная окружения PKP_DB_PASSWORD задана как changeMePlease. Если пользователь забудет ее переопределить, приложение будет использовать пароль, который можно получить из Dockerfile.

Рассмотрим еще один образ:

Для него в Dockerfile указано, что пароль администратора прописан явно в ENV-инструкции и остается в метаданных образа (история слоев, docker inspect). Любой, кто получит доступ к образу (реестр, кэш сборки), сможет извлечь этот секрет и скомпрометировать учетную запись.

Чтобы исключить подобные риски, следует убедиться, что в Dockerfile не задаются никакие пароли. При необходимости аутентификации можно использовать механизмы оркестратора (secrets) или временную генерацию пароля при старте контейнера через скрипт entrypoint, без сохранения в слоях. Также мы рекомендуем использовать механизмы безопасной передачи секретов во время выполнения (Docker secrets, Kubernetes Secrets) или, при крайней необходимости, подключать их через --secret во время сборки с BuildKit — но ни в коем случае не оставлять в итоговом образе.

Передача паролей через аргументы команды

В некоторых случаях пароли могут быть раскрыты при их передаче через аргументы команды, так как эти аргументы видны всем пользователям в системе:

В приведенном примере пароль суперпользователя MySQL подставляется в команду healthcheck в открытом виде, что делает его видимым при просмотре списка процессов (ps aux), в логах аудита и системах мониторинга. Если злоумышленник получит доступ к чтению процессов контейнера или логам, он сможет извлечь пароль и получить полный контроль над базой данных.

Чтобы исправить эту ошибку, для healthcheck следует использовать локальное подключение через Unix-сокет с аутентификацией по умолчанию (если сконфигурирован плагин auth_socket для root), либо создать выделенного пользователя с минимальными привилегиями (например, только USAGE), без пароля или с паролем, передаваемым через защищенный файл (--defaults-file с ограниченными правами). Можно также применять для аутентификации healthcheck переменную окружения MYSQL_PWD, но она остается видимой в /proc.

Повышение привилегий в контейнере

Одним из наиболее распространенных векторов первичной компрометации Linux-систем является RCE в веб-приложениях и сетевых сервисах. Обычно такие сервисы имеют минимальные права, что значительно усложняет злоумышленникам их дальнейшие действия: дампинг учетных данных, сокрытие следов своей активности, попытки выхода из контейнера и многие другие.

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

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

Атаки на sudo

Одним из самых простых методов повышения прав является выполнение произвольных команд от имени root без ввода пароля с помощью sudo. Рассмотрим следующий образ:

Анализ такого образа с помощью KIRA сразу подсвечивает основную проблему: установка пакета sudo и настройка NOPASSWD: ALL для пользователя solr грубо нарушает принцип наименьших привилегий. В контейнере для работы платформы Solr не требуются настолько широкие права, зато они создают легкий путь повышения привилегий до root.

В другом примере небезопасной конфигурации права NOPASSWD:ALL выдаются пользователю базы данных PostgreSQL — это прямое и грубое ослабление политики разграничения доступа. Если злоумышленник получит возможность выполнить код от имени пользователя postgres (например, через уязвимость в сетевом сервисе, SQL-инъекцию или компрометацию одного из процессов), он немедленно и без дополнительных условий сможет исполнять любые команды от имени пользователя root. Это эквивалентно работе всего контейнера под root.

В качестве мер для снижения рисков мы предлагаем полностью удалить эту директиву. Минимально необходимые команды, требующие привилегий, следует делегировать точечно через sudoers с явным указанием разрешенных исполняемых файлов и параметров, используя NOPASSWD только в крайнем случае и для конкретных утилит.

Наш ИИ-ассистент KIRA может определить и более сложные небезопасные конфигурации, например разрешение беспарольного sudo для всей группы sudo (модификация существующих правил).

Риск в этом примере состоит в том, что команда заменяет стандартные декларации, требующие аутентификации, на беспарольное выполнение всех команд для любого пользователя, входящего в группу sudo (в том числе, возможно, для postgres, если он туда попадет). Это расширяет поверхность атаки на всех членов группы, превращая каждого из них в потенциальную точку мгновенного повышения привилегий.

Для снижения рисков рекомендуем не изменять глобальную политику sudoers, оставить стандартное требование пароля либо использовать более безопасный механизм эскалации (например, gosu для запуска конкретного процесса от имени другого пользователя без постоянных привилегий).

Небезопасные права на файлы

Еще один распространенный вектор повышения прав — небезопасно настроенные права на файлы и директории. Чаще всего для удобства авторы образов контейнеров используют права 777, позволяющие любому, в том числе непривилегированному пользователю, свободно создавать и удалять файлы, а также менять их содержимое. Это может приводить как к повышению прав, так и к возможности удаления или модификации логов непривилегированным злоумышленником и к другим неприятным последствиям.

Рассмотрим следующую команду:

Она создает риск того, что каталоги, содержащие бинарные файлы и скрипты, станут доступными для записи любому пользователю контейнера. Это позволяет атакующему с низкими привилегиями подменить утилиты, входящие в состав cargo, или добавить новые вредоносные исполняемые файлы. При последующем вызове этих инструментов (особенно от имени пользователя root или через sudo) будет выполняться код злоумышленника с унаследованными привилегиями вызывающего процесса, что напрямую ведет к локальному повышению привилегий.

Для снижения рисков можно установить минимально необходимые права: chmod 0755 на директории и chmod 0755/0644 на соответствующие файлы. Владельцем должен быть root, запись разрешена только владельцу. Не следует применять chmod 777 ни к одному системному пути.

Отсутствие контроля целостности

Загрузка ПО без контроля его целостности может сделать инфраструктуру уязвимой к подмене ПО.

Например, такой риск может возникнуть при скачивании дистрибутива по протоколу HTTP:

Использование протокола HTTP без проверки целостности архива создает условия для атаки Man-in-the-Middle на этапе сборки образа. Злоумышленник, контролирующий канал связи или DNS, может подменить архив вредоносным содержимым, что приведет к компрометации контейнера и всего окружения, в котором он будет запущен.

Для снижения рисков можно настроить подключение к веб-ресурсам только по HTTPS (если ресурс поддерживает этот протокол). Также можно скачивать архив без распаковки, сравнивать его контрольную сумму (SHA256) с контрольной суммой из доверенного источника и только после этого распаковывать. Желательно размещать проверенный архив во внутреннем репозитории артефактов, исключая прямые загрузки из сети.

Риск MitM будет и при отключении проверки сертификата:

Отсутствие проверки TLS-сертификата позволяет злоумышленнику, контролирующему сетевой сегмент, подменить загружаемый ZIP-архив вредоносным содержимым. Поскольку архив содержит PHP-код, который будет выполняться веб-сервером, компрометация на этапе сборки приведет к развертыванию бэкдора или утечке данных.

Для снижения рисков необходимо убрать флаг --no-check-certificate, после загрузки вычислить SHA256-хэш архива и сверить с заранее известным эталонным значением (например, из релизной страницы или локального хранилища доверенных хэшей). Дополнительно следует рассмотреть возможность использования фиксированного релиза (тэга), а не скользящей ветки 7.2-dev.

Заключение

Контейнеры Docker стали очень популярным средством для развертывания программного обеспечения, и злоумышленники не оставили это без внимания. Они оперативно добавляют в свой арсенал уязвимости в ПО и ошибки в конфигурации, совершают атаки на цепочки поставок. Скомпрометировать контейнерную инфраструктуру могут с самыми разными целями — от майнинга криптовалюты до шифрования данных с целью получения выкупа или кражи критичной для компании информации.

Как показало наше исследование, 64 из 100 образов контейнеров с популярными приложениями содержат ПО с критическими уязвимостями, и лишь 10% полностью актуальны. Также выявлены множественные небезопасные конфигурации, в том числе пароли, хранящиеся в Dockerfile в открытом виде, чрезмерные привилегии у пользователей и процессов.

Для обнаружения и предотвращения подобных угроз необходимо тщательно соблюдать меры безопасности: проводить аудит конфигурации образов, безопасно управлять используемыми в образах секретами, своевременно применять обновления безопасности, сканировать их содержимое на вредоносное ПО при каждом обновлении и использовать принятые в индустрии лучшие практики повышения безопасности.

Такой подход требует специализированных решений, учитывающих специфику контейнерных сред. Решение Kaspersky Container Security обеспечивает безопасность контейнерных приложений на всех этапах жизненного цикла: от разработки до эксплуатации. Продукт защищает бизнес-процессы организации, помогает соответствовать отраслевым стандартам и нормам безопасности, а также реализовать принцип безопасной разработки ПО.