Вы думаете, это база для CI. А это — инструмент проникновения уровня ЦРУ
NewsMakerОдин бит из 2024 года — и ваш DevOps в слезах.
Бэкдор в библиотеке XZ-Utils , обнаруженный в марте 2024 года и признанный одной из самых серьёзных атак на цепочку поставок ПО за последние годы, до сих пор остаётся в открытом доступе на Docker Hub. Специалисты Binarly нашли как минимум 35 Linux-образов, содержащих заражённую версию библиотеки, что создаёт серьёзные риски для инфраструктур, которые автоматически подтягивают эти контейнеры.
Docker Hub — официальный публичный репозиторий контейнеров, которым активно пользуются разработчики и DevOps-команды по всему миру. Многие системы непрерывной интеграции ( CI/CD ) и сборки в продакшне опираются на образы из Docker Hub в качестве базовых слоёв. Если образ содержит вредоносный компонент, все созданные на его основе сборки становятся потенциально скомпрометированными — даже если пользователь не подозревает об угрозе.
Binarly подчёркивает, что масштабы проблемы могут быть куда серьёзнее: они исследовали только ограниченное количество образов, не включая в сканирование всю платформу. И всё же даже в рамках этого частичного анализа были найдены десятки заражённых контейнеров, причём часть из них не просто осталась доступной для загрузки, а стала основой для других сборок — которые также получили вредоносную нагрузку транзитивно, по цепочке.
XZ-Utils — популярный инструмент для сжатия данных в Linux , и его компонент liblzma.so в версиях 5.6.0 и 5.6.1 был модифицирован таким образом, чтобы внедрять вредоносный код через механизм IFUNC в glibc. Это позволяло перехватывать вызовы RSA_public_decrypt в OpenSSH . Если злоумышленник подключался по SSH к уязвимому контейнеру и использовал специальный приватный ключ, он получал полный root-доступ без аутентификации. Такой подход требовал предельно точной настройки, но сам факт его наличия ставил под угрозу любой контейнер с включённым SSH.
Код внедрил разработчик под псевдонимом Jia Tan, который долгое время считался надёжным участником проекта. Его коммиты прошли проверку и попали в релизные пакеты крупнейших дистрибутивов: Debian , Fedora , OpenSUSE и Red Hat. Быстрое обнаружение уязвимости ограничило окно для возможных атак, а компании вроде Binarly и Kaspersky выпустили сканеры для поиска заражённых экземпляров.
Однако в случае с Docker Hub ситуация остаётся тревожной. Debian, несмотря на уведомление от Binarly, отказался удалять старые образы с бэкдором , сославшись на низкий риск и необходимость сохранять «архивные артефакты». Представители Debian считают, что эксплойт возможен только в случае, если в контейнере запущен SSH-сервер , он доступен извне, а злоумышленник обладает специфическим ключом. Тем не менее, Binarly не согласны с этим подходом. Они указывают, что даже пассивное наличие таких образов может привести к их случайному использованию — особенно в автоматических сборках, где старая версия может быть подтянута как зависимость.
Отказ от удаления заражённых образов ставит под угрозу пользователей, не подозревающих об их наличии. Тем более что вредоносный код остаётся скрытым и не проявляет себя до момента активации. Единственным надёжным способом защиты остаётся ручная проверка версии библиотеки liblzma. Безопасной считается только версия 5.6.2 и выше, включая актуальную 5.8.1. Всё, что ниже — потенциальный риск.
Бэкдор в библиотеке XZ-Utils , обнаруженный в марте 2024 года и признанный одной из самых серьёзных атак на цепочку поставок ПО за последние годы, до сих пор остаётся в открытом доступе на Docker Hub. Специалисты Binarly нашли как минимум 35 Linux-образов, содержащих заражённую версию библиотеки, что создаёт серьёзные риски для инфраструктур, которые автоматически подтягивают эти контейнеры.
Docker Hub — официальный публичный репозиторий контейнеров, которым активно пользуются разработчики и DevOps-команды по всему миру. Многие системы непрерывной интеграции ( CI/CD ) и сборки в продакшне опираются на образы из Docker Hub в качестве базовых слоёв. Если образ содержит вредоносный компонент, все созданные на его основе сборки становятся потенциально скомпрометированными — даже если пользователь не подозревает об угрозе.
Binarly подчёркивает, что масштабы проблемы могут быть куда серьёзнее: они исследовали только ограниченное количество образов, не включая в сканирование всю платформу. И всё же даже в рамках этого частичного анализа были найдены десятки заражённых контейнеров, причём часть из них не просто осталась доступной для загрузки, а стала основой для других сборок — которые также получили вредоносную нагрузку транзитивно, по цепочке.
XZ-Utils — популярный инструмент для сжатия данных в Linux , и его компонент liblzma.so в версиях 5.6.0 и 5.6.1 был модифицирован таким образом, чтобы внедрять вредоносный код через механизм IFUNC в glibc. Это позволяло перехватывать вызовы RSA_public_decrypt в OpenSSH . Если злоумышленник подключался по SSH к уязвимому контейнеру и использовал специальный приватный ключ, он получал полный root-доступ без аутентификации. Такой подход требовал предельно точной настройки, но сам факт его наличия ставил под угрозу любой контейнер с включённым SSH.
Код внедрил разработчик под псевдонимом Jia Tan, который долгое время считался надёжным участником проекта. Его коммиты прошли проверку и попали в релизные пакеты крупнейших дистрибутивов: Debian , Fedora , OpenSUSE и Red Hat. Быстрое обнаружение уязвимости ограничило окно для возможных атак, а компании вроде Binarly и Kaspersky выпустили сканеры для поиска заражённых экземпляров.
Однако в случае с Docker Hub ситуация остаётся тревожной. Debian, несмотря на уведомление от Binarly, отказался удалять старые образы с бэкдором , сославшись на низкий риск и необходимость сохранять «архивные артефакты». Представители Debian считают, что эксплойт возможен только в случае, если в контейнере запущен SSH-сервер , он доступен извне, а злоумышленник обладает специфическим ключом. Тем не менее, Binarly не согласны с этим подходом. Они указывают, что даже пассивное наличие таких образов может привести к их случайному использованию — особенно в автоматических сборках, где старая версия может быть подтянута как зависимость.
Отказ от удаления заражённых образов ставит под угрозу пользователей, не подозревающих об их наличии. Тем более что вредоносный код остаётся скрытым и не проявляет себя до момента активации. Единственным надёжным способом защиты остаётся ручная проверка версии библиотеки liblzma. Безопасной считается только версия 5.6.2 и выше, включая актуальную 5.8.1. Всё, что ниже — потенциальный риск.