The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Незащищённость NPM к атакам по внедрению вредоносных модулей..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от opennews (??) on 26-Мрт-16, 11:25 
Инцидент (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

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Аноним (??) on 26-Мрт-16, 11:25 
коммитим репо -> обновляемся -> проверяем что пришло
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

21. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +8 +/
Сообщение от rshadow (ok) on 26-Мрт-16, 18:00 
Тут все проще. "Дистрибутив" жидко обкакался. И пытается все свалить на разработчиков.

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

40. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Аноним (??) on 27-Мрт-16, 19:40 
Какой дистрибутив? Вернее дистрибутив чего?
Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

4. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  –3 +/
Сообщение от Аноним (??) on 26-Мрт-16, 12:23 
Все правильно, проекту пора "взрослеть".
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +27 +/
Сообщение от Аноним (??) on 26-Мрт-16, 12:58 
Что уж там..., проекту пора "умирать".
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

16. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +5 +/
Сообщение от Аноним (??) on 26-Мрт-16, 16:33 
нпму в текущем виде действительно надо умереть как можно скорее, иначе ничего нового не родится
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

36. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +1 +/
Сообщение от Аноним (??) on 27-Мрт-16, 14:06 
На яваскрипте сложно писать большие проекты, поэтому вместо взрослоты - хипстота. И даже пример десятилетий успешной работы других пакетных манеджеров не помог.
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

7. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +1 +/
Сообщение от Аноним (??) on 26-Мрт-16, 13:40 
>Использование семантического версионирования по умолчанию не привязывающего приложение к конкретным версиям модулей

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Аноним (??) on 26-Мрт-16, 13:48 
У них там CouchDB без привилегий, можно заливать все что угодно и любых размеров.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +10 +/
Сообщение от конь on 26-Мрт-16, 13:49 
если бы не жил в пещере, знал бы что это, на данный момент, распространенная практика не только в js сообществе.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

10. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  –1 +/
Сообщение от Аноним (??) on 26-Мрт-16, 14:23 
Ну не знаю, у нас в Java мире везде надо версии указывать. Без них не работает.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

13. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +10 +/
Сообщение от _ (??) on 26-Мрт-16, 14:49 
мда.. в Java где всё идет через коммерческий mavencentral и где тебе с "непонятного" источника прилетают скомпилированные классы, - это не лучший пример для подражания в подобных ситуациях.

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

20. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от mine (ok) on 26-Мрт-16, 17:35 
> cargo в Rust, более совершенен, да там semver, на все пакеты приходят в исходниках на машину, все пакеты хостятся на гитхабе(публичный ревью).

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

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

22. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +3 +/
Сообщение от _ (??) on 26-Мрт-16, 19:27 
Я сильно не знаком с NPM, хоть и пользовался им, но непонятна ситуация с владельцами NPM, которые могут на свое усмотрение, где-то у себя поменять привязку пакета "foo" с оригинального на платный(с трояном, от сп.служб и т.д) и это до загрузки не проверить.

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

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

30. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Аноним (??) on 27-Мрт-16, 01:59 
> cargo индекс, виден всем (на гитхабе) и человек может понять перед загрузкой, кто, когда и где стоит за таким-то пакетом перед загрузкой его через cargo!

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

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

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

37. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  –1 +/
Сообщение от Аноним (??) on 27-Мрт-16, 14:07 
> Я сильно не знаком с NPM, хоть и пользовался им,

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

45. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от anonimous on 28-Мрт-16, 12:15 
Т.е. владельцам NPM ты не доверяешь, а владельцам Гитхаба -- всем сердцем и душой?
Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

47. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +3 +/
Сообщение от anonimous on 28-Мрт-16, 12:31 
> но непонятна ситуация с владельцами NPM

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

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

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

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

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

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

31. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от angra (ok) on 27-Мрт-16, 03:10 
Любопытно, как при таком подходе решается ситуация конфликта версий. Вот некая программа требует десяток модулей конкретной версии, каждый из этих модулей тоже требует конкретных версий других модулей. И есть какой-нибудь очень часто используемый модуль, ну типа isarray или leftpad из предыдущей новости. И вот у тебя в программе есть пятьдесят модулей, каждый из которых привязан к разной версии некого isarray. Что происходит в таком случае? Вопрос хранения и загрузки с сервера решит какой-нибудь vcs, но что происходит в момент исполнения программы? В память загружается пятьдесят разных версий модуля?
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

48. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Очередной аноним on 29-Мрт-16, 08:48 
Не знаю как в "голой" яве (раньше часто в саму jar-ку приложения сразу библиотеки нужных версий всовывали), а вот в Weblogic'е (наверное и в других серверах приложений тоже) есть старое банальное понятие "разделяемой библиотеки" (shared library). Такая библиотека имеет номер версии. А в приложениях (в дескрипторе развертывания), которые потом деплоятся на сервер приложений и используют эту библиотеку, ты указываешь номер требуемой версии, причем можешь указать "строго этот номер версии" или "начиная с этого номера и выше". На сервере приложений крутится несколько нужных версий одной и той же shared library. При деплое приложения сервер подсовывает нужную версию в зависимости от того что указано в дескрипторе развертывания этого приложения (ну или ошибку, если нет нужной версии)
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

50. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Клыкастый (ok) on 31-Мрт-16, 14:54 
это одна из причин по которой жабасофт считается (и является) убогим говном.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

11. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  –3 +/
Сообщение от Аноним (??) on 26-Мрт-16, 14:42 
Развитие QA, DevOps, и т.д. и переход из в JS-разработчики делают своё дело
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

14. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  –1 +/
Сообщение от Crazy Alex (ok) on 26-Мрт-16, 15:57 
О да, прибивать гвоздями к минорной версии - лучше, конечно.
Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

24. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +1 +/
Сообщение от Wladmis (ok) on 26-Мрт-16, 21:52 
> О да, прибивать гвоздями к минорной версии - лучше, конечно.

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

29. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +1 +/
Сообщение от Crazy Alex (ok) on 27-Мрт-16, 00:23 
Я просто этот Java мир видел вблизи - там обычно именно миноры гвоздями и прибивают, хотя Maven очень гибок в это плане.
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

12. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Аноним (??) on 26-Мрт-16, 14:49 
О, ну неужели они всё-таки это заметили?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +6 +/
Сообщение от Crazy Alex (ok) on 26-Мрт-16, 15:58 
Ну вот обязательно надо было собрать все мыслимые грабли? На чужом примере учиться - никак?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

39. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +2 +/
Сообщение от Michael Shigorin email(ok) on 27-Мрт-16, 17:27 
> Ну вот обязательно надо было собрать все мыслимые грабли?

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

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

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

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

19. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Аноним (??) on 26-Мрт-16, 16:41 
Кто то говорил, что на js меньше ошибок на кол-во кода.
Как может быть меньше того, чего нету совсем?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  –1 +/
Сообщение от Аноним (??) on 26-Мрт-16, 22:25 
> Кто то говорил, что на js меньше ошибок на кол-во кода.
> Как может быть меньше того, чего нету совсем?

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

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

25. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +2 +/
Сообщение от kleem_head on 26-Мрт-16, 21:57 
народ, хорош шлак изливать. все такие маркетологи, а кто код писать будет? ну хоть кто-то может вектор для исправления ситуации дать? а то пока все работали вопросов как-то ни кто не задавал, зато теперь реквиумы и оды у всех прут. противно. блин.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

28. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Аноним (??) on 26-Мрт-16, 23:03 
проще некуда: запилить новый нпм с ссл, гитом, подписями и без шавок у руля.
Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

32. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  –1 +/
Сообщение от Аноним (??) on 27-Мрт-16, 03:33 
> ссл

При чем тут SSL?

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

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

34. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Наме on 27-Мрт-16, 10:04 
Храните свои подписи в блокчейне и будет вам счастье.
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

38. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +1 +/
Сообщение от Аноним (??) on 27-Мрт-16, 14:23 
Счастья будет много. В биткоине более 30Гб уже.
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

46. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +2 +/
Сообщение от agent_007 (ok) on 28-Мрт-16, 12:23 
> Кто будет проверять соответсвие подписи и личности автора?

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

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

44. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Аноним (??) on 28-Мрт-16, 10:38 
> проще некуда: запилить новый нпм с ссл, гитом, подписями и без шавок у руля.

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

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

49. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Аноним (??) on 30-Мрт-16, 09:41 
> ... на питоне...

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

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

26. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +1 +/
Сообщение от Вася (??) on 26-Мрт-16, 22:21 
пора на http://jspm.io/ сваливать
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

43. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Аноним (??) on 28-Мрт-16, 08:16 
>  npm install systemjs

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

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

35. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от BlackRaven86 email(ok) on 27-Мрт-16, 13:11 
> Включить по умолчанию shrinkwrap для организации привязки проекта к конкретной версии модуля

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

41. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +/
Сообщение от Anonimous on 27-Мрт-16, 22:01 
Легко и просто: захерачиваешь node_modules в свн/гит и никаких тебе ужасов с npm install. Раз в несколько месяцев обновляешься, ну или когда нужно добавить новый модуль. И волосы твои мягкие и шелковистые.
Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

42. "Незащищённость NPM к атакам по внедрению вредоносных модулей..."  +2 +/
Сообщение от Anonimous on 27-Мрт-16, 22:05 
+ независишь от интернета/авторов, выпиливающих свои модули/политиков, блокирующих гитхаб
+ нормальные, повторяемые сборки

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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