Взлом 400+ пакетов Arch Linux AUR: как украли учётные данные и установили руткит через eBPF

В минувшую неделю в сообществе Arch Linux произошла крупная атака: злоумышленники получили контроль над более чем 400 пакетами в Arch User Repository (AUR), изменив их сценарии сборки так, чтобы на каждой машине, где эти пакеты устанавливались или обновлялись, автоматически запускался вредоносный бинарный файл. Этот инструмент, написанный на Rust, специализируется на извлечении конфиденциальных данных — от токенов API до файлов конфигурации. При наличии прав root он способен загрузить eBPF-руткит, который скрывает присутствие вредоноса в системе. Важно, что AUR — это стороннее хранилище, отдельное от официальных репозиториев Arch, которые не пострадали. Пользователи, установившие или обновившие пакеты 11 июня или позже, должны немедленно проверить списки скомпрометированных пакетов, чтобы избежать утечки данных.

Атака не использовала уязвимости в ядре или системных библиотеках. Вместо этого преступники эксплуатировали доверие пользователей к именам и истории пакетов. Злоумышленники выбирали заброшенные проекты — пакеты, оставленные прежними сопровождающими без обновлений. Они принимали на себя сопровождение таких пакетов, изменяли файлы сборки и подменяли метаданные git, чтобы изменения выглядели как работа легитимного сопровождающего. Впоследствии один из доверенных пользователей Arch Linux подтвердил, что аккаунт сопровождающего не был взломан. После захвата пакета в сценарий сборки PKGBUILD или .install добавлялась команда npm install atomic-lockfile@1.4.2. Этот npm-пакет, в свою очередь, содержал легитимные зависимости и хук preinstall, который загружал и исполнял ELF-файл deps. Стоило пользователю собрать пакет — как вредоносный бинарник начинал работу в системе.

Среди подтверждённых примеров, о которых сообщалось на рассылку Arch, значатся пакеты alvr и premake-git. Независимый исследователь Whanos провёл реверс-инжиниринг payload и описал вредоносную программу на Rust, нацеленную на рабочие станции разработчиков и системы сборки. Она собирает файлы конфигурации, токены, ключи SSH, историю браузера и другие артефакты, представляющие ценность. Передача данных происходит по протоколу HTTP на временный сервис temp.sh. Для управления ботнетом используется onion-сервис Tor, доступ к которому осуществляется через локальный прокси. Для обеспечения живучести вредонос устанавливает системный сервис с политикой автоматического перезапуска. При наличии прав root он копирует себя в /var/lib/ и создаёт unit-файл в /etc/systemd/system/, а при работе без root — в домашний каталог пользователя с unit-файлом в ~/.config/systemd/user/.

Как атака обманула механизмы доверия в Arch Linux

Arch User Repository — это крупнейшая коллекция сторонних пакетов, поддерживаемая сообществом. В отличие от официальных репозиториев, где каждое изменение проходит проверку, AUR полагается на доверие к сопровождающим. Когда проект остаётся без внимания, любой желающий может заявить о себе как о новом сопровождающем и изменить сценарий сборки. Преступники воспользовались этим: они нашли заброшенные пакеты, изменили их PKGBUILD и .install, а также подменили git-коммиты, чтобы выглядеть как легитимные изменения от прежнего сопровождающего. Подмена метаданных — ключевой элемент атаки, так как git-журнал остаётся частью истории пакета и вызывает доверие у пользователей.

Поскольку AUR не проверяет подписи кода на уровне репозитория, изменения в сценариях сборки проходят без дополнительных проверок. Пользователь, который видит знакомое имя пакета и привычную историю коммитов, с большой вероятностью доверяет сборке. Злоумышленники не взламывали серверы Arch или доверенных пользователей — они просто воспользовались открытым процессом передачи сопровождения. Это делает атаку особенно коварной: вредоносный код не прячется в бинарнике, а встраивается в этап сборки, который выполняется на машине пользователя. Таким образом, даже если пакет прошёл проверку на легитимность, его установка запускает вредоносный payload.

Технические детали вредоноса: от сбора данных до скрытого присутствия

Вредоносный бинарник deps, написанный на Rust, нацелен на рабочие станции и CI-системы, где хранятся токены доступа, ключи SSH и конфигурационные файлы. Он собирает данные из стандартных мест: ~/.ssh/, ~/.gnupg/, ~/.docker/, ~/.aws/, ~/.npmrc, а также браузерных профилей. Скомпилированный ELF-файл не вызывает подозрений — он маскируется под легитимные зависимости, которые npm загружает вместе с atomic-lockfile. После запуска вредонос проверяет наличие прав root и выбирает способ установки persistency. В случае успеха он регистрирует себя как системный сервис, который будет автоматически перезапускаться даже после перезагрузки.

Для сокрытия активности используется eBPF-руткит, загружаемый при наличии root. eBPF позволяет внедрять код в ядро Linux, перехватывать системные вызовы и скрывать процессы, файлы и сетевые соединения. Вредонос использует эту технологию, чтобы скрыть свой бинарник, процессы и исходящий трафик, направленный на temp.sh. Управление ботнетом осуществляется через onion-сервис Tor, что усложняет обнаружение и блокировку командного центра. Локальный прокси на loopback-адресе скрывает реальный IP-адрес сервера управления, делая инфраструктуру более устойчивой к расследованиям.

Кто и почему стал целью: разработчики и их секреты

Целевой аудиторией атаки являются разработчики и DevOps-инженеры, работающие в среде Arch Linux. Их рабочие станции часто содержат токены доступа к облачным платформам, ключи SSH к серверам, конфигурации CI/CD и другие критически важные артефакты. Скомпрометировав такую машину, злоумышленники получают доступ не только к локальным данным, но и к корпоративным ресурсам через украденные учётные данные. Это делает атаку особенно прибыльной: преступники могут продать доступ к внутренним сетям или использовать украденные токены для развёртывания дополнительных вредоносов.

Наличие eBPF-руткита говорит о высоком уровне подготовки атакующих. Они не только крадут данные, но и обеспечивают себе долгосрочное присутствие в системе, что позволяет им оставаться незамеченными в течение длительного времени. Это особенно опасно для команд, которые не используют мониторинг активности в ядре или не проверяют системные вызовы на уровне eBPF. Вредонос может оставаться в системе месяцами, периодически отправляя новые порции данных на temp.sh.

Как проверить свои системы и что делать, если вы пострадали

Если вы установили или обновили пакеты из AUR 11 июня или позже, немедленно проверьте их на наличие в списке скомпрометированных. Списки публикуются на форумах Arch Linux, в рассылках и на страницах GitHub некоторых исследователей. Проверьте не только имя пакета, но и его версию — злоумышленники могут использовать разные версии или ветки для распространения вредоноса. Если пакет числится в чёрном списке, удалите его и все связанные зависимости, затем выполните аудит файловой системы на наличие подозрительных бинарников в /var/lib/ и ~/.local/share/.

После удаления вредоноса проверьте учётные данные: смените пароли, токены и ключи SSH, особенно если они хранились на пострадавшей машине. Убедитесь, что ни один из ваших сервисов не был скомпрометирован через украденные учётные данные. Если вы работаете в команде, предупредите коллег и предложите им провести аналогичную проверку. Также рекомендуется отключить системные сервисы, которые вы не используете, и ограничить права пользователей на выполнение опасных команд.

Почему этот инцидент важен для всего Linux-сообщества

Атака на AUR — это не первый и не последний случай, когда злоумышленники эксплуатируют доверие к сторонним репозиториям. Она показывает, как хрупок механизм доверия в экосистеме Arch Linux, где любой может заявить о себе как о сопровождающем и изменить сценарий сборки. Это ставит под угрозу не только отдельных пользователей, но и целые команды, полагающиеся на AUR для установки ПО. Инцидент подчёркивает необходимость более строгих проверок для сторонних хранилищ, включая обязательную подпись сценариев сборки и аудит изменений.

Для пользователей Arch Linux это сигнал к тому, чтобы пересмотреть подход к установке пакетов из AUR. Если раньше многие доверяли сторонним пакетам без дополнительных проверок, то теперь стоит задуматься о ручной сборке или использовании официальных репозиториев. Администраторам систем следует внедрить мониторинг установленных пакетов, проверку контрольных сумм и ограничение прав пользователей на выполнение опасных команд. Для сообщества это возможность пересмотреть процессы управления AUR и сделать экосистему более устойчивой к подобным атакам.

Что дальше: как сообщество борется с последствиями и что ожидать

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

Для пользователей Arch Linux важно следить за официальными каналами информации: форумами, рассылками и страницами Trusted Users. Если вы используете AUR, рассмотрите возможность временного отключения хранилища до стабилизации ситуации. Также стоит обратить внимание на инструменты для автоматического сканирования пакетов на наличие подозрительных изменений. В долгосрочной перспективе сообщество может внедрить более строгие механизмы аутентификации для передачи сопровождения, чтобы предотвратить подобные атаки в будущем.

Практический чек-лист для пользователей Arch Linux

1. Проверьте, не устанавливали ли вы пакеты из AUR 11 июня или позже. Сверьте их с актуальными списками скомпрометированных пакетов.
2. Удалите подозрительные пакеты и все связанные зависимости. Используйте команду pacman -Rns имя_пакета для полной очистки.
3. Выполните аудит системы: проверьте /var/lib/, ~/.local/share/ и ~/.config/systemd на наличие незнакомых бинарников или сервисов.
4. Смените пароли, токены и ключи SSH, особенно если они хранились на пострадавшей машине.
5. Отключите системные сервисы, которые вы не используете, и ограничьте права пользователей.
6. Рассмотрите возможность временного отключения AUR до стабилизации ситуации.
7. Следите за официальными каналами Arch Linux для получения обновлений и рекомендаций.
8. Если вы разработчик, проверьте свои CI/CD-системы и токены доступа к облачным платформам.

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