XZ Utils backdoor: разбор supply chain атаки и что мы поменяли в проверке зависимостей

В марте 2024 года Андрес Фройнд из Microsoft случайно обнаружил, что liblzma - библиотека из пакета XZ Utils - при определённых условиях подменяет внутренние функции sshd и фактически открывает backdoor для авторизации по специальному ключу. CVE-2024-3094, CVSS 10.0. Вредоносный код добрался до Fedora 40 beta, openSUSE Tumbleweed и Kali Linux. В стабильные выпуски Debian и Ubuntu он не попал - только в нестабильные ветки, - но это во многом случайность, а не заслуга процессов.

Мы разбирали этот инцидент подробно и пришли к выводу, что это не просто очередная CVE с высоким баллом. Это учебный кейс, который показывает, как атака через цепочку поставок выглядит в реальности - и насколько стандартные инструменты проверки зависимостей против неё беспомощны.

Как это было сделано

Механика атаки заслуживает детального рассмотрения, потому что она принципиально отличается от взлома репозитория или внедрения вредоносного пакета через опечатку в имени.

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

Вредоносный код был спрятан не в самом git-репозитории, а в тарболле релиза - файле .tar.gz, который дистрибутивы загружают при сборке пакетов. В тарболле лежали бинарные тестовые файлы, внутри которых и был спрятан вредоносный payload. Скрипты конфигурации пакета извлекали и активировали его при сборке в определённых условиях: наличие systemd, сборка под deb или rpm, архитектура x86_64. То есть на типичном рабочем месте разработчика под macOS или без systemd ничего не происходило - атака нацелена именно на серверные дистрибутивы Linux в продакшне.

Обнаружил это Фройнд совершенно случайно: при профилировании SSH-соединений заметил избыточную нагрузку CPU на тестовой машине с Fedora 40 beta и начал копать. Несколько дней расследования - и картина сложилась.

Почему стандартные процессы это не ловят

Мы задали себе честный вопрос: а что из того, что мы обычно делаем при проверке зависимостей, поймало бы XZ Utils backdoor?

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

Сканирование на известные CVE - не ловит. До публикации CVE-2024-3094 это была просто свежая версия xz с хорошей репутацией.

Проверка репутации пакета - не ловит в достаточной мере. XZ Utils - зрелый проект с пятнадцатилетней историей. Jia Tan - активный контрибьютор с историей качественных правок.

Сравнение тарболла с git-репозиторием - ловит, но кто это делает? Это нетривиальная операция, которая не является частью стандартного процесса сборки пакетов.

Получается, что атака была заточена именно под слепые зоны типичного supply chain due diligence. Это не баг реализации - это архитектурная проблема подхода.

Что мы поменяли

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

Инвентаризация системных библиотек как отдельный трек. До XZ Utils мы фокусировались на прикладных зависимостях - pip, npm, maven. Системные библиотеки вроде libssl, libz, liblzma воспринимались как данность из дистрибутива. Теперь они тоже в реестре: какая версия, в каких дистрибутивах используется, когда последний раз обновлялась.

Политика задержки нестабильных веток. Fedora 40 beta и openSUSE Tumbleweed - rolling-дистрибутивы, которые первыми получают свежие пакеты. Именно они оказались в зоне поражения. Для продакшн-серверов на КИИ мы и раньше рекомендовали стабильные LTS-ветки, но теперь это жёсткое требование с документированным обоснованием, а не просто «лучшая практика».

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

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

Что это означает шире

XZ Utils - не единственный инцидент 2024 года с открытым ПО. В течение года были обнаружены вредоносные npm-пакеты, имитирующие популярные библиотеки, скомпрометированные аккаунты PyPI-мейнтейнеров, атаки через GitHub Actions в CI/CD-пайплайнах. Общий вектор один: атакующие идут не напролом через уязвимость в коде, а через доверие, которое выстраивается годами.

Полный аудит supply chain - это работа, у которой нет конечной точки. Каждая новая зависимость это потенциальная точка входа, и контроль над ней со временем может перейти к кому угодно. Это неудобная правда про open source экосистему, которую все знают, но предпочитают не фокусироваться на ней, пока не случится XZ Utils.

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