Atomic Arch: Безпрецедентна атака на AUR, що скомпрометувала майже 2000 пакетів

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

Метод атаки: експлуатація довіри

Atomic Arch не була зламом інфраструктури Arch Linux. Натомість це було хірургічно точне використання процесу прийняття покинутих пакетів в AUR — механізму, який дозволяє будь-якому члену спільноти взяти на себе відповідальність за занедбані програми .

Атака розгорталася двома хвилями, причому зловмисники постійно вдосконалювали методи, щоб уникнути виявлення.

Хвиля 1: Пастка через npm (11 червня)

Зловмисники систематично брали під контроль покинуті пакети. Отримавши права супроводжувача, вони не змінювали вихідний код програмного забезпечення. Це б порушило контрольні суми та викликало тривогу. Натомість вони модифікували скрипти збірки PKGBUILD, додавши шкідливі залежності npm: atomic-lockfile (v1.4.2) та js-digest (v4.2.2) . Ці пакети були налаштовані на автоматичне виконання під час процесу makepkg. Для додаткового маскування код вбудовувався у скрипти .install та приховувався за допомогою розбиття рядків, змішаного цитування та шістнадцяткових escape-послідовностей .

Хвиля 2: Перехід на Bun (12 червня)

Лише через день з'явилася друга хвиля. Цього разу атакуючі замінили шлях встановлення через npm на процес на основі Bun, використовуючи інший шкідливий пакет під назвою lockfile-js (v1.4.2) . Ця зміна ускладнила виявлення, оскільки початкові індикатори компрометації були зосереджені на реєстрі npm, і інструменти безпеки довелося оновлювати для моніторингу нового середовища виконання .

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

Шкідливе навантаження: Викрадач та Руткіт

На машини, які компілювали скомпрометовані пакети, доставлялося двоетапне навантаження, призначене для шпигунства та забезпечення постійної присутності.

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

Комбінація викрадача облікових даних та руткіта на рівні ядра становила надзвичайно серйозну загрозу, особливо для робочих станцій розробників, які часто містять привілейовані ключі доступу та чутливі дані.

Реакція спільноти

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

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

Ключовим джерелом тертя стало те, що офіційна команда Arch не одразу опублікувала єдиний канонічний список усіх уражених пакетів. Це змусило користувачів покладатися на сторонні списки від таких джерел, як SafeDep та Corgea .

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

Атака Atomic Arch оголила структурні вразливості репозиторіїв, що підтримуються спільнотою на волонтерських засадах.

• Пастка покинутих пакетів — це системний ризик: Можливість для будь-якого користувача миттєво прийняти та модифікувати покинутий пакет без верифікації особи чи обов'язкового перегляду коду перетворила зручну функцію на вектор атаки з високим рівнем впливу .
• Ін'єкції на етапі збірки оминають перевірки цілісності: Традиційні механізми захисту покладаються на перевірку цілісності архівів вихідного коду. Оскільки 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 протягом вікна атаки, повинен розглядатися як інцидент безпеки, що потребує повноцінного реагування .