Бэкдоринг SSH
Злонамеренный или скомпрометированный сопровождающий внедрил вредоносное поведение в библиотеку с именем либлзма, часть инструментов и библиотек сжатия xz, что приводит к появлению бэкдора в SSH. Это сложная атака на цепочку поставок программного обеспечения, поскольку библиотека была намеренно модифицирована для бэкдора с использованием методов запутывания и скрытности для сокрытия полезной нагрузки атаки от рецензентов. Недавно он был обнаружен и раскрыт (29 марта), и обработка атаки продолжается. Однако он был быстро локализован, поскольку, по-видимому, он затрагивает только предварительные версии ограниченного набора сред (пакеты DEB и RPM для архитектуры x86_64 и собранные с помощью GCC). В любом случае, CVE был дан Базовая оценка CVSS 10, что зарезервировано для самых критических уязвимостей кибербезопасности. Если он попадет в стабильные дистрибутивы, воздействие будет подавляющим. Технический анализ атаки, включая подробное объяснение бэкдора xz, был проанализирован в другом месте. В этом посте мы сосредоточимся на хронологии атаки, на том, как ее можно было обнаружить, как инцидент был обработан на сегодняшний день и какие уроки можно извлечь из атаки.Как был внедрен бэкдор XZ
Примечание. Репозиторий git находится в git.tukaani.org. Тем не менее, был также Репозиторий, размещенный на GitHub (в настоящее время заблокировано), где учетная запись GitHub публиковала изменения, которые позже были интегрированы в репозиторий Git. Одна часть бэкдора, судя по всему, находится только в распространяемых архивах версий 5.6.0 и 5.6.1, а не в репозиториях git, и опирается на одна строка в файле build-to-host.m4 файл макроса, используемый autoconf. Другая часть находилась в двух предполагаемых тестовых файлах. bad-3-corrupt_lzma2.xz и хороший-large_compressed.lzma , которые были взял на себя обязательство аккаунтом GitHub «Jia Tan» (ЦзяТ75) В xz-репозиторий 23 февраля. Это было безобидное изменение, добавляющее тестовые файлы (предположительно сжатые блоки .lzma и .xz). Интересно, что тестовые файлы не использовались в тестах! Строка в файле .m4 вставляет запутанный скрипт (включенный в архив), который будет выполнен в конце настройки, если некоторые условия совпадают. Он изменяет Makefile для либлзма библиотека, содержащая код, извлекающий данные из файла .xz, который после деобфускации завершается в этом сценарии, вызывается в конце configure. Он решает, следует ли изменить процесс сборки для внедрения кода: только под GCC и компоновщиком GCC, под Debian или rpm и только для x86_64 Linux. При совпадении внедренный код перехватывает выполнение, заменяя два ИФУНК преобразователи, поэтому определенные вызовы заменяются. Это приводит к анализу таблиц символов в памяти (это требует времени, что привело к обнаружению, как будет объяснено позже). Дальше все становится интереснее: бэкдор устанавливает перехватчик аудита в динамический компоновщик, ожидая прибытия функционального символа RSA_public_decrypt, который перенаправляется в точку в коде бэкдора, который, в свою очередь, вызывает обратный вызов. библиотека libcrypto, предположительно для выполнения обычной аутентификации. И полезная нагрузка активируется, если запущенная программа имеет имя процесса. / usr / sbin / sshd. Было ясно, что целью были SSH-серверы. Традиционно, SSHD серверы, такие как OpenSSH, не были связаны с либлзма, но sshd есть часто исправляют для поддержки systemd-notify, чтобы другие службы могли запускаться при работе sshd. И тогда liblzma косвенно загружается Systemd, замыкая круг. Бэкдор еще не полностью проанализирован, но, похоже, разрешение удаленного выполнения команд (РС) с привилегиями демона sshd, работающий в контексте предварительной аутентификации. Информация из удаленного сертификата, если она сопоставлена с бэкдором, расшифровывается с помощью ChaCha20, а в случае успешного расшифрования передается в система(). По сути, это закрытый RCE, гораздо хуже, чем простой обход открытого ключа. В более позднем архиве 5.6.1 были показаны дополнительные усилия по сокрытию следов, добавление дополнительной путаницы для имен символов и попытки исправить замеченные ошибки. Ан механизм расширения Также были созданы дополнительные тестовые файлы для поиска определенных сигнатур для добавления в бэкдор. Эта довольно сложная атака может пройти незамеченной до тех пор, пока не будут достигнуты стабильные дистрибутивы Linux. К счастью, некоторые люди любят проверять, почему происходят аномальные вещи.Раскрытие атаки XZ Backdoor
Во многих случаях внедренное вредоносное поведение обнаруживается случайно или случайно. Хорошим примером был предупреждение об устаревании («Кого волнуют предупреждения?»), что привело к открытию атака потока событий в октябре 2018 года. Еще один пользователь, предупредивший Кодеков в апреле 2021 года их скрипт загрузки bash не прошел контрольную сумму («Кто проверяет целостность артефактов с помощью контрольных сумм»?) Аномалии и странные симптомы с ssh loginс (logins отнимает много ресурсов процессора и увеличивает затраченное время, ошибки valgrind) вызвало любопытство Андрес Фройнд, бдительный разработчик PostgreSQL, но не аналитик безопасности (как он заявил). После некоторого исследования OpenSSH в Debian Sid он пришел к выводу, что проблема времени отклика связана с библиотекой. либлзма, Часть xz-утилиты библиотека сжатия. Причина: "вышестоящий репозиторий xz и архивы xz были защищены бэкдором». Эта диагностика была настолько точной! 29 марта 2024 года Андрес опубликовал в Openwall первый анализ: «бэкдор в исходном коде xz/liblzma, приводящий к компрометации ssh-сервера». Факт: архивы XZ Utils 5.6.0 и 5.6.1 содержат бэкдор. Эти архивы были созданы и подписаны вышеупомянутым аккаунтом Цзя Тана. He опубликовано в Мастодонте позже в тот же день, осознав, что открытие было случайным и требовало множества совпадений. Комментарии других пользователей заслуживают внимания. Пользователь GitHub тот же сам (он же Сэм Джеймс) опубликовал хороший Gist Часто задаваемые вопросы о бэкдоре xz-utils где обобщалась атака, ссылаясь на более углубленный анализ атакующей полезной нагрузки. Эти анализы были технически содержательными и помогли нам лучше понять инъекцию, которая была тщательно продумана:- xz/liblzma: объяснение обфускации на этапе Bash. Хороший анализ деобфускации с помощью скрипта инъекции, в четыре «этапа».
- Голубая нить Филиппо Вальсорды Анализ самого бэкдора в RSA_public_decrypt, который показывает его природу: RCE, а не обход аутентификации и закрытый (принимает закрытый ключ автора, а если нет, возвращается к нормальному поведению)/невозвратный. Автор намеревался вести себя сдержанно, чтобы избежать обнаружения!
- Анализ бэкдора XZ от @smx-smx (WIP) — Дополнительный анализ бэкдора (чуть ли не в начале заблудился 😀)
- Вики-документация по бэкдору xz, еще один разбор скрипта внедрения 5.6.1.
Как разрешился инцидент
Раскрытие информации Андреасом Фройндом было осторожным, поскольку, по его собственным словам:«Учитывая очевидное участие в разработке, я не сообщал об ошибке в разработке. Поскольку я изначально думал, что это проблема, специфичная для Debian, я отправил более предварительный отчет на security@...ian.org. Впоследствии я сообщил о проблеме на distros@. CISА был уведомлен путем рассылки».
Red Hat присвоила этой проблеме CVE-2024-3094. Затем это слово распространилось как лесной пожар. Лассе Коллин, другой специалист по обслуживанию XZ, добавил новый commit в субботу, 30 марта, под названием «CMake: исправление саботированной проверки песочницы Landlock». Один из методов изолирования библиотеки от песочницы был саботирован, по крайней мере, при сборке с помощью CMake. Он сразу же раскрыл эту проблему в Бэкдор XZ Utils. Red Hat назначила эту проблему CVE-2024-3094 (см. также в CVE, NVD, Ubuntu). Ему была присвоена колоссальная Базовый балл CVSS 10. Такие оценки всегда сводят с ума Интернет. CISА в тот же день, 29 марта, выпустил бдительный, возможно, слишком упрощенный из-за срочности, рекомендующий пользователям перейти на стабильную версию 5.4.6. Репозитории GitHub организации Tukaani были отключены (хорошо это или плохо? Я думаю, хорошо: многие дистрибутивы и организации все еще ссылались на выпуски GitHub в качестве источника зараженных архивов для сборки. Отключение репозитория предотвращает это. В любом случае есть копия или репозитории в git.tukaani.org). Аккаунты GitHub JiaTan75 и Lasse Collins (Larhzu) также были заблокированы. Это часть политика сдерживания, даже если это может затронуть невинных людей. ЦзяТ75 активность в неотключенных репозиториях пока нельзя увидеть. Промышленность отреагировала незамедлительно. Многие производители опубликовали правила обнаружения уязвимых систем, например Яра рулитили поддержка коммерческих инструментов от системная копия, PAN, и другие. Специалисты по безопасности любят Джеймс Бертоти опубликовал обзор нашего подхода к программному обеспечению с открытым исходным кодом. Сейчас мы находимся на этапе ликвидации и восстановления инцидента. Другие проекты, поддерживаемые JiaTan75, находятся под пристальным вниманием, в частности лиархив/библиотека (где JiaTan75 был постоянным участником) и фаззер ОСС-ФУЗЗ (где это commit автор JiaTan75 постарался избежать oss-fuzz, что на самом деле не смог обнаружить бэкдор). Эти попытки сокрытия добавляют дополнительные доказательства.
Кто находится под атакой?
Либо учетная запись GitHub JiaT75 была скомпрометирована (помните, что GitHub недавно ввел 2FA), либо физический пользователь, владеющий этой учетной записью, перешел на темную сторону. Но есть веские причины думать о продвинутой постоянной угрозе (APT), возможно, поддерживаемой государством, из-за технической сложности атаки. Дальнейшее расследование органов кибербезопасности и правоохранительных органов покажет… Эта запись в YCombinator Hacker News о Цзя Тане проливает некоторый свет на «кто» и его деятельность. Рекомендуемые! Он дает много информации о том, как злоумышленники пытаются обмануть других пользователей, используя социальную инженерию.«Очень досадно — предполагаемый автор бэкдора общался со мной (rwmj) в течение нескольких недель, пытаясь добавить xz 5.6.x в Fedora 40 и 41 из-за «отличных новых функций». Мы даже работали с ним над исправлением проблемы valgrind (которая, как выяснилось, была вызвана добавленным им бэкдором). Вчера вечером нам пришлось помчаться, чтобы решить проблему после непреднамеренного нарушения эмбарго. Он участвовал в проекте xz в течение двух лет, добавляя всевозможные бинарные тестовые файлы, и, честно говоря, с таким уровнем сложности я бы с подозрением относился к даже более старым версиям xz, пока не будет доказано обратное».
Цзя Тан принял меры, чтобы его не отслеживали: похоже, для подключения он использовал VPN (vpn.singapore.witopia.net), что само по себе нормально. И многие изменения, похоже, подкреплены временными одноразовыми электронными письмами (в данном случае от ProtonMail), призывающими объединить изменения. Актер может захотеть пойти еще глубже, вплоть до ядра Linux, поскольку он является участником xy-встроенный проект. Первоначальный анализ на сегодняшний день не выявил никаких признаков выкидыша. Примечание: другое скромный участник XZ «Ханс Янсен» (пользователь GitHub «hansjans162») под пристальным вниманием. Его учетная запись в Debian теперь заблокировал. Он сделал много обновлений для Debian Games, чтобы скрыть то, что он хотел, в debian/xz-utils, обновление для исходной версии 5.6.1, чтобы поторопиться с распространением бэкдора для Debian/нестабильный. Все, что мы можем сказать на данный момент, это то, что это (пока неопознанный) APT, использующий разные учетные записи, работающий над этой кампанией не менее двух лет и терпеливо работающий над внедрением RCE в SSH.
Можно ли было предотвратить атаку через бэкдор XZ?
Довольно сложно. Во-первых, часть внедренного бэкдора попала в сжатые тестовые файлы, которые не использовались тестами. Оглядываясь назад, это могло бы вызвать некоторые (шумные) тревоги, но кого волнует проверка того, что все тестовые файлы используются реальными тестами в реальном мире? Во-вторых, часть внедренного бэкдора попала в макрофайлы в релизные tarballs, и сложно вручную проверить различия с ожидаемыми tarballs. Автоматизация также сложна, поскольку ожидаемый результат от самой сборки (для тех, кто знает, как работает automake/autoconf) трудно смоделировать для анализа того, соответствует ли реальный tarball ожиданиям. Некоторые это ставили as «Несовпадение архивов с деревом git — это особенность, а не ошибка». Происхождение бинарных архивов из исходного кода является нерешенной проблемой. Репутация пользователя? Что ж, аккаунт JiaTan75 на GitHub в прошлом не совершал мошеннических действий. commitс. Его приостановили только после того, как были собраны доказательства, но до 29 марта это был обычный пользователь, занимавшийся обычными делами. Ну, не так уж и нормально. Позже commitс (этой, этой, этой и этой который скорректировал код эксплойта) пытался исправить ошибки valgrind и сбои в некоторых конфигурациях из-за различий с компоновкой стека, ожидаемой бэкдором. Commit обзоры могут это обнаружить, но у кого хватит терпения анализировать изменения в двоичном тестовом файле или реальную мотивацию для изменения атрибутов GCC в исходном коде C? Следует ли поднимать тревогу, когда SSH login занимает 800 мс вместо 300 мс? Вероятно, только сверхблагоразумные люди обратят на это внимание. Цицерон сказал: «Оспешность свойственна молодости; благоразумие до старости». Инфраструктура ifunc была добавлена в июне 2023 года Хансом Янсеном и Цзя Таном. Это первый commit добавление поддержки ifunc в crc64_fast.c (позже использованное для внедрения бэкдора). За несколько месяцев до внедрения бэкдорных двоичных файлов в тестовые файлы!
Примечание: Автор и commitЗдесь есть различия, но это нормально: Лассе Коллин — сопровождающий проекта, и он объединил изменения. Он даже благодарит «Ханса Янсена»…
До публикации Андреса Фройнда и CVE, созданного RedHat, никто не высказывал опасений. Если вы видите каскад инструментов, которые могут это отловить, они сразу же обнаруживают затронутый компонент. постфактум.
Вероятно, лучшая профилактика исходит из природы дистрибутивов Linux и того, что нестабильные, новейшие версии переходят в стабильные дистрибутивы только после определенного процесса.
Уроки, извлеченные из атаки XZ bBackdoor
Мы отметили, насколько трудно обнаружить умышленный бэкдоры. Бэкдоры следует рассматривать как внутреннюю угрозу, поскольку они устанавливаются внутренним персоналом или через скомпрометированные внутренние учетные записи. И этим ребятам больше всего доверяют. А когда бэкдор внедряется в распределенный артефакт, его становится сложнее обнаружить.
Некоторые авторы, такие как Кевин Бомонт указал на система, что открывает большую поверхность атаки сторонних сервисов на бэкдор. Вот чем здесь злоупотребил плохой актер. У Systemd много глаз, но XZ — малоизвестная библиотека в цепочке. «Когда верхнее течение заражено, все пьют отравленную воду ниже по течению».
Несвязанный запрос на изменение в системе для динамическая загрузка библиотек сжатия, который удалил бы бэкдор, уже был интегрирован в систему, но еще не доставлен. Дополнительные зависимости, введенные libsystemd, могут быть источником уязвимостей.и вчера этот запрос был открыт.
A комментарий в разделе «xz: отключите ifunc, чтобы исправить проблему» commit дал четкое представление о том, на чем следует сосредоточить внимание, если мы хотим предотвратить такую деятельность (выделено мной):
«Урок, который мы должны усвоить как сообщество, заключается в том, чтобы обеспечить software supply chain security в целом, аудит систем сборки, помимо исходного кода. Например, взлом SolarWinds, когда злоумышленники модифицировали обновления программного обеспечения для программного обеспечения мониторинга SolarWinds с закрытым исходным кодом».
Раннее обнаружение и быстрая реакция настолько ограничили воздействие. Если вы помните финальная сцена из Люди в черном III: "Это было близко". И снова К. не забыл оставить чаевые. И ни один боглодит не вошел в стабильные дистрибутивы Linux.
1. «Я *не* специалист по безопасности и не занимаюсь реверс-инжинирингом». 2. Цзя — распространённое китайское имя. Тан — также распространённая фамилия, означающая «великолепный». Многие люди, не состоящие в родстве, носят это имя, пожалуйста, не осуждайте никого, кто носит это имя!
