Совершению атаки способствуют несколько факторов:

• Использование семантического версионирования (SemVer), по умолчанию не привязывающего приложение к конкретным версиям модулей, что позволяет инициировать установку обновления модуля через выпуск его новой версии;
• Применение постоянного кэширования параметров аутентификации в NPM - после входа с машины разработчика можно выполнять любые действия от его имени, пока разработчик вручную не отсоединится от репозитория. Подобный подход мешает разработчику контролировать свою активность в репозитории, что может быть использовано для скрытой публикации обновлений с его компьютера.
• Использование централизованного реестра, который используется большинством систем на базе платформы Node.js. Любой опубликованный модуль сразу становится доступен для всех, без прохождения какой-либо проверки;
• Возможность определения shell-скриптов, запускаемых на различных этапах установки модуля и позволяющих выполнить любые действия на системе пользователя.

Сценарий атаки сводится к подготовке модуля, который через автоматически запускаемый установочный скрипт создаёт и публикует новый вредоносный модуль, а также добавляет этот вредоносный модуль в список зависимостей к модулям, которые разрабатываются на текущем компьютере. Внедрение подобного модуля на незащищённую систему разработчика одного из популярных модулей NPM приведёт к цепной реакции - в репозиторий будет отправлена новая версия популярного модуля, привязанная через зависимости к вредоносному модулю.

Публикация с уровнем "bugfix" приведёт к установке обновления большинством пользователей. Далее цепочка повторяется; при установке модуля будет запущен вредоносный скрипт, который изменит модули, разрабатываемые текущим пользователем и опубликует их. Все операции по публикации будут выполнены без участия разработчика, так как сеанс подключения к репозиторию NPM прокэширован.

Отличная возможность для внедрения вредоносных модулей появилась после инцидента с модулем kik, автор которого удалил из репозитория свои 273 модуля, связанные зависимостями со многими проектами. Злоумышленник мог разместить в репозитории новые модули с теми же именами и они были бы установлены на системах, в которых удалённые модули были упомянуты в зависимостях. В результате эксперимента исследователю безопасности удалось перехватить контроль над 238 из 273 удалённых модулей.

Для первичного внедрения вредоносного кода также могут быть использованы методы социальной инженерии, например, атакующий может отправить разработчику сообщение о конфликте или проблемах с определённым модулем, для проверки проблемы разработчик установит данный модуль и тем самым запустит цепочку распространения червя.

Для блокирования подобных атак разработчикам модулей рекомендуется не использовать постоянное подключение к NPM, установить "npm shrinkwrap" для привязки зависимостей и использовать при установке опцию "npminstall ... --ignore-scripts" для игнорирования установочных скриптов.

В качестве рекомендуемых мер усиления безопасности инфраструктуры NPM, которые помогут избежать проведения подобных атак, предлагается:

• Ввести ограниченное время жизни параметров входа;
• Применять двухфакторную аутентификацию при публикации модулей (например, ввести обязательное подтверждение операции по SMS);
• Производить отключение от репозитория перед выполнением операции установки модулей;
• Ввести обязательное ручное подтверждение выполнения скриптов, вызываемых перед установкой или удалением модуля;
• Включить по умолчанию shrinkwrap для организации привязки проекта к конкретной версии модуля;
• Вынести процесс обновления версий в отдельно подтверждаемую операцию "npm upgrade";
• Внедрить систему проверки и рецензирования публикуемых модулей.