Администраторы репозитория NPM предупредили (https://blog.npmjs.org/post/173526807575/reported-malicious-...) пользователей о выявлении бэкдора в популярном JavaScript-пакете mailparser (https://www.npmjs.com/package/mailparser), который используется как зависимость в 213 пакетах и насчитывает около 64 тысяч еженедельных загрузок. Бэкдор был интегрирован в связанный зависимостями пакет getcookies и был закомуфлирован под видом библиотеки для работы с браузерными Cookie. На деле в пакете getcookies присутствовал код для получения управляющих команд от удалённого атакующего через передачу специально оформленных данных в HTTP-заголовках.
Бэкдор позволял загрузить и выполнить произвольный код на сервере, на котором выполняются web-приложения, использующие mailparser в качестве зависимости. Примечательно, что пакет mailparser помечен как устаревший и не поддерживаемый автором. Getcookies использовался в mailparser через несколько промежуточных зависимостей - в mailparser использовался пакет http-fetch-cookies, который использовал модуль express-cookies, который, в свою очередь, загружал вредоносный getcookies. На момент выявления бэкдора, вредоносный модуль лишь был указан как зависимость, но непосредственно не вызывался из mailparser, т.е. бэкдор не был активирован и, вероятно, предназначался для проведения атак в будущем.Проблема была решена мэйнтейнерами NPM в течение 2 часов после поступлении жалоб о возможном бэкдоре в пакете getcookies. После подтверждения проблемы пользователь "dustin87", который опубликовал бэкдор, был заблокирован, а предложенные им модули getcookies, express-cookies и http-fetch-cookies удалены. Пакет mailparser откатили до версии 2.2.0, в которой отсутствует зависимость http-fetch-cookies (с данной зависимостью вышло три версии 2.2.3, 2.2.2 и 2.2.1). Каким образом злоумышленники получили доступ к учётной записи автора mailparser не ясно, но после инцидента возможность входа по данному аккаунту была заблокирована.
URL: https://blog.npmjs.org/post/173526807575/reported-malicious-...
Новость: https://www.opennet.me/opennews/art.shtml?num=48544
Как тут любят говорить: "Полон опасностей NPM JS мирок".
Такое может сказать только тот кто ни разу не программировал и не устанавливал зависимости в других языках. А в зависимости для других языков запрещено вставлять бэкдоры, например в GoLang у которого нет даже понятия версия для пакета?
Нашёл что в пример приводить. А в нормальных промышленных языках библиотеки не имеют таких адовых графов зависимостей и не обновляются два раза в неделю.
В некоторых других языках код, который может получать что-то там по HTTP/email/ssh, сразу видно по типам функций, а пара воркэраундов легко грепается по словам вроде unsafePerformIO.
https://habr.com/company/ruvds/blog/346442/ :-)
Пользователи, не беспокойтесь, всё под контролем. Агент 87 отправлен на спецкурс переподготовки. Встречайте агента 88.
> Каким образом злоумышленники получили доступ к учётной записи автора mailparser не ясно, но после инцидента возможность входа по данному аккаунту была заблокирована.А возможность того, что он добавил зависимость по невнимательности они не рассматривали?
Тогда там почти всех банить придется, чую…
>в mailparser использовался пакет http-fetch-cookies, который использовал модуль express-cookies, который, в свою очередь, загружал вредоносный getcookiesНу вы поняли
>>в mailparser использовался пакет http-fetch-cookies, который использовал модуль express-cookies, который, в свою очередь, загружал вредоносный getcookies
> Ну вы понялиЭто все что надо знать о NPM. И о тех кто его использует.
А где там в конце однострочник на Per^W JS ?
То, что ПО тянет зависимости, которые, в свою очередь, тянут свои зависимости - это, как раз таки, правильно. Гляньте, например, rebar.config любого мало-мальски серьёзного проекта на Эрланге - там тоже десяток-другой зависимостей, у каждой из которых в rebar.config свои зависимости, и так далее, и которые при сборке тянутся из сети (правда, в rebar автор может гвоздями прибить конкретную версию зависимости, работоспособность и отсутствие багов в которой он проверил, после этого в следующие версии можно что угодно добавить, собираться софт будет только с указанной версией с правильным хэшем).
Если честно, я вполне допускаю аналогичный сценарий ("получили доступ к учётной записи автора") для любого ${language_name}-мирка, в чём особенность ноды, из-за которой вокруг таких инцидентов так много шума - я хз.
> правда, в rebar автор может гвоздями прибить конкретную версию зависимости, работоспособность и отсутствие багов в которой он проверил, после этого в следующие версии можно что угодно добавить, собираться софт будет только с указанной версией с правильным хэшемДа-да, и с правильными дырами, давно закрытыми в новых версиях. У всех одно и то же — что у жабистов, что у питонщиков; вот и у эрлангеров, оказывается.
> дырами, давно закрытыми в новых версияхМожно ссылочку на CVE по дырам, например, в зависимостях riak? Вот тут списочек, если что: https://github.com/basho/riak/blob/develop/rebar.config.lock
Ну, тут уж кому что больше во вкусу - то ли известные проблемы и предсказуемая работа и разработка, то ли гонка за свежаком. По-хорошему - решается разделением на стабильную и нестабильную ветки, а дальше, в зависимости от вменяемости разработчиков конкретного модуля - прибивать гвоздями только мажор либо конкретную версию. Одно время в джаве так модно было, не знаю, как сейчас
Особенности таковы:
1) очень мелкая разбивка. В результате модулей чёртова гора и БОЛЬШАЯ куча зависимостей
2) частый выход обновлений - ревьюить задолбаешься
3) обычно отсутствие вменяемого менеджмента версий - ломают API только так, поэтому зафиксировать версию - разве что для всего целиком, и тогда - привет известные дыры
4) браузерная гонка, тоже провоцирующая обновления.Эрлангеры не настолько радикальны, хотя лично мне гораздо больше нравится подход тех же плюсов, когда есть несколько вполне известных и уважаемых библиотек на все случаи жизни, а остальное и используется сравнительно редко, и от него, скорее всего, другие библиотеки зависеть не будут. Плюс более аккуратное отношение к совместимости по API.
И ведь эта проблема принципиально не решаема.
Запросто решаема - собственно, в тех же плюсах её вообще нет, потому что работа с библиотеками по-другому устроена. И в джаве нет, где тоже всё по-своему. Это именно в JS сложилась совершенно безумная модель - миллион мелких либ, обновляющихся по два раза в день, ломая зависимости
Любители хипстареп должны страдать.
Если посмотреть всю хронологию произошедших подобных событий, то сразу становится понятно - где собака зарыта. Исправить все это дело - сущий пустяк. Опять же, получили доступ к учетке владельца с предполагаемым паролем вида "12345". К счастью, сам js ко всему этому отношение имеет мало.
Как то недавно попробовал создание мобильного приложения на популярной JS технологии , дак там зависимостей на 20.000 различных файлов, вот и ищи бэкдоры)