Atomic Arch: атака на цепочку поставок AUR, скомпрометировавшая 1900 пакетов

Страница кампании SafeDep и консолидированные сообществом списки в итоге насчитали 1937 затронутых названий пакетов AUR, что подчеркивает огромный охват атаки . Важно отметить, что официальные репозитории Arch Linux (core, extra, community) не пострадали — это был инцидент исключительно в AUR .

Метод атаки: использование доверия в своих целях

Atomic Arch не был взломом инфраструктуры Arch. Вместо этого злоумышленники хирургически точно использовали процедуру взятия под опеку брошенных пакетов в AUR — процесс, который позволяет любому участнику сообщества заявить права на пакеты, оставленные мейнтейнерами .

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

Первая волна: npm-ловушка (11 июня)

Атакующие систематически брали под опеку брошенные пакеты. Получив права мейнтейнера, они не изменяли сам исходный код программ — такой шаг нарушил бы контрольные суммы и поднял бы тревогу. Вместо этого они модифицировали сборочные скрипты PKGBUILD, добавив в них вредоносные npm-зависимости: atomic-lockfile (v1.4.2) и js-digest (v4.2.2) . Эти пакеты были настроены на автоматический запуск во время процесса makepkg. Чтобы еще сильнее скрыть вредоносную активность, код встраивали в скрипты .install и маскировали с помощью разбиения shell-строк, смешанных кавычек и шестнадцатеричных escape-последовательностей .

Вторая волна: переход на Bun (12 июня)

Всего через день появилась вторая волна. На этот раз атакующие заменили установку через npm на процесс установки на основе Bun, используя другой вредоносный пакет под названием lockfile-js (v1.4.2) . Такая смена усложнила обнаружение, поскольку многие из первоначальных индикаторов компрометации были ориентированы на реестр npm, и инструментам безопасности потребовалось обновление для мониторинга новой среды выполнения и зависимостей .

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

Вредоносная нагрузка: стилер и руткит

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

• Стилер учетных данных на Rust: Целенаправленная бинарная программа, которая воровала секреты разработчиков, включая сессии браузеров, SSH-ключи, токены GitHub, токены npm, сессии Slack/Teams, токены Vault, учетные данные Docker/Podman и ключи доступа к облачным сервисам .
• eBPF-руткит (только с правами root): Если пакет собирался с правами root, вредоносная программа развертывала eBPF-руткит, способный скрывать свои файлы, процессы и сетевую активность от стандартных инструментов обнаружения, таких как ps и htop. Руткит использовал /sys/fs/bpf/ для закрепления, что делало его исключительно трудным для удаления .

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

Реакция сообщества и разработчиков

Сообщество Arch Linux и индустрия безопасности отреагировали быстро, но масштаб атаки серьезно осложнил ответные меры.

• Действия команды Arch: Разработчики Arch открыли общую ветку отчетов AUR 11 июня и начали процесс отката вредоносных коммитов, бана аккаунтов атакующих и очистки пула брошенных пакетов. В следующий понедельник Arch Linux также приостановил регистрацию новых аккаунтов в AUR, чтобы предотвратить дальнейшие злоупотребления . Сопровождающий пакетов Arch Джонатан Гротелюшен подтвердил, что команда работает над тем, чтобы «восстановить или удалить все вредоносные коммиты и заблокировать ответственные аккаунты» .
• Конфликт в сообществе: Атака вызвала бурные споры. На форумах, таких как PrivacyGuides, некоторые участники сообщества призывали к полному закрытию AUR, утверждая, что его модель, основанная на доверии, была фундаментально сломана при таком масштабе компрометации .
• Реакция сторонних компаний: ИБ-компании, включая Sonatype, Corgea, Cloud Security Alliance (CSA) и TrueSec, опубликовали детальные анализы, индикаторы компрометации (IoC) и скрипты для проверки (такие как aur-malware-check), чтобы помочь пользователям провести аудит своих систем .

Основным источником трений стало то, что официальная команда Arch не сразу опубликовала единый канонический список всех затронутых пакетов, из-за чего пользователям пришлось полагаться на сторонние списки от таких источников, как SafeDep и Corgea .

Уроки для экосистемы Linux

Атака Atomic Arch обнажила структурные слабости в репозиториях сообщества, основанных на доверии и полагающихся на волонтерскую поддержку.

• Ловушка брошенных пакетов — системный риск: Возможность для любого пользователя мгновенно принять и изменить брошенный пакет без проверки личности или обязательного код-ревью превратила удобную функцию в вектор атаки с высоким потенциалом .
• Инъекция на этапе сборки обходит проверки целостности: Традиционные механизмы защиты основаны на проверке целостности tar-архивов с исходным кодом. Поскольку Atomic Arch отравлял сборочные скрипты, а не исходный код, стандартные контрольные суммы не обеспечивали никакой защиты .
• Межэкосистемные цепочки поставок — новый рубеж: Атака использовала реестры npm и Bun как оружие для распространения вредоносного ПО в экосистеме Linux, доказав, что один скомпрометированный пакет в одном реестре может вызвать каскадные последствия на разных платформах .

Что делать пострадавшим пользователям

Исследователи безопасности и рекомендации сообщества Arch единодушны: в данном случае простого удаления одного пакета недостаточно.

1. Считайте систему полностью скомпрометированной: Любой хост, который собирал или обновлял пакет AUR в период с 9 по 12 июня 2026 года, следует считать полностью скомпрометированным .
2. Переустановите систему с чистого носителя: Простое сканирование антивирусом ненадежно, потому что eBPF-руткит специально скрывается от инструментов обнаружения. Единственный гарантированный способ — пересобрать затронутую систему с доверенного установочного носителя .
3. Немедленно смените все учетные данные: Считайте, что стилер уже похитил все секреты, доступные на машине: SSH-ключи, токены GitHub и npm, токены Vault, ключи облачного доступа, сессии браузера, а также учетные данные Docker/Podman .
4. Проведите аудит истории AUR: Выполните

   pacman -Qm

   , чтобы получить список всех сторонних пакетов, установленных в системе, и сверьте их с опубликованными сообществом списками вредоносных пакетов .
5. Проверьте индикаторы компрометации: Поищите следы atomic-lockfile, lockfile-js или js-digest в кэшах сборки, а также подозрительные записи в /sys/fs/bpf/ .
6. Действуйте как при инциденте безопасности: Организациям не следует относиться к этому как к простой проверке. Любую рабочую станцию разработчика на Arch или сервер CI/сборки, который обращался к AUR в период атаки, следует рассматривать как инцидент безопасности, требующий полноценного реагирования .