Уязвимость в механизме Trusted Publishing npm могла позволить злоумышленникам захватывать легитимные программные пакеты, перехватывая имена заброшенных репозиториев GitHub, что потенциально подвергло миллионы загрузок пакетов атакам на цепочку поставок.
Исследователи из Bloom Security выявили более 1500 потенциально уязвимых пакетов npm, включая сканеры безопасности, инструменты аутентификации и криптографические пакеты.
Уязвимость, получившая название SlugFest, возникла из-за того, что npm полагалась на удобочитаемые имена репозиториев GitHub для проверки доверенных издателей, а не на постоянные числовые идентификаторы репозиториев. Это могло позволить злоумышленнику унаследовать доверие к публикации пакета, заявив права на имя репозитория, от которого отказался первоначальный владелец.
Проблема уже устранена, сообщил CSO исследователь Bloom Security Голан Майерс. «Команда npm подтвердила, что исправление было выпущено 2 октября, введя 48-часовой срок действия для невалидированных конфигураций Trusted Publishing», — сказал он.
Майерс заявил, что Bloom не наблюдал активной эксплуатации уязвимости в реальных условиях, но подтвердил, что ошибка была успешно использована для публикации новой версии существующего пакета npm в контролируемых ими тестовых условиях. Исправление устраняет риски, связанные с невалидированными конфигурациями, хотя сопровождающим по-прежнему необходимо проверять существующие отношения доверия, написала Bloom в блоге, которым поделились с CSO до его публикации во вторник.
Перехваченное имя репозитория позволило публиковать пакеты
Trusted Publishing от npm позволяет сопровождающим пакетов публиковать релизы через автоматизированные рабочие процессы с использованием OpenID Connect (OIDC), избегая долгосрочных учетных данных для публикации. Однако Bloom обнаружил, что конфигурация доверия npm полагалась на имя владельца/репозитория GitHub, а не на его неизменяемый идентификатор репозитория.
Когда репозиторий переименовывается, передается или удаляется, его прежнее имя может стать доступным для получения другим пользователем. Злоумышленник мог создать репозиторий по этому адресу и настроить рабочий процесс GitHub Actions с ожидаемым именем файла. Поскольку npm проверяла имя репозитория и имя файла рабочего процесса, не проверяя постоянный идентификатор репозитория, злоумышленник потенциально мог получить действительный идентификатор публикации для пакета, которым он не владел.
Исследователи продемонстрировали атаку на пакет, контролируемый исследователями, опубликовав новую версию из репозитория GitHub, принадлежащего другой организации. Атака не требовала компрометации учетной записи GitHub или npm законного сопровождающего или кражи их учетных данных.
Их сканирование реестра выявило более 1500 уязвимых пакетов с более чем 10 миллионами совокупных загрузок и более чем одним миллионом загрузок в месяц. Один пакет accounted for over 200,000 monthly downloads, according to Bloom.
AI-агенты усиливают риск для цепочки поставок
Bloom утверждает, что AI-агенты для написания кода могут ускорить распространение вредоносных зависимостей, поскольку они все чаще выбирают и устанавливают программные пакеты с минимальным вмешательством человека.
В десятках организаций исследователи измерили примерно 70 пакетов, установленных агентами на конечную точку каждый месяц, с ростом до примерно 350 на машинах разработчиков. Эти цифры охватывают прямые установки и не включают транзитивные зависимости.
Вредоносный релиз мог выполнить управляемый злоумышленником код через хук установки при установке скомпрометированного пакета разработчиками или системами CI. AI-агенты могли ввести такую зависимость без явного выбора ее разработчиком. «Захваченному пакету больше не нужно искать разработчика», — сказал Майерс. «Ему нужно только быть пакетом, который выберет агент».
Помимо того, что GitHub устранил проблему, сделав невалидные конфигурации Trusted Publishing истекающими через 48 часов, npm также усилила свои меры безопасности, отклоняя токены trusted-publishing, выданные через события issue_comment в GitHub Actions, наряду с существующим ограничением на события pull_request_target.
Кроме того, Bloom рекомендовал сопровождающим проводить аудит своих конфигураций Trusted Publishing, проверять, что каждое доверенное имя репозитория по-прежнему разрешается в репозиторий под их контролем, и при необходимости удалять и повторно создавать привязки. Исследователи также посоветовали командам безопасности проводить аудит зависимостей программного обеспечения и инструментов, используемых в их средах, и применять меры контроля над тем, что разработчикам и AI-агентам разрешено устанавливать.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Shweta Sharma
