The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Незащищённость NPM к атакам по внедрению вредоносных модулей-червей

26.03.2016 10:29

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

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

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

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

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

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

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

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

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

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


  1. Главная ссылка к новости (https://medium.com/@nm_johnson...)
  2. OpenNews: Инцидент с захватом прав на NPM-модуль привёл к сбою в работе проектов, использующих NPM
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/44111-npm
Ключевые слова: npm
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (43) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 11:25, 26/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    коммитим репо -> обновляемся -> проверяем что пришло
     
     
  • 2.21, rshadow (ok), 18:00, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • +8 +/
    Тут все проще. "Дистрибутив" жидко обкакался. И пытается все свалить на разработчиков.

    По факту же, в любом дистрибутиве все зависит от разработчиков. Просто есть свободные дистры, в которых все правильно сделано умными людьми. А есть коммерческие дистры, где правильно стараются делать из за клиентов и денег. А это ни то ни се.

     
     
  • 3.40, Аноним (-), 19:40, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Какой дистрибутив? Вернее дистрибутив чего?
     

  • 1.4, Аноним (-), 12:23, 26/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Все правильно, проекту пора "взрослеть".
     
     
  • 2.6, Аноним (-), 12:58, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • +27 +/
    Что уж там..., проекту пора "умирать".
     
     
  • 3.16, Аноним (-), 16:33, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • +5 +/
    нпму в текущем виде действительно надо умереть как можно скорее, иначе ничего нового не родится
     
  • 2.36, Аноним (-), 14:06, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На яваскрипте сложно писать большие проекты, поэтому вместо взрослоты - хипстота. И даже пример десятилетий успешной работы других пакетных манеджеров не помог.
     

  • 1.7, Аноним (-), 13:40, 26/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >Использование семантического версионирования по умолчанию не привязывающего приложение к конкретным версиям модулей

    Только JS макаки могли додуматься до такого.

     
     
  • 2.8, Аноним (-), 13:48, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    У них там CouchDB без привилегий, можно заливать все что угодно и любых размеров.
     
  • 2.9, конь (?), 13:49, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • +10 +/
    если бы не жил в пещере, знал бы что это, на данный момент, распространенная практика не только в js сообществе.
     
     
  • 3.10, Аноним (-), 14:23, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ну не знаю, у нас в Java мире везде надо версии указывать. Без них не работает.
     
     
  • 4.13, _ (??), 14:49, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • +10 +/
    мда.. в Java где всё идет через коммерческий mavencentral и где тебе с "непонятного" источника прилетают скомпилированные классы, - это не лучший пример для подражания в подобных ситуациях.

    cargo в Rust, более совершенен, да там semver, на все пакеты приходят в исходниках на машину, все пакеты хостятся на гитхабе(публичный ревью).

     
     
  • 5.20, mine (ok), 17:35, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > cargo в Rust, более совершенен, да там semver, на все пакеты приходят в исходниках на машину, все пакеты хостятся на гитхабе(публичный ревью).

    Чем это отличается от сабжа?

     
     
  • 6.22, _ (??), 19:27, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я сильно не знаком с NPM, хоть и пользовался им, но непонятна ситуация с владельцами NPM, которые могут на свое усмотрение, где-то у себя поменять привязку пакета "foo" с оригинального на платный(с трояном, от сп.служб и т.д) и это до загрузки не проверить.

    cargo индекс, виден всем (на гитхабе) и человек может понять перед загрузкой, кто, когда и где стоит за таким-то пакетом перед загрузкой его через cargo!

    Кроме-то в Rust(cargo) сейчас запрещены вайлдкарды версий(*) в зависимостях, т.е изначально версии перед публикацией фиксируется. Их можно изменить на определенный диапазон (e.g: "1.1.1=<1.1.4"), но так делают только авторы которые и писали сам пакет и его пакет-зависимость.

     
     
  • 7.30, Аноним (-), 01:59, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > cargo индекс, виден всем (на гитхабе) и человек может понять перед загрузкой, кто, когда и где стоит за таким-то пакетом перед загрузкой его через cargo!

    Чем это отличается от сабжа? (2)

    > в Rust(cargo) сейчас запрещены вайлдкарды версий(*) в зависимостях, т.е изначально версии перед публикацией фиксируется

    Запрещены - и ладно, в NPM подобных запретов нет, NPM лишь предоставляет инструмент/возможность, а то, как им пользоваться - на усмотрение конечного разработчика.

     
  • 7.37, Аноним (-), 14:07, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Я сильно не знаком с NPM, хоть и пользовался им,

    ...но мнение имею. Молодец, настоящий адепт cargo-культа. Садись, пять.

     
  • 7.45, anonimous (?), 12:15, 28/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Т.е. владельцам NPM ты не доверяешь, а владельцам Гитхаба -- всем сердцем и душой?
     
  • 7.47, anonimous (?), 12:31, 28/03/2016 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > но непонятна ситуация с владельцами NPM

    Как и с любым другим онлайн-сервисом. Хочешь надежности -- проверяй и держи на своих машинах.

    > cargo индекс, виден всем (на гитхабе) и человек может понять перед загрузкой, кто, когда и где стоит за таким-то пакетом перед загрузкой его через cargo!

    Как и в любом другом хранилище пакетов. Но см пункт 1 -- ты никогда не сможешь гарантировать, что чужой сервис вернет тебе правильную информацию.

    > Кроме-то в Rust(cargo) сейчас запрещены вайлдкарды версий(*) в зависимостях

    В любой системе зависимостей можно выбрать -- привязаться к последней версии или по * -- это исключительно выбор разработчика. Наркоманское ограничение в cargo, кстати, только говорит о его убогости -- да, да когда-нибудь кому-нибудь может понадобиться эта фича и придётся городить костыли с авто-генератором зависимостей для билд-скрипта.

     
  • 4.31, angra (ok), 03:10, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Любопытно, как при таком подходе решается ситуация конфликта версий. Вот некая программа требует десяток модулей конкретной версии, каждый из этих модулей тоже требует конкретных версий других модулей. И есть какой-нибудь очень часто используемый модуль, ну типа isarray или leftpad из предыдущей новости. И вот у тебя в программе есть пятьдесят модулей, каждый из которых привязан к разной версии некого isarray. Что происходит в таком случае? Вопрос хранения и загрузки с сервера решит какой-нибудь vcs, но что происходит в момент исполнения программы? В память загружается пятьдесят разных версий модуля?
     
     
  • 5.48, Очередной аноним (?), 08:48, 29/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю как в "голой" яве (раньше часто в саму jar-ку приложения сразу библиотеки нужных версий всовывали), а вот в Weblogic'е (наверное и в других серверах приложений тоже) есть старое банальное понятие "разделяемой библиотеки" (shared library). Такая библиотека имеет номер версии. А в приложениях (в дескрипторе развертывания), которые потом деплоятся на сервер приложений и используют эту библиотеку, ты указываешь номер требуемой версии, причем можешь указать "строго этот номер версии" или "начиная с этого номера и выше". На сервере приложений крутится несколько нужных версий одной и той же shared library. При деплое приложения сервер подсовывает нужную версию в зависимости от того что указано в дескрипторе развертывания этого приложения (ну или ошибку, если нет нужной версии)
     
  • 4.50, Клыкастый (ok), 14:54, 31/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    это одна из причин по которой жабасофт считается (и является) убогим говном.
     
  • 2.11, Аноним (-), 14:42, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Развитие QA, DevOps, и т.д. и переход из в JS-разработчики делают своё дело
     
  • 2.14, Crazy Alex (ok), 15:57, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    О да, прибивать гвоздями к минорной версии - лучше, конечно.
     
     
  • 3.24, Wladmis (ok), 21:52, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > О да, прибивать гвоздями к минорной версии - лучше, конечно.

    Зачем же бросаться в крайности? О ранжировании не слышали?

     
     
  • 4.29, Crazy Alex (ok), 00:23, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я просто этот Java мир видел вблизи - там обычно именно миноры гвоздями и прибивают, хотя Maven очень гибок в это плане.
     

  • 1.12, Аноним (-), 14:49, 26/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    О, ну неужели они всё-таки это заметили?
     
  • 1.15, Crazy Alex (ok), 15:58, 26/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Ну вот обязательно надо было собрать все мыслимые грабли? На чужом примере учиться - никак?
     
     
  • 2.39, Michael Shigorin (ok), 17:27, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Ну вот обязательно надо было собрать все мыслимые грабли?

    И ряд немыслимых типа https://www.youtube.com/watch?v=1TioQx2jVN0 ...

    > На чужом примере учиться - никак?

    Это удел мудрых.

     

  • 1.19, Аноним (-), 16:41, 26/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Кто то говорил, что на js меньше ошибок на кол-во кода.
    Как может быть меньше того, чего нету совсем?
     
     
  • 2.27, Аноним (-), 22:25, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Кто то говорил, что на js меньше ошибок на кол-во кода.
    > Как может быть меньше того, чего нету совсем?

    Выгнали с работы в кризис и отдали набивание иксымелей для жабы индусу-аутсорсеру? Ничо страшного! Ты всегда можешь стать дворником и зарабатывать примерно столько же, сколько тот индус, а валютную ипотеку вернёшь почкой.

     

  • 1.25, kleem_head (?), 21:57, 26/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    народ, хорош шлак изливать. все такие маркетологи, а кто код писать будет? ну хоть кто-то может вектор для исправления ситуации дать? а то пока все работали вопросов как-то ни кто не задавал, зато теперь реквиумы и оды у всех прут. противно. блин.
     
     
  • 2.28, Аноним (-), 23:03, 26/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    проще некуда: запилить новый нпм с ссл, гитом, подписями и без шавок у руля.
     
     
  • 3.32, Аноним (-), 03:33, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > ссл

    При чем тут SSL?

    Кто будет проверять соответсвие подписи и личности автора?

     
     
  • 4.34, Наме (?), 10:04, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Храните свои подписи в блокчейне и будет вам счастье.
     
     
  • 5.38, Аноним (-), 14:23, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Счастья будет много. В биткоине более 30Гб уже.
     
  • 4.46, agent_007 (ok), 12:23, 28/03/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Кто будет проверять соответсвие подписи и личности автора?

    Поинтересуйтесь, как этот вопрос решается в различных дистрибутивах Linux. Например, в Debian.

     
  • 3.44, Аноним (-), 10:38, 28/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > проще некуда: запилить новый нпм с ссл, гитом, подписями и без шавок у руля.

    ... на питоне...

     
     
  • 4.49, Аноним (-), 09:41, 30/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > ... на питоне...

    Который не тормозит еще больше чем js.

     

  • 1.26, Вася (??), 22:21, 26/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    пора на http://jspm.io/ сваливать
     
     
  • 2.43, Аноним (-), 08:16, 28/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >  npm install systemjs

    а там копирастический червь скачается?

     

  • 1.35, BlackRaven86 (ok), 13:11, 27/03/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Включить по умолчанию shrinkwrap для организации привязки проекта к конкретной версии модуля

    Как они умудрились до сих пор это не включить? Я не представляю, как можно вообще без shrinkwrap можно чего-то разрабатывать.

     
     
  • 2.41, Anonimous (?), 22:01, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Легко и просто: захерачиваешь node_modules в свн/гит и никаких тебе ужасов с npm install. Раз в несколько месяцев обновляешься, ну или когда нужно добавить новый модуль. И волосы твои мягкие и шелковистые.
     
     
  • 3.42, Anonimous (?), 22:05, 27/03/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    + независишь от интернета/авторов, выпиливающих свои модули/политиков, блокирующих гитхаб
    + нормальные, повторяемые сборки

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру