The OpenNET Project / Index page

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

Выявлена попытка включения бэкдора в популярный NPM-пакет mailparser

03.05.2018 22:43

Администраторы репозитория NPM предупредили пользователей о выявлении бэкдора в популярном JavaScript-пакете 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 не ясно, но после инцидента возможность входа по данному аккаунту была заблокирована.

  1. Главная ссылка к новости (https://blog.npmjs.org/post/17...)
  2. OpenNews: Критическая проблема в NPM 5.7, приводящая к смене прав доступа на системные каталоги
  3. OpenNews: Сбой антиспам-системы привёл к коллапсу в репозитории NPM
  4. OpenNews: Инцидент с захватом прав на NPM-модуль привёл к сбою в работе проектов, использующих NPM
  5. OpenNews: Более половины npm-пакетов могли быть скомпрометированы из-за ненадёжных паролей доступа
  6. OpenNews: Применение тайпсквоттинга для распространения вредоносных модулей NPM, PyPI и Gems
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/48544-npm
Ключевые слова: npm, backdoor
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (21) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:48, 03/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +18 +/
    Как тут любят говорить: "Полон опасностей NPM JS мирок".
     
     
  • 2.13, Ydro (?), 07:46, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Такое может сказать только тот кто ни разу не программировал и не устанавливал зависимости в других языках. А в зависимости для других языков запрещено вставлять бэкдоры, например в GoLang у которого нет даже понятия версия для пакета?
     
     
  • 3.23, Crazy Alex (ok), 11:49, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Нашёл что в пример приводить. А в нормальных промышленных языках библиотеки не имеют таких адовых графов зависимостей и не обновляются два раза в неделю.
     
  • 3.37, 0xd34df00d (??), 05:07, 07/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    В некоторых других языках код, который может получать что-то там по HTTP/email/ssh, сразу видно по типам функций, а пара воркэраундов легко грепается по словам вроде unsafePerformIO.
     
  • 2.36, Anonymuos (?), 09:47, 06/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    https://habr.com/company/ruvds/blog/346442/ :-)
     

  • 1.2, АНБ (?), 23:03, 03/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +16 +/
    Пользователи, не беспокойтесь, всё под контролем. Агент 87 отправлен на спецкурс переподготовки. Встречайте агента 88.
     
  • 1.3, Аноним (-), 23:06, 03/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Каким образом злоумышленники получили доступ к учётной записи автора mailparser не ясно, но после инцидента возможность входа по данному аккаунту была заблокирована.

    А возможность того, что он добавил зависимость по невнимательности они не рассматривали?

     
     
  • 2.4, Аноним (-), 23:43, 03/05/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Тогда там почти всех банить придется, чую…
     

  • 1.12, Аноним (-), 07:26, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    >в mailparser использовался пакет http-fetch-cookies, который использовал модуль express-cookies, который, в свою очередь, загружал вредоносный getcookies

    Ну вы поняли

     
     
  • 2.19, Аноним (-), 09:47, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>в mailparser использовался пакет http-fetch-cookies, который использовал модуль express-cookies, который, в свою очередь, загружал вредоносный getcookies
    > Ну вы поняли

    Это все что надо знать о NPM. И о тех кто его использует.

     
     
  • 3.20, 1 (??), 09:55, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    А где там в конце однострочник на Per^W JS ?
     
  • 3.25, YetAnotherOnanym (ok), 14:26, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • –2 +/
    То, что ПО тянет зависимости, которые, в свою очередь, тянут свои зависимости - это, как раз таки, правильно. Гляньте, например, rebar.config любого мало-мальски серьёзного проекта на Эрланге - там тоже десяток-другой зависимостей, у каждой из которых в rebar.config свои зависимости, и так далее, и которые при сборке тянутся из сети (правда, в rebar автор может гвоздями прибить конкретную версию зависимости, работоспособность и отсутствие багов в которой он проверил, после этого в следующие версии можно что угодно добавить, собираться софт будет только с указанной версией с правильным хэшем).
    Если честно, я вполне допускаю аналогичный сценарий ("получили доступ к учётной записи автора") для  любого ${language_name}-мирка, в чём особенность ноды, из-за которой вокруг таких инцидентов так много шума - я хз.
     
     
  • 4.27, Аноним (-), 18:32, 04/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > правда, в rebar автор может гвоздями прибить конкретную версию зависимости, работоспособность и отсутствие багов в которой он проверил, после этого в следующие версии можно что угодно добавить, собираться софт будет только с указанной версией с правильным хэшем

    Да-да, и с правильными дырами, давно закрытыми в новых версиях. У всех одно и то же — что у жабистов, что у питонщиков; вот и у эрлангеров, оказывается.

     
     
  • 5.30, YetAnotherOnanym (ok), 00:23, 05/05/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > дырами, давно закрытыми в новых версиях

    Можно ссылочку на CVE по дырам, например, в зависимостях riak? Вот тут списочек, если что: https://github.com/basho/riak/blob/develop/rebar.config.lock

     
     
  • 6.32, Crazy Alex (ok), 01:17, 05/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, тут уж кому что больше во вкусу - то ли известные проблемы и предсказуемая работа и разработка, то ли гонка за свежаком. По-хорошему - решается разделением на стабильную и нестабильную ветки, а дальше, в зависимости от вменяемости разработчиков конкретного модуля - прибивать гвоздями только мажор либо конкретную версию. Одно время в джаве так модно было, не знаю, как сейчас
     
  • 4.31, Crazy Alex (ok), 01:14, 05/05/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Особенности таковы:
    1) очень мелкая разбивка. В результате модулей чёртова гора и БОЛЬШАЯ куча зависимостей
    2) частый выход обновлений - ревьюить задолбаешься
    3) обычно отсутствие вменяемого менеджмента версий - ломают API только так, поэтому зафиксировать версию - разве что для всего целиком, и тогда - привет известные дыры
    4) браузерная гонка, тоже провоцирующая обновления.

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

     

  • 1.24, Урри (?), 14:05, 04/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    И ведь эта проблема принципиально не решаема.
     
     
  • 2.33, Crazy Alex (ok), 01:19, 05/05/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Запросто решаема - собственно, в тех же плюсах её вообще нет, потому что работа с библиотеками по-другому устроена. И в джаве нет, где тоже всё по-своему. Это именно в JS сложилась совершенно безумная модель - миллион мелких либ, обновляющихся по два раза в день, ломая зависимости
     

  • 1.34, anomymous (?), 10:15, 05/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Любители хипстареп должны страдать.
     
  • 1.38, Аноним (-), 22:41, 07/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если посмотреть всю хронологию произошедших подобных событий, то сразу становится понятно - где собака зарыта. Исправить все это дело - сущий пустяк. Опять же, получили доступ к учетке владельца с предполагаемым паролем вида "12345". К счастью, сам js ко всему этому отношение имеет мало.
     
  • 1.39, Роб Пайк (?), 23:25, 07/05/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Как то недавно попробовал создание мобильного приложения на популярной JS технологии , дак там зависимостей на 20.000 различных файлов, вот и ищи бэкдоры)
     

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



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

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