В феврале 2024 года вредоносный бэкдор был внедрен в сборку Linux утилиты xz в библиотеке liblzma в версиях 5.6.0 и 5.6.1 учетной записью с именем «Jia Tan». [b] [4] Бэкдор дает злоумышленнику, обладающему определенным закрытым ключом Ed448, возможность удаленного выполнения кода в уязвимой системе Linux. Уязвимости был присвоен номер Common Vulnerabilities and Exposures CVE - 2024-3094 и ей был присвоен рейтинг CVSS 10.0, наивысший возможный рейтинг. [5]
Хотя xz обычно присутствует в большинстве дистрибутивов Linux , на момент обнаружения версия с бэкдором еще не была широко развернута в производственных системах, но присутствовала в версиях разработки основных дистрибутивов. [6] Бэкдор был обнаружен разработчиком программного обеспечения Андресом Фройндом, который объявил о своих результатах 29 марта 2024 года. [7]
Сотрудник Microsoft и разработчик PostgreSQL Андрес Фройнд сообщил о бэкдоре после исследования снижения производительности в Debian Sid . [8] Фройнд заметил, что соединения SSH генерируют неожиданно высокую загрузку ЦП, а также вызывают ошибки в Valgrind , [9] инструменте отладки памяти. [10] Фройнд сообщил о своей находке в список рассылки Openwall Project по безопасности с открытым исходным кодом, [9] что привлекло к ней внимание различных поставщиков программного обеспечения. [10] Злоумышленник предпринял попытки скрыть код, [11] поскольку бэкдор состоит из нескольких этапов, которые действуют вместе. [12]
После того, как скомпрометированная версия внедряется в операционную систему, она изменяет поведение демона сервера SSH OpenSSH , злоупотребляя библиотекой systemd , что позволяет злоумышленнику получить доступ администратора. [12] [10] Согласно анализу Red Hat , бэкдор может «позволить злоумышленнику взломать аутентификацию sshd и получить несанкционированный доступ ко всей системе удаленно». [13]
Последующее расследование показало, что кампания по внедрению бэкдора в проект XZ Utils стала кульминацией примерно трехлетних усилий, с ноября 2021 года по февраль 2024 года, [14] пользователя под именем Jia Tan и псевдонимом JiaT75, чтобы получить доступ к доверенной должности в проекте. После периода давления на основателя и главного сопровождающего с целью передачи контроля над проектом посредством очевидного кукловодства , Jia Tan получила должность со-сопровождающего XZ Utils и смогла подписать версию 5.6.0, в которой был представлен бэкдор, и версию 5.6.1, в которой было исправлено некоторое аномальное поведение, которое могло быть очевидным во время тестирования программного обеспечения операционной системы. [10]
Некоторые из предполагаемых псевдонимов кукольного театра включают учетные записи с именами пользователей вроде Jigar Kumar , krygorin4545 и misoeater91 . Подозревается, что имена Jia Tan , а также предполагаемый автор кода Hans Jansen (для версий 5.6.0 и 5.6.1) являются псевдонимами, выбранными участниками кампании. Ни один из них не имеет какого-либо видимого публичного присутствия в разработке программного обеспечения за пределами коротких нескольких лет кампании. [15] [16]
Бэкдор отличался уровнем своей сложности и тем фактом, что преступник практиковал высокий уровень операционной безопасности в течение длительного периода времени, работая над достижением доверенной должности. Американский исследователь безопасности Дэйв Айтел предположил, что он соответствует шаблону, приписываемому APT29 , передовому постоянному субъекту угроз, который , как полагают, работал в интересах российской СВР . [14] Журналист Томас Клэберн предположил, что это мог быть любой государственный субъект или негосударственный субъект со значительными ресурсами. [17]
Известно, что вредоносный код находится в выпусках 5.6.0 и 5.6.1 пакета программного обеспечения XZ Utils. Эксплойт остается неактивным, если не используется определенный сторонний патч сервера SSH. При правильных обстоятельствах это вмешательство потенциально может позволить злоумышленнику взломать аутентификацию sshd и получить несанкционированный доступ ко всей системе удаленно. [13] Вредоносный механизм состоит из двух сжатых тестовых файлов, которые содержат вредоносный двоичный код. Эти файлы доступны в репозитории git , но остаются неактивными, если их не извлечь и не внедрить в программу. [4] Код использует механизм glibc IFUNC для замены существующей функции в OpenSSH, вызванной RSA_public_decryptвредоносной версией. OpenSSH обычно не загружает liblzma, но распространенный сторонний патч, используемый несколькими дистрибутивами Linux, заставляет его загружать libsystemd , который, в свою очередь, загружает lzma. [4] Измененная версия build-to-host.m4была включена в tar-файл релиза, загруженный на GitHub , который извлекает скрипт, выполняющий фактическую инъекцию в liblzma. Этот измененный файл m4 отсутствовал в репозитории git; он был доступен только из файлов tar , выпущенных сопровождающим отдельно от git. [4] Похоже, что скрипт выполняет инъекцию только тогда, когда система собирается на системе Linux x86-64 , которая использует glibc и GCC и собирается через dpkg или rpm . [4]
Федеральное агентство по кибербезопасности и безопасности инфраструктуры США выпустило рекомендацию по безопасности, в которой рекомендовало откатить уязвимые устройства до предыдущей нескомпрометированной версии. [18] Поставщики программного обеспечения Linux, включая Red Hat, SUSE и Debian , вернули уязвимые пакеты к более старым версиям. [13] [19] [20] GitHub отключил зеркала для репозитория xz, прежде чем впоследствии восстановить их. [21]
Canonical отложила бета-релиз Ubuntu 24.04 LTS и его разновидностей на неделю и решила провести полную бинарную пересборку всех пакетов дистрибутива. [22] Хотя стабильная версия Ubuntu не была затронута, версии upstream были затронуты. Эта мера предосторожности была принята, поскольку Canonical не могла гарантировать к изначальному сроку выпуска, что обнаруженный бэкдор не повлияет на дополнительные пакеты во время компиляции. [23]
Специалист по информатике Алекс Стамос высказал мнение, что «это мог быть самый распространенный и эффективный бэкдор, когда-либо внедренный в какой-либо программный продукт», отметив, что если бы бэкдор остался незамеченным, он бы «дал своим создателям главный ключ к любому из сотен миллионов компьютеров по всему миру, на которых работает SSH». [24] Кроме того, инцидент также положил начало обсуждению целесообразности зависимости критически важных частей киберинфраструктуры от неоплачиваемых добровольцев. [25]
