Arch AUR Infected: что произошло и что делать пользователям Arch Linux#

Что произошло#

AUR — это пользовательский репозиторий Arch Linux, где пакеты поддерживаются сообществом. Именно поэтому при работе с ним всегда важно проверять PKGBUILD и другие файлы перед установкой.

В этом случае злоумышленники получили контроль над большим количеством пакетов и изменили build-скрипты так, чтобы вредоносный код запускался во время установки.

Главная проблема таких атак в том, что пользователь может думать, что просто обновляет обычный пакет, хотя на самом деле во время сборки или установки уже выполняется чужой код. Это делает AUR удобной целью для supply-chain атак: доверие к пакету используется против пользователя.

Что делало вредоносное ПО#

Согласно опубликованным данным, payload был написан на Rust и работал как credential stealer. Его цель — кража важных данных, которые могут храниться на машине пользователя: токенов, SSH-ключей, API-ключей и других секретов.

Также сообщалось, что при запуске с root-правами система могла загрузить eBPF-rootkit для скрытия вредоносной активности.

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

Что делать пользователям AUR#

Если ты используешь AUR, первое правило — не обновлять всё бездумно. Перед сборкой пакета нужно смотреть его файлы, особенно PKGBUILD, .install и любые скрипты, которые выполняются во время установки.

До проверки недавние обновления лучше считать подозрительными.

Если ты уже обновлял AUR-пакеты в период инцидента, нужно проверить, были ли установленные у тебя пакеты в списке затронутых. Если пакет был скомпрометирован и вредоносный код мог выполниться, систему стоит рассматривать как потенциально заражённую.

Что делать, если ты уже обновился#

Сначала нужно определить, были ли среди установленных AUR-пакетов те, которые попали под атаку. После этого стоит удалить затронутые пакеты и следовать рекомендациям по очистке от Arch-сообщества или сопровождающих пакетов.

Если вредоносный пакет действительно запускался, лучше считать, что данные на машине могли быть скомпрометированы. В таком случае нужно сменить важные пароли с другого, доверенного устройства.

Особенно стоит проверить SSH-ключи, API-токены, GitHub/GitLab-токены, ключи от серверов и любые секреты, которые могли храниться локально.

Также стоит пересоздать SSH-ключи и отозвать старые токены, если есть подозрение, что они могли быть доступны вредоносному коду. Просто удалить пакет недостаточно, если он уже успел выполниться.

Почему это важно#

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

Каждый пакет из AUR нужно воспринимать не как полностью доверенный бинарник, а как набор инструкций, которые будут выполнены на твоей машине.

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

Итог#

AUR не стал бесполезным или полностью небезопасным, но этот инцидент напоминает простую вещь: пользователь сам отвечает за то, что собирает и запускает на своей системе.

Если ты используешь Arch Linux и AUR, проверяй пакеты перед установкой, не обновляй всё вслепую и относись к свежим изменениям осторожно.

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