Node.js вещает: Google инженеры нашли уязвимость в NPM скриптах
Node.js разработчики, запускайте команду `npm install` на свой страх и риск и помните, что само-распространяющийся червь свободно гуляет по экосистеме.
Никогда нельзя полагать, что скачанный из интернета файл является безопасным. Это справедливо и для NPM, стандартного менеджера пакетов Node.js. Уязвимость при установке скриптов позволяет атакующему создать само-распространяющегося червя, который может проходить сквозь NPM пакеты.
«Это возможно благодаря тому, что один NPM пакет с легкостью может пропускать через себя большую часть экосистемы», пишет разработчик из Google Сэм Сакони в своей статье «разоблачение NPM гидры».
Так же как в других менеджерах пакетов, NPM поддерживает «lifecycle» скрипты, которые могут выполняться посторонними командами в системе на правах текущего пользователя. Хотя эти скрипты часто полезны и используются для очистки файлов после процесса установки, компилирование бинарных модулей и автоматического создания файлов конфигураций, но в то же время они могут опасны, поскольку при выполнении различных команд могут вносить любые изменения в систему.
«Возможно NPM пакеты написанные со злым умыслом, при установке выполняют скрипты которые внедряются в другие пакеты, которые в свою очередь публикуются в реестре, и другие пакеты созданные пользователем», пишут в статье в официальном NPM блоге. Однако, компания сообщает, что выгода от применения этих скриптов перевешивает риски потенциальной угрозы.
Пост преуменьшает риск и обращает внимание на пакеты, которые «чисты с самого начала», но не все из них «на все сто» в этом уверены. Статья Сакони, кроме нескольких обходных путей, не дает понять, как быть уверенным в том что пакеты, которые устанавливают пользователи не окажутся не тем что ожидалось.
«NPM не может гарантировать что их реестр пакетов безопасен», отмечается в статье.
Червь просачивается через зависимости пакетов
Червь пользуется тремя возможностями в NPM: семантической версионностью (semver), публикацией в централизованном реестре и привилегиями пользователя, который автоматически логиниться. Потому что пользователь остается авторизированным, пока не разлогинился вручную. Любой, кто вошел и запустил установку, позволяет другим модулям исполнять самые разнообразные команды. Пока нет привязки к конкретным версиям, пакеты могут быть обновлены до новых версий, и каждый из них может выполнять код. И наконец, они могут отправлять пакеты на сервер центрального реестра, откуда их себе смогут устанавливать и другие.
Атака червя полагается на социальную инженерию для начального инфицирования и вышеупомянутые «улучшения» могут свободно передвигаться по экосистеме.
Сперва злоумышленник обманным путем заставляет владельца NPM пакета установить зараженный пакет на своей системе. Это может быть фишинг или любая другая подобная атака. Однажды установленный, он создает «троянскую» версию пакета владельца NPM модуля и ставит перехватчик (hook) для запуска червя везде где он установлен. Модифицированный модуль, опубликованный на аккаунте владельца, становится отправной точкой для инфицирования всех его пакетов, запуская троянского модуля в качестве зависимости. Червь создает новые версии модулей в аккаунте с комментарием «bugfix», и теперь, при его установке — само-распространяющийся код может быть выполнен.
Для примера. PhoneGap имеет 463 промежуточных зависимости. И 276 индивидуальных NPM аккаунта могут обновлять версии их пакетов. Теперь достаточно всего одного человека из этих 276, чтобы червь мог продолжить заражать всех кто установил себе пакет от проекта PhoneGap, говорит Сакони.
NPM открещивается от рисков
Пока «дыру» не закрыли, заметка об уязвимости от «United States Computer Emergency Readiness Team» освещает несколько решений для обхода опасности. Они используют опцию »-ignore-scripts», когда устанавливают новые зависимости, замыкают версии с помощью `npm-shrinkwrap`, и поощряют пользователей, чьи модули сами постоянно разлогиниваются из NPM.
Организации использующие NPM в своих средах должны запускать локальное зеркало NPM реестра и запрещать отдельным пользователям устанавливать зависимости напрямую с главного реестра. Они должны регулярно проверять локальный реестр и удостоверяться, что вредоносные файлы не попали в список зависимостей.
Сакони порекомендовал поставить время истечения работы токенов и принудительного выхода пользователей из NPM после истечения определенного срока. В блоге, компания не описывала эти рекомендации, но озвучила другие решения для минимизации рисков.
Одна из идей — это усложнить публикацию модулей, если пользователь не осведомлен об опасности, это может быть двух-фактурная аутентификация. Еще можно работать с компаниями, обеспечивающими защиту предлагая последним проверить модули, но пока это невозможно. В данный момент компания мониторит часто обновляющиеся пакеты, поскольку червь может быть выявлен по очень частым выпускам новых версий, но они больше надеяться на пользователей, которые будут сами оповещать об подозрительных пакетах.
«Несомненно, если много пользователей попытаются согласовано массово публиковать вредоносные пакеты,- то они будут доступны в реестре NPM», заявляют в блоге.
Доверяй, но проверяй
Это будут трудные несколько дней для NPM. Выявление вредоносных публикуемых пакетов является их «ахиллесовой пятой». В текущих дебатах на тему регулирования менеджером удаленных из реестра пакетов. Удаление разработчиком пакета из NPM на прошлой неделе, тем самым сломав много зависящих от него проектов. Также довольно просто зарегистрировать свой код под именем удаленного модуля. Любой кто присвоил чужое имя может установить код любому пользователю, который зависит от оригинала.
В Reddit и GitHub в последние несколько дней много дискутируют по поводу доверия к разработчикам, сопровождении созданных ими пакетов и не начнут ли они создавать вредоносный код. В глобальной экосистеме это опасное для допущение, потому что если один такой разработчик захочет сломать много кода — ему придется противостоять целому сообществу. Однако должны быть способы безопасно устанавливать модули, это может быть цифровая подпись или другие методы проверки кода на безопасность и корректность. А пока остается только ощущать тревогу каждый раз, когда запускаешь команду `npm install`.
Оригинал статьи: www.infoworld.com/article/3048526/security/nodejs-alert-google-engineer-finds-flaw-in-npm-scripts.html
