XZ Utils backdoor (CVE-2024-3094): закладка в liblzma и срочная инвентаризация на серверах клиентов

Несколько дней назад разработчик Microsoft Андрес Фройнд опубликовал разбор того, что оказалось одной из самых технически изощрённых атак на open source инфраструктуру за последние годы. В liblzma - библиотеке сжатия, которая входит в XZ Utils и подтягивается как зависимость в огромное количество пакетов - обнаружена закладка. CVE-2024-3094, CVSS 10.0.

Фройнд заметил аномалию случайно: валидация SSH занимала подозрительно много CPU на его тестовой машине с Debian Sid. Потянул нитку - и размотал полную историю компрометации.

Как это работало

Закладка влияла не на сам xz, а на liblzma, которую подтягивает systemd через libsystemd - а та, в свою очередь, в ряде дистрибутивов линкуется с openssh-server. Итог: в скомпрометированных версиях злоумышленник мог вмешиваться в аутентификацию по SSH ещё до того, как OpenSSH до неё добирался. Механизм изощрённый: вредоносный код был спрятан в тестовых бинарных файлах в репозитории и распаковывался в процессе сборки пакета - не в исходниках, а именно в сборочных артефактах.

Затронуты конкретные версии: xz 5.6.0 и 5.6.1. Они успели попасть в Debian unstable (Sid) и Fedora Rawhide. Стабильные дистрибутивы - Debian stable, Ubuntu LTS, RHEL, Astra Linux, РЕД ОС - не затронуты: туда эти версии не добрались.

Кто и как это сделал

Здесь начинается часть, которая по-настоящему неприятна. Это не случайная уязвимость и не банальный взлом репозитория.

Злоумышленник или группа под именем Jia Tan два года методично выстраивали доверие в проекте XZ Utils. Единственный мейнтейнер - Лассе Коллин - испытывал давление сообщества, жаловался на выгорание. Jia Tan появился как помощник, делал полезные патчи, постепенно получил права на коммит. Параллельно другие аккаунты в списках рассылки торопили с включением xz в дистрибутивы, давили на мейнтейнера. Это не импровизация - это спланированная операция с горизонтом в два года.

Закладка внедрялась аккуратно: вредоносные изменения были размазаны по нескольким коммитам, код в тестовых файлах не читался как очевидно подозрительный. Автоматические проверки не поймали бы это - только ручной аудит или случайность, как в итоге и произошло.

Что мы сделали

Новость появилась поздно вечером в пятницу. К утру субботы у нас уже шёл обход по инфраструктуре клиентов.

Задача была простая и конкретная: найти, где стоят xz версий 5.6.0 или 5.6.1, и понять, есть ли там openssh-server с зависимостью через systemd. Никакой паники, просто инвентаризация.

По каждому серверу запускали примерно следующее:

xz --version
dpkg -l | grep -E 'xz-utils|liblzma'
rpm -qa | grep xz

Параллельно смотрели на дистрибутив и ветку: Debian Sid и Fedora Rawhide в продакшне у наших клиентов не используются как основа для боевых серверов - это предсказуемо, но проверить всё равно стоило. КИИ-контур у всех на стабильных ветках, что по требованиям ФСТЭК, что по здравому смыслу.

Результат инвентаризации: уязвимые версии xz в продакшне не обнаружены. Debian Sid нашёлся в нескольких dev-окружениях разработчиков - там действительно был xz 5.6.0. Эти машины не выходят в интернет напрямую, SSH через бастион, но версию всё равно откатили и зафиксировали в конфигурации.

Почему это важно за пределами конкретного CVE

Инцидент интересен не столько технической начинкой - закладки в библиотеках случались и раньше. Интересна схема. Два года социальной инженерии против одного усталого мейнтейнера - это атака на человека, не на код.

Open source держится на людях, которые делают это бесплатно, в свободное время, часто в одиночку. Проект с одним мейнтейнером, который выгорает - это не просто операционный риск проекта, это поверхность атаки. Jia Tan её использовал.

В нашем январском посте про аудит транзитивных зависимостей мы разбирали, почему стандартного patch management недостаточно для КИИ-контура и почему важно смотреть на историю коммитов и новых контрибьюторов. XZ Utils - это не абстрактный сценарий из той статьи, это он и есть, только реализовавшийся.

Что конкретно стоит сделать сейчас, если ещё не сделали:

Проверить версии xz/liblzma на всех серверах. Особенно на машинах, где дистрибутив обновлялся без ограничений на ветку - rolling или testing репозитории. Команды выше занимают пять минут на весь парк при наличии централизованного управления конфигурациями.

Убедиться, что dev-окружения изолированы. Разработчики часто сидят на свежих дистрибутивах, это разумно. Но если dev-машина ходит в ту же сеть, что и продакшн-серверы, и на ней стоит уязвимый sshd - это вектор.

Зафиксировать версии пакетов там, где их менять не нужно. apt-mark hold или аналог для критичных библиотек на стабильных серверах - дёшево и снижает вероятность случайного обновления до проблемной версии при неосторожном apt upgrade.

Проводим аудит инфраструктуры - смотрим на версии зависимостей, на изоляцию сред, на то, кто и когда последний раз делал полную инвентаризацию пакетов. История с XZ Utils показала: это не паранойя.