Кілька днів тому GitHub виявив два інциденти в інфраструктурі сховища пакетів NPM, з яких повідомляється, що 2 листопада сторонні дослідники безпеки в рамках програми Bug Bounty виявили вразливість у сховищі NPM що дозволяє публікувати нову версію будь-якого пакета, навіть якщо він не авторизований виконувати такі оновлення.
Уразливість була викликана неправильними перевірками авторизації в коді мікросервісів які обробляють запити до NPM. Служба авторизації виконала перевірку дозволів для пакетів на основі даних, переданих у запиті, але інша служба, яка завантажувала оновлення в репозиторій, визначила пакет для публікації на основі вмісту метаданих у завантаженому пакеті.
Таким чином, зловмисник може запросити публікацію оновлення для свого пакета, до якого він має доступ, але вказати в самому пакеті інформацію про інший пакет, який з часом буде оновлений.
Протягом останніх кількох місяців команда npm інвестувала в покращення інфраструктури та безпеки, щоб автоматизувати моніторинг та аналіз нещодавно випущених версій пакетів для виявлення зловмисного програмного забезпечення та іншого шкідливого коду в режимі реального часу.
Є дві основні категорії подій публікації шкідливих програм, які відбуваються в екосистемі npm: зловмисне програмне забезпечення, яке публікується через викрадення облікового запису, і зловмисне програмне забезпечення, яке зловмисники публікують через власні облікові записи. Незважаючи на те, що придбання облікових записів з високим рівнем впливу є відносно рідкісними, порівняно з прямим зловмисним програмним забезпеченням, опублікованим зловмисниками за допомогою власних облікових записів, придбання облікових записів може бути далекосяжним, якщо орієнтуватися на популярних супроводжувачів пакетів. Хоча час виявлення та реагування на придбання популярних пакетів в останніх інцидентах становив лише 10 хвилин, ми продовжуємо вдосконалювати наші можливості виявлення зловмисного програмного забезпечення та стратегії сповіщень до більш активної моделі реагування.
Проблема це було виправлено через 6 годин після повідомлення про вразливість, але вразливість була присутня в NPM довше ніж те, що охоплюють журнали телеметрії. GitHub стверджує, що не було жодних слідів атак із використанням цієї уразливості з вересня 2020 року, але немає гарантії, що проблема не була використана раніше.
Другий інцидент стався 26 жовтня. В ході технічної роботи з базою даних сервісу replicant.npmjs.com, було виявлено, що в базі даних є конфіденційні дані, доступні для зовнішньої консультації, відкриваючи інформацію про назви внутрішніх пакетів, які були згадані в журналі змін.
Інформація про ці імена можна використовувати для здійснення атак залежностей на внутрішні проекти (У лютому така атака дозволила запускати код на серверах PayPal, Microsoft, Apple, Netflix, Uber та 30 інших компаній.)
Крім того, у зв'язку зі збільшенням випадків захоплення сховищ великих проектів і просування шкідливого коду через компрометацію облікових записів розробників, GitHub вирішив ввести обов’язкову двофакторну аутентифікацію. Зміна набуде чинності в першому кварталі 2022 року і пошириться на супроводжувачів і адміністраторів пакетів, що входять до списку найпопулярніших. Крім того, повідомляється про модернізацію інфраструктури, яка запровадить автоматизований моніторинг та аналіз нових версій пакетів для раннього виявлення шкідливих змін.
Нагадаємо, згідно з дослідженням, проведеним у 2020 році, лише 9.27% менеджерів пакетів використовують двофакторну аутентифікацію для захисту доступу, а в 13.37% випадків при реєстрації нових облікових записів розробники намагалися повторно використати зламані паролі, які з'являються у відомих паролях. .
Під час перевірки надійності використовуваних паролів 12% облікових записів у NPM (13% пакетів) були доступні за рахунок використання передбачуваних і тривіальних паролів типу «123456». Серед проблем були 4 облікові записи користувачів із 20 найпопулярніших пакетів, 13 облікових записів, пакети яких завантажувалися понад 50 мільйонів разів на місяць, 40 – понад 10 мільйонів завантажень на місяць та 282 з понад 1 мільйоном завантажень на місяць. Враховуючи навантаження модулів уздовж ланцюжка залежностей, скомпрометація ненадійних облікових записів може вплинути на до 52% усіх модулів у NPM.
Нарешті, якщо вам цікаво дізнатись більше про це Ви можете перевірити деталі У наступному посиланні.