В Arch User Repository обнаружили более 400 зараженных пакетов: вредоносные пакеты AUR подтягивали на машины Linux-руткит и стилер для кражи учетных данных, токенов и рабочих секретов разработчика. Для русскоязычной IT-аудитории это не очередная страшилка про open source, а прямое напоминание: developer workstation давно стал такой же точкой входа в инфраструктуру, как прод-сервер или CI.
Об атаке сообщает BleepingComputer со ссылкой на сообщество open-source-разведки Independent Federated Intelligence Network. По данным исследователей, злоумышленник выдавал себя за доверенного мейнтейнера в AUR и через смену владельцев пакетов проталкивал зараженные обновления. Речь идет не про официальный репозиторий Arch Linux, а про AUR — пользовательский каталог PKGBUILD-скриптов, без которого многие Arch-системы в реальной жизни почти не обходятся: там лежат проприетарные приложения, nightly-сборки, старые версии утилит и прочий софт, который в официальных репозиториях не живет.
Схема атаки выглядела неприятно приземленной, а потому особенно опасной. Исследователь IFIN Майкл Таггарт пишет, что зараженные пакеты были изменены так, чтобы на этапе установки скачать и выполнить вредоносный npm-пакет atomic-lockfile. Независимый исследователь Whanos проанализировал один из образцов и обнаружил в нем ELF-бинарник для Linux с именем deps. По его оценке, это стилер учетных данных с опциональными функциями eBPF-руткита, который можно активировать при наличии повышенных привилегий. Иными словами, вредонос не только собирает данные, но и потенциально умеет прятаться внутри системы куда лучше типичного «трояна на коленке».
Набор целей у этого кода вполне отражает портрет современной машины разработчика. В отчете перечислены данные браузеров и Electron-приложений, Slack, Microsoft Teams, Discord, GitHub, npm, HashiCorp Vault, Docker и Podman, SSH-артефакты, VPN-материалы, история команд shell и другие локальные секреты. Это уже не история про абстрактную компрометацию одной рабочей станции. Если на ноутбуке разработчика лежат токены GitHub, доступы к registry, ключи для CI, контейнерные креды и куки из корпоративных веб-сервисов, то одна такая инфекция быстро превращается в цепочку вторжений: кодовая база, артефакты сборки, облачная инфраструктура, внутренняя коммуникация.
Отдельно настораживает использование eBPF. В нормальном мире эта технология нужна для наблюдаемости, сетевых инструментов и низкоуровневой телеметрии. В плохом — она дает вредоносному коду шанс работать ближе к ядру, скрывать процессы и усложнять расследование. Именно поэтому рекомендация исследователей звучит жестко: если на системе нашли признаки заражения, одной чисткой пакетов и удалением подозрительных файлов лучше не ограничиваться. Пользователям советуют менять все учетные данные и всерьез рассматривать переустановку Arch Linux с нуля, потому что руткит может пережить поверхностное «лечение».
Параллельно свое исследование опубликовала компания Sonatype, которая занимается безопасностью цепочек поставки ПО. Ее аналитики описали похожую кампанию, но с другим механизмом доставки. По их данным, атакующий перехватил как минимум 20 осиротевших пакетов в AUR и модифицировал PKGBUILD так, чтобы после установки запускался post-install-скрипт, вызывающий npm и подтягивающий тот же atomic-lockfile. То есть у кампании уже видны как минимум два вектора: подмена мейнтейнера и захват orphaned-пакетов. Это важная деталь для всех, кто привык успокаивать себя мыслью «мы же ставим только знакомые пакеты». В подобных экосистемах компрометируют не бренд, а доверительную модель вокруг него.
Для Arch эта история болезненна именно потому, что AUR — часть повседневной практики, а не экзотический уголок для энтузиастов. Формально пользователи и так знают, что AUR не проходит такой же контроль, как официальные репозитории. Практически же многие ставят пакеты через помощники, редко перечитывают PKGBUILD перед обновлением и почти никогда не ждут, что innocuous-looking post-install внезапно полезет за npm-зависимостью с вредоносной нагрузкой. Атака хорошо бьет по типичной developer ergonomics: чем удобнее и автоматизированнее установка, тем меньше шансов, что кто-то заметит подозрительный шаг до запуска.
Под ударом здесь не только индивидуальные разработчики, но и команды. Если в компании разрешены Arch или Arch-based дистрибутивы на рабочих машинах, этот инцидент почти автоматически становится вопросом для security и IT operations. Нужны хотя бы три базовые реакции: инвентаризация того, какие AUR-пакеты реально используются; проверка, не попадали ли в парк затронутые сборки; ревизия того, какие секреты вообще допускается хранить на локальной машине. И да, старый спор «можно ли разработчику жить с постоянными long-lived токенами в браузере и shell history» снова получил неприятно наглядный аргумент против.
Сейчас мейнтейнеры AUR ищут и удаляют вредоносные коммиты, а связанные аккаунты блокируют. Джонатан Гротелюшен, сопровождающий пакетов Arch Linux, попросил сообщество сообщать о любых подозрительных пакетах. Исследователи также советуют проверить список затронутых пакетов и индикаторы компрометации, а Майкл Таггарт отдельно указал на скрипт для поиска atomic-lockfile в системе. Сам по себе этот эпизод вряд ли останется единичным: supply-chain-атаки все чаще целятся не в пользователей массового софта, а в среды разработки, где один удачный компромисс открывает путь к репозиториям, пайплайнам и внутренним сервисам. Чем сильнее разработка завязана на community-репозитории и локальные секреты, тем дороже становится привычка «сначала ставим, потом думаем». Подробности инцидента собраны в материале .