🐭 #события #offense

Бэкдор в утилите xz (CVE-2024-3094) – одна из самых громких новостей последних дней в сфере безопасности;

➖ CVSS: 😀
➖ Версии: 5.6.0 / 5.6.1
➖ RCE без следов в логах sshd
➖ Требуется приватный ключ злоумышленника

➡️Очевидно, что нужно откатываться к менее неприятным версиям, и на этом нам, как пользователям, можно было бы остановиться, но мне хочется разобраться в сути проблемы и в очередной раз обсудить тему человеческого фактора;

🧩 Everything I know about the xz backdoor ⚡️

   🧩  thesamesam/xz-backdoor ⚡️

🧩 Reported Supply Chain Compromise Affecting XZ Utils Data Compression Library, CVE-2024-3094 [CISA]

🧩 Frequently Asked Questions About CVE-2024-3094, A Backdoor in XZ Utils [Tenable]



❓) Что произошло?

  [💻]  Деобфусцированный код:   injected.txt
[✉️] Полное письмо с разбором:
‟backdoor in upstream xz/liblzma leading to ssh server compromise”

Andres Freund, разработчик из Microsoft, сообщил в рассылке oss-security об обнаружении бэкдора в утилите xz, который приводит к компрометации сервера SSH;

Специалист заметил:
🪲 Ошибки valgrind*
🪲 Увеличенное время логина по SSH
🪲 Увеличенное потребление CPU при логине по SSH
💻 А после – что TAR-архив xz, поставляемый через upstream репозиторий, содержал строку build-to-host.m4#L63, которой не было ни в upstream'ном build-to-host, ни на GitHub;

*К слову, ошибки valgrind были вызваны таким лэйаутом стека, который бэкдор не предусматривал, причём этот недочёт попытались исправить в версии xz 5.6.1;

Оказалось, что происходит инъекция обфусцированного скрипта, который извлёк другой специалист, Florian Weimer, и его исполнение по окончании конфигурации (при некоторых условиях**);

Деобфусцирвав код, специалисты выяснили, что он:

➖Перехватывает выполнение
➖Заменяет crc32_resolve() / crc64_resolve(), которые резолвятся при запуске sshd, на другой код, вызывающий _get_cpuid()
➖Производит проверки среды окружения
➖Парсит таблицы символов в памяти (основная причина замедления)
➖Устанавливает хук в динамический линковщик, ожидая резолва RSA_public_decrypt@...plt и заменяя его значение для указания на другой код бэкдора
➖Вызывает вредоносный код при логине по SSH с помощью ключа + продолжает нормальную аутентификацию

**Замеченные условия эксплуатации:
0️⃣ Детектируются некоторые дебаггеры (gdb, rr, ...)
1️⃣ x86-64 linux
2️⃣ Сборка с помощью gcc + gnu linker
3️⃣ Не установлена переменная окружения TERM
4️⃣ LD_BIND_NOT != 1
5️⃣ argv[0] = /usr/sbin/sshd
6️⃣ Не установлены LD_DEBUG, LD_PROFILE
7️⃣ Установлен LANG
8️⃣ yolAbejyiejuvnup != Evjtgvsh5okmkAvj‼️



❓) Как так вышло?

[2022]  Путь ко внедрению бэкдора начался приблизительно 2 года назад, когда основного разработчика, Lasse Collin, стали обвинять в медленном прогрессе. Пользователь Jigar Kumar настаивал на том, что xz срочно нужен новый мейнтейнер, ведь проект простаивает;

[2022]  Lasse Collin признался незнакомцу, что находится в трудном положении: ментальные проблемы, нехватка рук и ресурсов не дают ему и, следовательно, xz двигаться вперёд с требуемой скоростью, но в проект вносит вклад некий Jia Tan, который, возможно, получит более значимую роль в проекте;

  [✉️]  Полный ответ Lasse Collin для Jigar Kumar:
‟Re: [xz-devel] XZ for Java”

[2023] Jia Tan становится основным контактом вместо Lasse Collin в oss-fuzz – фаззере open source проектов от Google. Он коммитит инфраструктуру, которая будет использована в эскплойте в 2024 году. Автором числится некий Hans Jansen, который, судя по всему, был создан сугубо для этого коммита. Jia Tan создаёт пулл реквест в oss-fuzz, настаивая на отключении некоторых проверок, обуславливая это необходимостью xz в поддержке IFUNC;

[2024] Jia Tan изменяет ссылку на проект в oss-fuzz с tukaani.org/xz на xz.tukaani.org/xz-utils и коммитит последние штрихи для бэкдора;


Эта история – причина вспомнить и подумать о насущном:
▪️о ментальном здоровье
▪️об ответственности
▪️о прочих злободневных проблемах, особо острых для open source (анонимность, нехватка рук, ресурсов, мотивации, ...)

➡️Stay safe.

   @HaHacking  🐇