Arch Linux 12 июня временно ограничил часть операций в AUR после волны вредоносных изменений в пользовательских пакетах. Для разработчиков и DevOps-команд это не локальная история про один дистрибутив, а наглядный сбой в цепочке поставки: атакующим не понадобился ни взлом инфраструктуры Arch, ни zero-day, им хватило права забрать заброшенный пакет и подменить сценарий сборки.
Официально проект предупредил, что из-за расследования пользователи могут столкнуться с проблемами при регистрации новых аккаунтов, публикации обновлений, а также при усыновлении и создании пакетов в AUR. Речь идет именно о пользовательском репозитории AUR, а не об официальных пакетах Arch Linux.
Ограничения ввели после волны вредоносных усыновлений
В сообщении Arch Linux говорится о «большом количестве вредоносных усыновлений пакетов и обновлений» в AUR. Это важная формулировка: проблема возникла не из-за компрометации центральной инфраструктуры, а из-за механики сопровождения пакетов, где заброшенный проект может перейти новому сопровождающему.
Компания Sonatype и BleepingComputer писали, что первая волна затронула более 400 пакетов, а позднее оценка выросла примерно до 1500. Цифра менялась по мере разбора инцидента, поэтому корректнее говорить не о финальном списке, а о крупной и быстро растущей кампании.
Атака шла через PKGBUILD и вредоносную зависимость
По данным Sonatype, злоумышленники брали под контроль заброшенные пакеты и меняли PKGBUILD так, чтобы при установке подтягивался вредоносный npm-пакет atomic-lockfile. Дальше уже запускался ELF-файл deps, который исследователи описывают как стилер с признаками руткита на eBPF.
Разбор, на который ссылается BleepingComputer, показывает, что вредонос собирал чувствительные данные с машин разработчиков: SSH-артефакты, токены GitHub и npm, данные браузеров, Slack, Discord, Microsoft Teams, HashiCorp Vault и другие локальные секреты. То есть мишенью был не «обычный Linux-пользователь», а рабочая станция, с которой можно пойти дальше в Git, облако и CI/CD.
Для инженерных команд это риск шире одного ноутбука
Проблема AUR в том, что многие компании относятся к нему как к удобному складу недостающего софта: пакет поставили на ноутбук разработчика, потом в образ для сборки, потом на внутренний сервер. Пока все спокойно, это экономит время. Когда через тот же канал приезжает стилер, компрометация одного хоста быстро превращается в утечку ключей, токенов и доступов к соседним системам.
Практический вывод простой. Если в инфраструктуре есть AUR-пакеты, которые ставили или обновляли во время июньской кампании, такие машины стоит проверять как потенциально скомпрометированные: аудит PKGBUILD, ревизия сетевой активности, ротация SSH-ключей и токенов, отдельный запрет или хотя бы жесткое ревью AUR в CI/CD и на серверах. В этой истории дорогим оказался не сам пакет, а доверие к нему.
Следующий шаг для Arch Linux очевиден: закрыть лазейку в процессе усыновления пакетов так, чтобы удобство сообщества не превращалось в готовый канал для supply chain-атак.
Источники: Arch Linux, BleepingComputer, Sonatype.