<div id="post_message_809303">

Аналитики компании Binarly <a href="https://www.binarly.io/blog/persistent-risk-xz-utils-backdoor-still-lurking-in-docker-images" target="_blank">обнаружили </a>в Docker Hub не менее 35 образов, до сих пор зараженных бэкдором, который еще в прошлом году проник в xz Utils. Исследователи предупредили, что это потенциально подвергает риску пользователей, организации и их данные.<br/>
<br/>
В Binarly объясняют, что многие CI/CD-пайплайны, разработчики и производственные системы извлекают образы непосредственно с Docker Hub, используя их как базу для своих собственных контейнеров. Если эти образы скомпрометированы, каждая новая сборка будет наследовать уязвимость или вредоносный код.<br/>
<br/>
Напомним, что бэкдор в составе популярного пакета xz Utils был <a href="https://xakep.ru/2024/04/01/xz-utils-backdoor/" target="_blank">случайно обнаружен</a> в 2024 году, и этот инцидент получил большой резонанс. В итоге проблеме присвоили идентификатор <a href="https://nvd.nist.gov/vuln/detail/CVE-2024-3094" target="_blank">CVE-2024-3094</a>, и она получила 10 баллов из 10 возможных по шкале CVSS.<br/>
<br/>
Так как xz Utils и входящая в его состав библиотека liblzma очень популярны и включены в большинство дистрибутивов Linux (а также используется множеством приложений для Linux и macOS), обнаружение малвари взбудоражило все опенсорсное сообщество.<br/>
<br/>
Проведенное в прошлом году расследование показало, что операция по внедрению бэкдора была тщательно спланирована и длилась несколько лет, а злоумышленники долго планировали свою атаку и втирались в доверие к сопровождающему xz Utils, Лассе Коллину (Lasse Collin aka Larhzu).<br/>
<br/>
Бэкдор перехватывал и перенаправлял операции расшифровки ключей SSH RSA (функцию <a href="https://www.openssl.org/docs/manmaster/man3/RSA_public_decrypt.html" target="_blank">RSA_public_decrypt</a>) в OpenSSH через механизм IFUNC библиотеки glibc. В результате, если атакующий со специальным приватным ключом подключался по SSH к зараженной системе, он имел возможность обойти аутентификацию и удаленно выполнять команды с правами root.<br/>
<br/>
Так как вредоносный код в итоге поставлялся в официальных пакетах Linux-дистрибутивов (например, Debian, Fedora, OpenSUSE и Red Hat), заражение xz Utils стало одной из самых серьезных компрометаций прошлого года.<br/>
<br/>
Как сообщили на этой неделе специалисты Binarly, проблемы в цепочке поставок, вызванные заражением xz Utils, актуальны и сейчас, так как в Docker Hub по-прежнему присутствуют десятки зараженных образов.<br/>
<br/>
<div style="margin:20px; margin-top:5px; ">
<!-- <div class="smallfont" style="margin-bottom:2px">Quote:</div> -->
<table border="0" cellpadding="6" cellspacing="0" width="100%">
<tr>
<td class="alt2" style="background: rgb(37, 37, 37) none repeat scroll 0% 0%; border: 1px solid rgb(0, 0, 0); border-radius: 5px; font-size: 11px; text-shadow: none;">
<font size="3">«Мы обнаружили, что некоторые из этих скомпрометированных [из-за xz Utils] образов до сих пор публично доступны в Docker Hub. И что еще хуже — поверх этих зараженных базовых образов были построены другие, что приводит к каскадному заражению», — говорят исследователи.</font>
</td>
</tr>
</table>
</div>Суммарно специалисты нашли 35 таких образов, которые до сих пор доступны для скачивания. При этом аналитики подчеркивают, что это число лишь частично отражает реальный масштаб проблемы, поскольку они не проводили полное сканирование платформы.<br/>
<br/>
Наибольшее удивление исследователей вызвал тот факт, что разработчики Debian не стали убирать 64-битные образы с зараженной версией библиотеки из Docker Hub.<br/>
<br/>
В ответ на это в Debian <a href="https://github.com/debuerreotype/docker-debian-artifacts/issues/246" target="_blank">заявили</a>, что намеренно решили не удалять эти образы из репозитория и сохранили их как исторические артефакты. При этом пользователям настоятельно рекомендуется работать только с актуальными образами, а не со старыми.<br/>
<br/>
Мейнтейнеры пишут, что приняли такое решение, поскольку сочли эксплуатацию маловероятной. Например, для использования бэкдора должен быть установлен и запущен sshd в контейнере, у атакующего должен быть сетевой доступ к SSH-сервису этого контейнера, а также необходимо использовать приватный ключ, который соответствует логике срабатывания бэкдора.<br/>
<br/>
<img alt="" border="0" class="bbCodeImage" src="https://xakep.ru/wp-content/uploads/2025/08/548465/report.jpg"/><br/>
<br/>
Эксперты Binarly раскритиковали такой подход, подчеркивая, что само наличие этих образов в публичном доступе создает значительный риск случайного скачивания или использования в автоматизированных сборках.<br/>
<br/>
То же самое относится ко всем образам, которые могут содержать скомпрометированную версию xz Utils. Исследователи напоминают, что пользователям всегда следует вручную проверять, что библиотека представлена в безопасной версии 5.6.2 или новее (последняя стабильная версия — 5.8.1).<br/>
<br/>
<div style="margin:20px; margin-top:5px; ">
<!-- <div class="smallfont" style="margin-bottom:2px">Quote:</div> -->
<table border="0" cellpadding="6" cellspacing="0" width="100%">
<tr>
<td class="alt2" style="background: rgb(37, 37, 37) none repeat scroll 0% 0%; border: 1px solid rgb(0, 0, 0); border-radius: 5px; font-size: 11px; text-shadow: none;">
<font size="3">«Инцидент с бэкдором в xz Utils демонстрирует, что даже кратковременно внедренный вредоносный код может оставаться незамеченным в официальных образах контейнеров в течение длительного времени, и может распространяться в экосистеме Docker, — заключают специалисты. — Это подчеркивает, что подобные артефакты могут незаметно сохраняться и распространяться в CI/CD-пайплайнах и контейнерных экосистемах, а также подтверждает критическую необходимость непрерывного мониторинга на уровне двоичных файлов, а не просто отслеживания версий».</font>
</td>
</tr>
</table>
</div><a href="https://xakep.ru/2025/08/13/docker-hub-xz-utils" target="_blank">@ xakep.ru</a>
</div>