Инцидент (https://www.opennet.ru/opennews/art.shtml?num=44104) с нарушением работы многих известных проектов после удаления модуля из NPM-репозитория, привёл к обсуждению незащищённости NPM от атак, инициированных со стороны разработчиков модулей. В том числе раскрыты (http://blog.npmjs.org/post/141702881055/package-install-scri...) данные об незащищённости (https://www.kb.cert.org/vuls/id/319816) инфраструктуры NPM к атаке по
внедрению (https://medium.com/@nm_johnson/npm-package-hijacking-fr...) в репозиторий самораспространяющихся вредоносных модулей.Совершению атаки способствуют несколько факторов:
- Использование семантического версионирования (https://docs.npmjs.com/getting-started/semantic-versioning) (SemVer), по умолчанию не привязывающего приложение к конкретным версиям модулей, что позволяет инициировать установку обновления модуля через выпуск его новой версии;
- Применение постоянного кэширования параметров аутентификации в NPM - после совершения входа с машины разработчика можно выполнять любые действия от его имени, пока разработчик вручную не отсоединиться от репозитория. Подобный подход мешает разработчику контролировать свою активность в репозитории, что может быть использовано для скрытой публикации обновлений с его компьютера.
- Использование централизованного реестра, который используется большинством систем на базе платформы Node.js. Любой опубликованный модуль сразу становится доступен для всех, без прохождения какой-либо проверки;
- Возможность определения shell-скриптов (https://docs.npmjs.com/misc/scripts), запускаемых на различных этапах установки модуля и позволяющих выполнить любые действия на системе пользователя.
Сценарий атаки сводится к подготовке модуля, который через автоматически запускаемый установочный скрипт создаёт и публикует новый вредоносный модуль, а также добавляет этот вредоносный модуль в список зависимостей к модулям, которые разрабатываются на текущем компьютере. Внедрение подобного модуля на незащищённую систему разработчика одного из популярных модулей NPM приведёт к цепной реакции - в репозиторий будет отправлена новая версия популярного модуля, привязанная через зависимости к вредоносному модулю.
Публикация с уровнем "bugfix" приведёт к установке обновления большинством пользователей. Далее, цепочка повторяется, при установке модуля будет запущен вредоносный скрипт, который изменит модули, разрабатываемые текущим пользователем и опубликует их. Все операции по побликации будут выполнены без участия разработчика, так как сеанс подключения к репозиторию NPM прокэширован.
Отличная возможность для внедрения вредоносных модулей появилась после инцидента с модулем kik, автор которого удалил из репозитория свои 273 модуля, связанные зависимостями со многими проектами. Злоумышленник мог разместить в репозитории новые модули с теми же именами и они были бы установлены на системах, в которых удалённые модули были упомянуты в зависимостях.
В результате эксперимента исследователю безопасности удалось (https://medium.com/@nm_johnson/npm-package-hijacking-fr...) перехватить контроль над 238 из 273 удалённых модулей.
Для первичного внедрения вредоносного кода также могут быть использованы методы социальной инженерии, например, атакующий может отправить разработчику сообщение о конфликте или проблемах с определённым модулем, для проверки проблемы разработчик установит данный модуль и тем самым запустит цепочку распространения червя.
Для блокирования подобных атак разработчикам модулей рекомендуется не использовать постоянное подключение к NPM, установить "npm shrinkwrap" для привязки зависимостей и использовать при установке опцию "npminstall ... --ignore-scripts" для игнорирования установочных скриптов.
В качестве рекомендуемых мер усиления безопасности инфраструктуры NPM, которые помогут избежать проведения подобных атак, предлагается:
- Ввести ограниченное время жизни параметров входа;
- Применять двухфакторную аутентификацию при публикации модулей (например, ввести обязательное подтверждение операции по SMS);
- Производить отключение от репозитория перед выполнением операции установки модулей;
- Ввести обязательное ручное подтверждение выполнения скриптов, вызываемых перед установкой или удалением модуля;
- Включить по умолчанию shrinkwrap (https://docs.npmjs.com/cli/shrinkwrap) для организации привязки проекта к конкретной версии модуля;
- Вынести процесс обновления версий в отдельно подтверждаемую операцию "npm upgrade";
- Внедрить систему проверки и рецензирования публикуемых модулей.
URL: https://medium.com/@nm_johnson/npm-package-hijacking-fr...
Новость: https://www.opennet.ru/opennews/art.shtml?num=44111
