В экосистеме Node.js злоумышленники начали новую серию атак на цепочку поставок. Они скомпрометировали широко используемые библиотеки кэширования cacheable и keyv. Оба пакета входят в список зависимостей огромного количества проектов. Особенно опасна ситуация с keyv: она служит транзитивной зависимостью для многих популярных инструментов, поэтому разработчики могли установить её автоматически, даже не подозревая об этом. Фактически, любой проект, в котором используется кэширование на базе keyv или её производных, оказывается в зоне риска. Речь идёт о JavaScript-экосистеме, которая лежит в основе множества веб-сервисов и бизнес-приложений. Поэтому уязвимость каналов распространения кода напрямую затрагивает компании любого размера. В зону риска попадают и небольшие стартапы, и крупные корпорации.
Описание
Компания JFrog Security Research, специализирующаяся на анализе угроз, обнаружила новую модификацию известного вредоносного ПО Shai-Hulud. Первым признаком компрометации стало заражение пакетов cacheable и keyv. Позже выяснилось, что список пострадавших гораздо шире: в него попали десятки пакетов из экосистем ServiceTitan, OneReach, Ornikar, Arv Bedrock и других организаций. Среди затронутых версий - обновления вспомогательных библиотек для тестирования, стилизации, работы с пользовательским интерфейсом и управления конфигурацией. Исследователи уже подтвердили сотни заражённых версий, а итоговый перечень продолжает пополняться. Примечательно, что многие из атакованных пакетов не имеют прямого отношения к кэшированию. Злоумышленники внедряли код в самые разные утилиты, лишь бы они были востребованы у разработчиков. Это говорит о широкомасштабности кампании и её нацеленности на максимальное распространение.
По данным JFrog Security Research, вредоносный код попадает в проект через автоматически выполняемые сценарии при установке пакета. Современные менеджеры пакетов, включая npm, поддерживают так называемые скрипты жизненного цикла. Они могут запускаться до или после установки. Обычно такие сценарии применяются для полезных задач - например, для компиляции нативного кода или загрузки дополнительных ресурсов. Однако злоумышленники воспользовались этой возможностью, чтобы незаметно выполнить свою полезную нагрузку. Для разработчика процесс установки выглядит стандартным, но вместе с библиотекой на компьютер попадает чужой код. Этот метод известен как атака на цепочку поставок. Легитимный инструмент превращается в вектор заражения, и доверие пользователя становится ключевым фактором распространения вредоносного ПО.
Shai-Hulud известен специалистам уже несколько лет. Предыдущие атаки с его использованием были связаны с заражением пакетов, которые маскировались под полезные утилиты. В новой версии авторы применили другой подход. Они подделывают обновления уже существующих, популярных и заслуживающих доверия библиотек. Это повышает вероятность того, что обновление примет не только начинающий разработчик, но и опытная команда. Более того, вредоносный код подготовлен так, чтобы избегать простых методов обнаружения. Он не проявляет себя в тестовых средах и начинает действовать только после того, как оказывается в реальной производственной инфраструктуре. В некоторых случаях заражение происходит не сразу, а через определённое время. Это серьёзно затрудняет выявление источника проблемы.
Особую тревогу вызывает тот факт, что keyv является базовым компонентом для других библиотек кэширования. Если разработчик установил один из таких инструментов, транзитивная зависимость автоматически установила заражённую версию. Проверить состав всех вложенных зависимостей вручную практически невозможно. Поэтому любая команда, использующая Node.js и npm в своих проектах, должна проверить окружение. Даже если сами разработчики не загружали keyv напрямую, она могла появиться в проекте вместе с другими популярными библиотеками. Такая схема распространения делает угрозу скрытой и трудноуловимой. Между тем, по данным опросов, лишь небольшой процент компаний регулярно проводит аудит зависимостей своего кода. Остальные полагаются на репутацию пакетов, что и приводит к подобным инцидентам.
Если заражённая версия была установлена, необходимо считать всю среду разработки скомпрометированной. Вредоносный код способен собирать переменные окружения, включая ключи доступа к облачным сервисам, базам данных и сторонним API. Он может изменять файлы проекта, внедрять дополнительный код и открывать злоумышленникам удалённый доступ к системе. Результатом может стать утечка исходного кода, учётных данных и коммерческой информации. Особенно опасна ситуация для компаний, использующих непрерывную интеграцию. Вредоносный код, попавший в сборочный конвейер, может распространиться на артефакты и затрагивать клиентов. При таком сценарии последствия выходят далеко за пределы одной команды разработчиков. Они способны нанести серьёзный репутационный и финансовый ущерб.
Пользователям npm версии 12 и новее не нужно бояться заражения этим способом. Менеджер пакетов по умолчанию отключает автоматическое выполнение скриптов установки. Однако это не означает, что можно игнорировать проблему. Во-первых, многие компании продолжают использовать более старые версии инструментов. Во-вторых, при ручном выполнении команд или использовании альтернативных менеджеров пакетов защита может быть слабее. В-третьих, вредоносный код может активироваться не только при установке, но и при обычном использовании заражённой библиотеки. Всем, кто подозревает у себя заражение, следует переустановить окружение, обновить зависимости и перевыпустить ключи. Дополнительно стоит включить двухфакторную аутентификацию для учётных записей с правом публикации пакетов. Также полезно настроить уведомления о любых изменениях в зависимостях.
Центр безопасности JFrog опубликовал предварительное уведомление и пообещал предоставить полный технический анализ, перечень затронутых версий и инструкции по восстановлению. Пока расследование продолжается, организациям рекомендуется временно исключить использование пакетов cacheable и keyv, а также связанных с ними библиотек в процессах сборки. Перед возвратом к работе нужно дождаться официальных рекомендаций и убедиться, что используемые версии не входят в список скомпрометированных. Кроме того, стоит провести внутреннюю проверку всех проектов на предмет наличия указанных пакетов. Это особенно важно для крупных организаций, где перечень зависимостей может исчисляться тысячами. Ситуация в очередной раз демонстрирует, что безопасность цепочки поставок требует постоянного внимания и встроенных механизмов контроля.
Индикаторы компрометации
