Как один разработчик предотвратил крупнейшую кибератаку: история взлома XZ Utils

Прошел ровно год с момента, когда мир с открытым ртом следил за расследованием одного из самых изощрённых бэкдоров в истории Linux. История с библиотекой xz Utils напоминала триллер: внедрение под реальным именем, доверие сообщества, закладки в коде — и случайное обнаружение в самый обычный рабочий день.

29 марта 2024 года программист Андрес Фройнд проснулся, как обычно, рано. На кухне уже фыркала кофемашина, а ноутбук мигал знакомым индикатором обновлений. Андрес любил утренние часы: пока город только-только просыпался, он уже погружался в привычную рутину — тесты, логи, графики загрузки процессора.

Утром он запустил стандартный набор тестов. Всё выглядело штатно: графики ровные, CPU не перегружен, багов не видно. И вдруг — странность. Незначительная ошибка, но не из тех, что просто игнорируешь. Андрес нахмурился. «Что это было?» — пробормотал он. Он подключился по SSH к серверу, чтобы проверить детали, и заметил ещё одно отклонение: задержка отклика в 500 миллисекунд. Полсекунды. Для большинства — ерунда. Но для Андреса — первый тревожный звонок. Он начал копать глубже.

---

Предыстория

Тем временем, за тысячи километров от Андреса, кто-то явно потирал руки. Его план был почти завершён: незаметно, шаг за шагом, он подготовил одну из самых изощрённых атак на инфраструктуру с открытым исходным кодом. Целью стал проект XZ Utils — малозаметный, но критически важный компонент большинства современных Linux-дистрибутивов.

По данным CISA, уязвимость в XZ могла позволить атакующему получить удалённый доступ к таким системам. Это действительно был ключ к цифровой инфраструктуре целых стран — и, возможно, один из самых тревожных инцидентов в истории open source.

Созданный в 2005 году инженером-программистом Лассе Коллином, формат файла .xz использует алгоритм сжатия LZMA, который обеспечивает сжатие на 30–40% эффективнее, чем gzip. Формат быстро завоевал популярность и активно используется для упаковки файлов tar, а также для сжатия системных архивов и других важных данных.

Почему атаковали XZ Utils

Потому что он оказался в составе многих других популярных инструментов. Один из них — OpenSSH — служит стандартом де-факто для безопасного удалённого доступа к серверам. Им пользуются миллионы систем по всему миру, от домашних серверов до критически важной инфраструктуры.

Важно понимать, что OpenSSH (а точнее, его серверная часть sshd) напрямую не использует библиотеку liblzma, которая входит в состав XZ Utils. Однако в некоторых популярных дистрибутивах, например Debian, sshd может быть собран с поддержкой systemd — системного менеджера, отвечающего за инициализацию служб при запуске Linux.

Вот где начинается интересное. systemd может обращаться к liblzma при обработке сжатых конфигурационных файлов. То есть, если внедрить вредоносный код в liblzma, он может активироваться ещё до старта sshd и повлиять на его работу.

Таким образом, чтобы встроить бэкдор, атакующему не нужно ломать sshd или systemd напрямую — это привлекло бы внимание. Вместо этого он находит уязвимость в менее очевидной библиотеке, которая подключается «по цепочке». А именно — в liblzma, которая оказывается идеальной «точкой входа».

Взлом, который планировали годами

Звучит вроде бы просто, однако чтобы воспользоваться этой уязвимостью, нужно было пройти долгий путь. Началось все еще в 2021 году. Тогда таинственный хакер зарегистрировался на GitHub под именем Jia Tan (JiaT75, Цзя Тан) и начал отправлять патчи в список рассылки xz-devel. Постепенно, не торопясь, он завоевывал доверие.

Его первый патч в этой рассылке добавлял файл «.editorconfig». Он был вполне безобидным и не вызывал подозрений. В ноябре того же года Jia Tan снова привлек внимание просьбой исправить очевидную проблему сборки.

Параллельно с этим хакер (или группа хакеров) начал использовать тонкую тактику социальной инженерии. Главная цель — убедить мейнтейнера XZ Utils, Лассе Коллина, что одному справляться с проектом становится всё сложнее, и пора подключать ещё кого-то из «надежных» помощников.

Лассе много лет занимался XZ Utils практически в одиночку — из интереса, по зову души. Но в какой-то момент увлечение начало напоминать тяжёлую обязанность. Работы становилось всё больше, времени и сил — всё меньше. Особенно на фоне личных проблем со здоровьем. Объективно, помощь действительно была нужна.

И именно этим воспользовался Jia Tan.

В апреле 2022 года он отправил очередной, на первый взгляд, незначительный патч. Однако именно с него на сцене появляется новый персонаж — Jigar Kumar. Формально он никак не связан с Jia Tan, но быстро начинает продвигать идею: Лассе нужен «напарник», чтобы проект не умер. И Jia — отличный кандидат.

Джигар Кумар начинает аккуратно, но настойчиво критиковать Лассе Коллина — сопровождающего проекта XZ Utils. Он намекает, что разработка почти замерла, обновления не принимаются, и всё это тормозит развитие проекта:

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

Подтекст прост: если так пойдёт и дальше, проект может вообще заглохнуть. А значит, Лассе стоит передать часть ответственности кому-то более «эффективному». Например, Jia Tan.

Позже к обвинениям подключается некий Dennis Ens (Деннис Энс). Он отправляет письмо xz-devel с вопросом о поддержке XZ для Java. И также выражает недовольство работой сопровождающего.

Лассе Коллин извинился за задержку с ответами и пояснил, что сейчас работает с множеством обращений. Но конфликт на этом не закончился.

​В июне 2022 года на форуме разработчиков XZ Utils развернулась дискуссия о темпах развития проекта и необходимости привлечения новых участников. 7 июня участник под псевдонимом Джигар Кумар написал:​

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

На это Лассе Коллин ответил:​

Я не потерял интерес, но моя способность заниматься проектом была довольно ограничена, в основном из-за длительных проблем с психическим здоровьем, но также из-за некоторых других вещей. Недавно я немного поработал с Цзя Таном над XZ Utils, и, возможно, в будущем у него будет более значительная роль, посмотрим. Также имейте в виду, что это неоплачиваемый хобби-проект.

После нескольких недель давления и потока писем, призывающих передать проект в новые руки, в репозитории xz появляется коммит от пользователя JiaT75. На первый взгляд — вполне безобидный патч. Но именно он стал поворотной точкой: Цзя Тан начал быстро продвигаться, вскоре став вторым по активности участником проекта.

Параллельно с этим из поля зрения пропадают Джигар Кумар и Деннис Энс. Их имена больше не появляются в сети, кроме пары упоминаний в письмах Коллину. А вот Цзя Тан закрепился прочно. К октябрю 2022 года он уже входит в организацию Tukaani на GitHub, а Лассе всё чаще поручает ему ключевые задачи.

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

30 декабря 2022 года Цзя Тан вносит пакет коммитов, а в одном из них впервые указывает своё полное имя — Jia Cheong Tan. Это подтверждает, что он получил прямой доступ к системе коммитов. В марте 2023 года он выпускает свою первую сборку — версию v5.4.2. На тот момент он уже воспринимается как полноценный мейнтейнер библиотеки XZ Utils.

Чтобы Лассе не видел потенциальных проблем с его патчами, Тан решает перехватить контроль над уведомлениями об уязвимостях. Он меняет контактный email в системе OSS-Fuzz — платформе от Google, которая проверяет open-source-проекты на стабильность и безопасность. После этого все баг-репорты шли напрямую к нему, а не к оригинальному мейнтейнеру.

Позже к нему подключается некий Hans Jansen, якобы независимый участник. Он отправляет патч в xz, который выглядел вполне нормально, но по факту нарушал процесс fuzz-тестирования. Цзя Тан принимает этот патч, а затем вносит изменения в проект OSS-Fuzz, чтобы замаскировать потенциальную проблему. Эти правки тоже прошли модерацию без лишних вопросов.

23 февраля 2024 года Цзя Тан добавляет вредоносный код, зашифрованный в двоичных тестовых входных файлах, предназначенных для сборки и поздней активации в зависимости от окружения (например, systemd). Для этого он использует редактор шестнадцатеричных данных, так что стандартные проверки не срабатывают. Версия XZ 5.6.1 выходит с этим кодом, но всё ещё выглядит как вполне рутинное обновление.

Примерно в это же время разработчик под ником @teknoraver создаёт issue на GitHub, предлагая прекратить связывание liblzma с systemd. Это предложение могло бы прервать вектор атаки. Поняв, что «окно возможностей» может захлопнуться, Цзя Тан действует быстрее. Именно это, вероятно, приводит к спешке и ошибкам, которые позднее и позволят обнаружить уязвимость.

9 марта 2024 года он выпускает сборку XZ 5.6.1, содержащую бэкдор, а вскоре после этого Ханс Янсен пишет команде Debian, настоятельно рекомендуя обновиться до этой версии. Цзя Тан тем временем давит на Fedora и параллельно пытается внедрить патч в Ubuntu 24.04 LTS. Об этом писали в Debian Security Advisory.

Всё шло по плану. Ещё немного — и модифицированная версия библиотеки могла оказаться в релизах крупнейших дистрибутивов. Но именно в этот момент на сцену выходит Андрес Фройнд. И история получает совсем другой финал.

Андрес Фройнд и предотвращение атаки

Предотвратил грядущую катастрофу инженер-программист Андрес Фройнд. Ему 38 лет, он живет в Сан-Франциско и работает в Microsoft. Его работа заключается в разработке части программного обеспечения с открытым исходным кодом для PostgreSQL.

История началась еще зимой 2024 года, когда Фройнд возвращался из Германии, куда летал к родителям. Просматривая журнал автоматизированных тестов, он заметил несколько странных сообщений об ошибках. Тогда у него очень болела голова, он страдал от смены часовых поясов, и сообщения не казались ему срочными, поэтому он отложил их.

Но несколько недель спустя, 29 марта 2024 года, проводя еще несколько тестов дома, он заметил задержку в работе SSH при запуске нестабильной версии Debian.

Сам Андрес так описывает свои размышления в тот момент:

Не было запущено никакого графического пользовательского интерфейса или чего-то еще. Так что как будто не должно было быть никакого использования ЦП вообще, потому что он простаивал. Но иногда были эти 500 миллисекунд и 700 миллисекунд где-то высокой загрузки ЦП, которая затем снова снижалась. Это было неожиданно. Поэтому я запустил профилировщик.

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

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

След привёл его к утилите XZ Utils — и тут он вспомнил: похожие баги уже мелькали раньше. Может, это всё части одной и той же истории?

Фройнд обнаружил, что XZ Utils намеренно модифицировали вредоносным кодом в течение последних трех лет. Изменения были небольшими и незаметными, но в сочетании с другими частями операционной системы Linux они давали хакеру фактически полный доступ ко всему серверу. Бэкдор готовился к включению в версии Linux, которые достигли бы практически всех современных серверов с выходом в интернет.

Это казалось сюрреалистичным», — сказал он. «Были моменты, когда я думал, что, должно быть, просто плохо спал ночью и видел какие-то лихорадочные сны.

Но его расследование продолжало приносить новые доказательства, и 29 марта Фройнд опубликовал в списке рассылки Openwall сообщение о бэкдоре.

Эта новость вызвала взрыв в мире технологий. Проблему исправили, а Фройд стал героем, предотвратившим крупнейшую кибератаку. В интервью Андрес сказал, что такая популярность его дезориентирует: «Я нахожу это очень странным. Я довольно закрытый человек, который просто сидит перед компьютером и ковыряется в коде».

Суть бэкдора

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

При совпадении информации из удалённого сертификата с данными бэкдора, они расшифровываются с использованием алгоритма ChaCha20. После успешной расшифровки данные передаются в функцию system(), что позволяет злоумышленникам выполнять команды до завершения процесса аутентификации. Это делает уязвимость гораздо более серьёзной, чем просто обход аутентификации по открытым ключам.

Технически бэкдор был внедрен во время создания tarball для релиза, однако его нельзя обнаружить в репозитории xz на GitHub. Вредоносный код был скрыт от глаз разработчиков, так как он был добавлен только в релизы tarball исходного кода, а не в публичные репозитории. Это обеспечило относительную скрытность бэкдора, несмотря на его использование в сборках зависимых проектов.

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

Процесс исполнения бэкдора включает несколько этапов: сначала запускается скрипт build-to-host.m4, который декодирует «тестовый» файл bad-3-corrupt_lzma2.x в bash-скрипт. Затем этот скрипт выполняет сложные операции декодирования другого файла и извлекает общий объект liblzma_la-crc64-fast.o для компиляции библиотеки liblzma. Данная конструкция делает бэкдор труднодоступным для обнаружения без прямого анализа кода.

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

Общий объект компилируется в библиотеку liblzma и вмешивается в механизм динамической линковки. При запуске процесса указатели на функции, такие как RSA_public_decrypt из OpenSSH, подменяются на адреса вредоносной функции. Эта функция извлекает команды из сертификата клиента, прошедшего аутентификацию, и передаёт их в system() для исполнения, позволяя выполнить произвольный код (RCE) ещё до завершения аутентификации.

Секрет Jia Tan

Процесс бэкдора подробно исследовали, но того, кто стоит за атакой, до сих пор не вычислили. Кто такой Jia Tan? Это человек или группа людей? И что движет их действиями? На данный момент это остается одной из самых интригующих загадок в сфере информационной безопасности.

О личности Цзя Тана практически ничего не известно. Независимый репортер по теме безопасности, Брайан Кребс пишет, что он не смог найти «никаких следов» адресов электронной почты Цзя Тана: «Адреса электронной почты, которые использовались в течение как минимум пары лет вовлеченными сторонами, не имеют абсолютно никаких следов в какой-либо утечке данных или базе данных за пределами Github/Gitlab, и, возможно, Tukaani и Debian и нескольких списков рассылки. Обычно, когда я вижу это, я предполагаю, что мы имеем дело с одноразовым или одноцелевым адресом электронной почты, который был создан либо для мошенничества, либо потому, что кто-то очень параноидально относится к конфиденциальности». Подобная картина наблюдается и с аккаунтами Джигара Кумара, Денниса Энса и Ханса Янсена.

Но кое-какую информацию исследователям собрать удалось. Цзя Тан присутствовал на IRC-канале #tukaani на Libera.Chat. A /whois раскрыл подключающийся IP и отследил активность 29 марта.

Запуск Nmap на IP показывает много открытых портов, что, вероятно, указывает на прокси, хостинг-провайдера или что-то в этом роде. Похоже, что Цзя Тан был подключен с сингапурского IP-адреса 185.128.24.163, но этот сингапурский IP-адрес связан с VPN-сервисом Witopia.

Далее исследователи проанализировали часовой пояс злоумышленника. На первый взгляд Цзя Тан, безусловно, выглядит как человек, живущий в Восточной Азии. Часовой пояс его коммитов — UTC+8: это часовой пояс Китая, и он всего на час отличается от северокорейского.

Исследователь Huntress, работающий под псевдонимом «Alden», опубликовал визуализацию вредоносных коммитов Jia Tan в XZ Utils.

Однако анализ двух исследователей, Рии Карти и Саймона Хеннигера, предполагает, что Цзя Тан, возможно, просто изменял часовой пояс своего компьютера на UTC+8 перед каждым коммитом.

«Еще одним признаком того, что он не из Китая, является тот факт, что он работал в известные китайские праздники», — говорят Карти и Хеннигер. Они отмечают, что Цзя Тан также не отправлял новый код на католическое Рождество или Новый год.

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

Китайские государственные праздники (рассматриваем только 2023 год):

• Работает в 2023 году 29 сентября: Праздник середины осени;

• Работает в 2023 году 5 апреля: День поминовения усопших;

• Работает 26, 22, 23, 24, 26, 27 января 2023 года: Лунный Новый год.

Праздники Восточной Европы:

• Не работает 25 декабря: Рождество;

• Не работает 31 декабря или 1 января: Новый год».

Кроме того, в ходе расследования выяснилось, что большая часть работы Цзя Тана выполнялась в промежутке с 9 утра до 5 вечера для восточноевропейского или ближневосточного часового пояса. А наиболее распространенными рабочими днями были вторник (86), среда (85), четверг (89) и пятница (79).

«Временной диапазон коммитов предполагает, что это не был какой-то проект, который делали вне работы», — убеждены эксперты.

Исследователи безопасности сходятся во мнении, что за профилем Цзя Тана скрывается хакерская группа национального масштаба.

Костин Раю, бывший руководитель аналитической группы в «Лаборатории Касперского», считает, что за этой деятельностью стоит государственная структура с долгосрочными стратегическими целями, готовая инвестировать время и ресурсы в глубокое проникновение в открытые проекты.

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

Костин Раю предполагает, что за атакой стоят неамериканские группы, такие как китайская APT41, северокорейская Lazarus Group или российская APT29.

Исследователь Джо Кристиан подозревает северокорейскую Lazarus Group или Diamond Sleet: «Эта конкретная группа активно использовала уязвимости в цепочках поставок программного обеспечения и нацелилась на инфраструктуру CI/CD (Continuous Integration/Continuous Deployment) в течение последних четырех лет».

Но это все остается лишь догадками и предположениями.

Крис Стэнгл, бывший агент киберотдела ФБР, заявил, что правоохранительные органы, вероятно, расследуют инцидент. Он отметил, что CISA и ФБР изучают ситуацию, чтобы предотвратить подобные случаи в будущем и выяснить мотивацию участников.

В АНБ не комментируют ситуацию, не подтверждая и не опровергая наличие расследования.

Итоги

Агентство по кибербезопасности и безопасности инфраструктуры США (CISA) присвоило уязвимости код CVE-2024-3094. Бэкдор проник в тестовые выпуски дистрибутивов Linux, таких как Debian Sid, Fedora 41 и Fedora Rawhide, но был обнаружен до того, как успел попасть в широко используемые стабильные версии.

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

CISA призывает компании, использующие open-source, не только полагаться на добровольцев, но и вкладываться в развитие и поддержку таких проектов. Без этого будет всё сложнее предотвращать подобные угрозы.

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

Разработчик FFmpeg в твиттере с горечью заметил:

Фиаско с xz показало, как зависимость от неоплачиваемых волонтеров может привести к серьёзным проблемам. Корпорации с оборотом в триллионы долларов ожидают бесплатной и срочной поддержки от волонтёров.

После инцидента были высказаны предложения, как именно можно укрепить open-source-инфраструктуру. Один из авторов спецификации XML, Тим Брей, предложил создать «Институты качества открытого кода» (OSQI) — независимые организации, способные поддерживать критически важные проекты, оплачивать труд мейнтейнеров и проводить независимый аудит. Однако за прошедший год эта инициатива не получила серьёзного развития, и масштабных системных изменений пока не произошло.

«Нам в этот раз несказанно повезло», — сказал Андрес Фройнд в одном из постов на Mastodon. — «Но полагаться на удачу в будущем — плохая стратегия».

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

Мораль истории XZ Utils не в разоблачении, а в предупреждении: если ничего не менять — подобное случится снова. И, возможно, в следующий раз нам так не повезёт.

---

НЛО прилетело и оставило здесь промокод для читателей нашего блога:

-15% на заказ любого VDS (кроме тарифа Прогрев) — HABRFIRSTVDS