400 пакетов, одна старая лазейка — и доступ ко всему: от браузера до криптокошельков.
В Arch User Repository нашли масштабную атаку на цепочку поставок. В выходные злоумышленники получили контроль более чем над 1900 пакетами и изменили их сценарии сборки. После этого при установке или обновлении зараженного пакета на машине пользователя запускались компоненты для кражи учетных данных, закрепления в системе и скрытия активности. Официальные репозитории Arch Linux не пострадали. Проблема затронула именно AUR - пользовательский каталог пакетов, который поддерживает сообщество.
AUR устроен не так, как обычный репозиторий дистрибутива. Пользователь часто получает не готовую программу, а рецепт сборки с адресом исходного кода, списком зависимостей и командами для установки. Именно в эти рецепты злоумышленники добавили вредоносные команды . Названия пакетов, история проектов и накопленное доверие к ним при этом оставались прежними.
На AUR размещено около 100 000 пакетов. Почти десятая часть из них относится к осиротевшим, потому что прежние сопровождающие больше не поддерживают эти проекты. Такие пакеты стали удобной целью для атаки. Злоумышленник мог взять заброшенный проект на сопровождение, изменить сценарии сборки и дождаться, пока пользователи установят обновление обычным способом.
Sonatype назвала кампанию Atomic Arch. Атакующие искали заброшенные пакеты , у которых больше не было активного сопровождающего. В AUR такие проекты можно взять на сопровождение, и этим воспользовались злоумышленники. Они забирали старые пакеты, меняли PKGBUILD или сценарии установки .install и ждали, пока пользователи сами запустят сборку.
Атака не использовала уязвимость в Arch Linux и не требовала взлома инфраструктуры дистрибутива. Слабым местом стала сама модель сопровождения AUR, где осиротевший пакет может получить новый сопровождающий. Пользователь видел знакомый пакет, обновлял или собирал его обычным способом, а вредоносный код запускался уже на этапе сборки. Инцидент неприятен тем, что пакету доверяли по имени и прошлым заслугам, а вот проверить, кто сопровождает его сегодня, многие пользователи не успели или не посчитали нужным.
В измененные сценарии добавляли установку пакета atomic-lockfile из npm. На первый взгляд команда могла сойти за обычную зависимость, тем более рядом добавлялись легитимные пакеты для маскировки. Но в atomic-lockfile 1.4.2 был предустановочный сценарий preinstall. Он запускал вложенный исполняемый файл для Linux с именем deps. После сборки зараженного AUR-пакета этот файл уже работал на машине пользователя.
Среди подтвержденных примеров упоминались alvr и premake-git. Сначала речь шла примерно о 400 захваченных пакетах, затем оценка выросла до 1500, а к моменту новых подсчетов список приблизился к 2000. Сейчас в обновлениях указывают более 1900 затронутых AUR-пакетов. Постоянно обновляемый перечень доступен на странице Arch Linux .
Исполняемый файл deps разобрал независимый исследователь Whanos. По его анализу, это написанный на Rust стилер для рабочих станций разработчиков и сборочных окружений. Он собирает данные из браузеров на базе Chromium, включая Chrome, Edge и Brave, вытаскивает сессии из приложений на Electron вроде Slack, Discord и Microsoft Teams, ищет токены GitHub, npm, HashiCorp Vault, данные доступа к OpenAI и ChatGPT, SSH-ключи, known_hosts, историю командной оболочки, учетные данные Docker и Podman, а также <span class="vpn-highlight" title="Использование VPN может нарушать законодательство РФ">VPN</span>-профили.
Украденные файлы отправлялись через HTTP на temp.sh. Команды управления шли через скрытый сервис Tor с локальным прокси. Для закрепления в системе стилер создавал службу systemd с автоматическим перезапуском. При запуске с правами root он копировал себя в каталог внутри /var/lib/ и создавал файл службы в /etc/systemd/system/. Без прав администратора вредоносный файл использовал домашний каталог пользователя и пользовательскую службу systemd в ~/.config/systemd/user/.
Отдельный интерес вызвал руткит на eBPF , который упоминался в ранних разборах. Его роль важно не преувеличивать. Этот компонент не дает стилеру права администратора и не помогает повышать привилегии. Он загружается только тогда, когда вредоносный файл уже запущен с правами root и получил нужные возможности. Если руткит все же активировался, он может скрывать процессы, имена процессов и сетевые сокеты от стандартных инструментов, а также мешать отладке.
Поэтому простого удаления зараженного AUR-пакета недостаточно. Пакетный менеджер уберет только файлы, о которых знает. Если стилер уже запускался, особенно с правами root, системе больше нельзя доверять. В таком случае безопаснее считать машину скомпрометированной, немедленно менять пароли, токены, ключи доступа и сессии разработчика, а при возможной активации руткита - переустанавливать систему с доверенного носителя.
В анализе также упоминается второй файл, связанный с monero-wallet-gui. Его пока не разобрали полностью, но исследователи рассматривают файл как возможный майнер Monero. Сочетание кражи секретов, закрепления в системе и дополнительного руткита на eBPF делает кампанию опаснее обычного вредоносного пакета из пользовательского репозитория.
Позже появилась вторая волна атаки. В ней использовали уже не atomic-lockfile, а установку js-digest через bun. По последним данным, атакующий начал менять процедуру установки и переходить с npm на Bun-скрипты, чтобы обходить проверки и попытки блокировки. Эту активность связывают с отдельным набором аккаунтов, которые участники сообщества сопоставили с тем же автором пакета npm, что и atomic-lockfile. Полный масштаб второй волны пока считают, но пользователям советуют проверять следы обеих зависимостей.
Разработчики Arch удаляют вредоносные коммиты, блокируют связанные аккаунты и просят пользователей сообщать о подозрительных пакетах в рассылке. Опубликованные списки нельзя считать окончательными. Часть изменений уже откатывают, часть пакетов могли изменить повторно, а новые совпадения продолжают находить через поиск по зеркалам AUR. По сообщениям участников разбора, попытки перехвата пакетов продолжались и после первых блокировок.
Пользователям Arch Linux, которые устанавливали или обновляли AUR-пакеты с 11 июня, стоит проверить их по актуальным спискам затронутых проектов. Особое внимание нужно обратить на пакеты, которые недавно сменили сопровождающего, долго не обновлялись, а затем внезапно получили новые сценарии установки или команды для загрузки зависимостей. Если зараженный пакет успел собраться и запуститься, нужно исходить из того, что могли быть украдены браузерные сессии, SSH-ключи, токены GitHub и npm, учетные данные Docker, Vault, мессенджеров и облачных сервисов. Сколько пользователей успели загрузить взломанные пакеты во время атаки, пока неизвестно.
Для обнаружения опубликован SHA-256 основного вредоносного файла 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b. Полный набор индикаторов, включая адрес скрытого сервиса Tor, приведен в разборе ioctl.fail. Sonatype отслеживает кампанию как Sonatype-2026-003775 с оценкой CVSS 8.7. CVE для атаки не назначали, потому что речь идет не об уязвимости в конкретной программе, а о компрометации пакетов через модель сопровождения AUR.
Исследователи пока не установили, кто стоит за атакой. Похожая схема уже встречалась в 2018 году, когда атакующие забрали заброшенный пакет просмотрщика PDF и добавили вредоносный код. В 2026 году тот же прием просто масштабировали. Вместо попытки обмануть пользователя похожим названием злоумышленники брали реальные старые пакеты.
Атака хорошо показывает слабое место AUR. Пользовательский репозиторий удобен, потому что в нем много софта и низкий порог добавления пакетов. Но та же открытость требует привычки читать PKGBUILD и .install-файлы перед сборкой. Если пакет недавно сменил сопровождающего или внезапно начал выполнять новые команды установки, к нему стоит относиться как к незнакомому проекту, даже если его имя давно есть в AUR.
В Arch User Repository нашли масштабную атаку на цепочку поставок. В выходные злоумышленники получили контроль более чем над 1900 пакетами и изменили их сценарии сборки. После этого при установке или обновлении зараженного пакета на машине пользователя запускались компоненты для кражи учетных данных, закрепления в системе и скрытия активности. Официальные репозитории Arch Linux не пострадали. Проблема затронула именно AUR - пользовательский каталог пакетов, который поддерживает сообщество.
AUR устроен не так, как обычный репозиторий дистрибутива. Пользователь часто получает не готовую программу, а рецепт сборки с адресом исходного кода, списком зависимостей и командами для установки. Именно в эти рецепты злоумышленники добавили вредоносные команды . Названия пакетов, история проектов и накопленное доверие к ним при этом оставались прежними.
На AUR размещено около 100 000 пакетов. Почти десятая часть из них относится к осиротевшим, потому что прежние сопровождающие больше не поддерживают эти проекты. Такие пакеты стали удобной целью для атаки. Злоумышленник мог взять заброшенный проект на сопровождение, изменить сценарии сборки и дождаться, пока пользователи установят обновление обычным способом.
Sonatype назвала кампанию Atomic Arch. Атакующие искали заброшенные пакеты , у которых больше не было активного сопровождающего. В AUR такие проекты можно взять на сопровождение, и этим воспользовались злоумышленники. Они забирали старые пакеты, меняли PKGBUILD или сценарии установки .install и ждали, пока пользователи сами запустят сборку.
Атака не использовала уязвимость в Arch Linux и не требовала взлома инфраструктуры дистрибутива. Слабым местом стала сама модель сопровождения AUR, где осиротевший пакет может получить новый сопровождающий. Пользователь видел знакомый пакет, обновлял или собирал его обычным способом, а вредоносный код запускался уже на этапе сборки. Инцидент неприятен тем, что пакету доверяли по имени и прошлым заслугам, а вот проверить, кто сопровождает его сегодня, многие пользователи не успели или не посчитали нужным.
В измененные сценарии добавляли установку пакета atomic-lockfile из npm. На первый взгляд команда могла сойти за обычную зависимость, тем более рядом добавлялись легитимные пакеты для маскировки. Но в atomic-lockfile 1.4.2 был предустановочный сценарий preinstall. Он запускал вложенный исполняемый файл для Linux с именем deps. После сборки зараженного AUR-пакета этот файл уже работал на машине пользователя.
Среди подтвержденных примеров упоминались alvr и premake-git. Сначала речь шла примерно о 400 захваченных пакетах, затем оценка выросла до 1500, а к моменту новых подсчетов список приблизился к 2000. Сейчас в обновлениях указывают более 1900 затронутых AUR-пакетов. Постоянно обновляемый перечень доступен на странице Arch Linux .
Исполняемый файл deps разобрал независимый исследователь Whanos. По его анализу, это написанный на Rust стилер для рабочих станций разработчиков и сборочных окружений. Он собирает данные из браузеров на базе Chromium, включая Chrome, Edge и Brave, вытаскивает сессии из приложений на Electron вроде Slack, Discord и Microsoft Teams, ищет токены GitHub, npm, HashiCorp Vault, данные доступа к OpenAI и ChatGPT, SSH-ключи, known_hosts, историю командной оболочки, учетные данные Docker и Podman, а также <span class="vpn-highlight" title="Использование VPN может нарушать законодательство РФ">VPN</span>-профили.
Украденные файлы отправлялись через HTTP на temp.sh. Команды управления шли через скрытый сервис Tor с локальным прокси. Для закрепления в системе стилер создавал службу systemd с автоматическим перезапуском. При запуске с правами root он копировал себя в каталог внутри /var/lib/ и создавал файл службы в /etc/systemd/system/. Без прав администратора вредоносный файл использовал домашний каталог пользователя и пользовательскую службу systemd в ~/.config/systemd/user/.
Отдельный интерес вызвал руткит на eBPF , который упоминался в ранних разборах. Его роль важно не преувеличивать. Этот компонент не дает стилеру права администратора и не помогает повышать привилегии. Он загружается только тогда, когда вредоносный файл уже запущен с правами root и получил нужные возможности. Если руткит все же активировался, он может скрывать процессы, имена процессов и сетевые сокеты от стандартных инструментов, а также мешать отладке.
Поэтому простого удаления зараженного AUR-пакета недостаточно. Пакетный менеджер уберет только файлы, о которых знает. Если стилер уже запускался, особенно с правами root, системе больше нельзя доверять. В таком случае безопаснее считать машину скомпрометированной, немедленно менять пароли, токены, ключи доступа и сессии разработчика, а при возможной активации руткита - переустанавливать систему с доверенного носителя.
В анализе также упоминается второй файл, связанный с monero-wallet-gui. Его пока не разобрали полностью, но исследователи рассматривают файл как возможный майнер Monero. Сочетание кражи секретов, закрепления в системе и дополнительного руткита на eBPF делает кампанию опаснее обычного вредоносного пакета из пользовательского репозитория.
Позже появилась вторая волна атаки. В ней использовали уже не atomic-lockfile, а установку js-digest через bun. По последним данным, атакующий начал менять процедуру установки и переходить с npm на Bun-скрипты, чтобы обходить проверки и попытки блокировки. Эту активность связывают с отдельным набором аккаунтов, которые участники сообщества сопоставили с тем же автором пакета npm, что и atomic-lockfile. Полный масштаб второй волны пока считают, но пользователям советуют проверять следы обеих зависимостей.
Разработчики Arch удаляют вредоносные коммиты, блокируют связанные аккаунты и просят пользователей сообщать о подозрительных пакетах в рассылке. Опубликованные списки нельзя считать окончательными. Часть изменений уже откатывают, часть пакетов могли изменить повторно, а новые совпадения продолжают находить через поиск по зеркалам AUR. По сообщениям участников разбора, попытки перехвата пакетов продолжались и после первых блокировок.
Пользователям Arch Linux, которые устанавливали или обновляли AUR-пакеты с 11 июня, стоит проверить их по актуальным спискам затронутых проектов. Особое внимание нужно обратить на пакеты, которые недавно сменили сопровождающего, долго не обновлялись, а затем внезапно получили новые сценарии установки или команды для загрузки зависимостей. Если зараженный пакет успел собраться и запуститься, нужно исходить из того, что могли быть украдены браузерные сессии, SSH-ключи, токены GitHub и npm, учетные данные Docker, Vault, мессенджеров и облачных сервисов. Сколько пользователей успели загрузить взломанные пакеты во время атаки, пока неизвестно.
Для обнаружения опубликован SHA-256 основного вредоносного файла 6144d433f8a0316869877b5f834c801251bbb936e5f1577c5680878c7443c98b. Полный набор индикаторов, включая адрес скрытого сервиса Tor, приведен в разборе ioctl.fail. Sonatype отслеживает кампанию как Sonatype-2026-003775 с оценкой CVSS 8.7. CVE для атаки не назначали, потому что речь идет не об уязвимости в конкретной программе, а о компрометации пакетов через модель сопровождения AUR.
Исследователи пока не установили, кто стоит за атакой. Похожая схема уже встречалась в 2018 году, когда атакующие забрали заброшенный пакет просмотрщика PDF и добавили вредоносный код. В 2026 году тот же прием просто масштабировали. Вместо попытки обмануть пользователя похожим названием злоумышленники брали реальные старые пакеты.
Атака хорошо показывает слабое место AUR. Пользовательский репозиторий удобен, потому что в нем много софта и низкий порог добавления пакетов. Но та же открытость требует привычки читать PKGBUILD и .install-файлы перед сборкой. Если пакет недавно сменил сопровождающего или внезапно начал выполнять новые команды установки, к нему стоит относиться как к незнакомому проекту, даже если его имя давно есть в AUR.
- Источник новости
- www.securitylab.ru