Скомпрометовано npm-пакети Red Hat: понад 30 репозиторіїв постачають викрадач хмарних облікових даних
Скоординована атака на ланцюг постачання npm для викрадення хмарних облікових даних зачепила один із найвідоміших брендів корпоративного програмного забезпечення. Невідомі зловмисники скомпрометували понад 30 npm-пакетів Red Hat Cloud Services, спочатку захопивши обліковий запис GitHub співробітника Red Hat, а потім використавши цей доступ для надсилання шкідливих комітів. Шкідливе програмне забезпечення, вбудоване в ці пакети, ідентифіковане як варіант штаму «Mini Shai-Hulud», виконується автоматично під час інсталяції та негайно починає викрадати хмарні облікові дані, зокрема ключі доступу AWS, GCP та Azure, а також SSH-ключі та файли конфігурації Kubernetes.
Цей інцидент вирізняється не через слабкість самого npm, а через те, як зловмисники проникли: через легітимну, довірену особу розробника.
Як було скомпрометовано npm-пакети Red Hat
Ланцюг атаки розпочався з компрометації одного облікового запису GitHub, що належав співробітнику Red Hat. Опинившись у цьому обліковому записі, зловмисники отримали доступ, необхідний для безпосереднього надсилання коду до репозиторіїв, пов’язаних із npm-пакетами Red Hat Cloud Services. Оскільки коміти надходили від розпізнаного облікового запису контриб’ютора, автоматизованим конвеєрам та рецензентам було значно важче виявити щось підозріле.
Це визначальна риса атаки на ланцюг постачання програмного забезпечення: шкідливе навантаження подорожує всередині легітимного програмного забезпечення, підписаного та розповсюдженого через довірені канали. Розробники, які встановили або оновили будь-які з уражених пакетів протягом вікна компрометації, несвідомо виконали шкідливе ПЗ на власних системах без жодних очевидних попереджень. Самі пакети продовжували працювати нормально, що ще більше ускладнювало виявлення.
Варіант шкідливого ПЗ «Mini Shai-Hulud» спеціально розроблений для запуску під час інсталяції, у момент, коли розробник вводить npm install. Він не чекає запуску застосунку чи взаємодії з користувачем. Такий підхід різко скорочує час між зараженням і викраденням даних.
Які облікові дані було викрадено та чому це важливо
Список цілей шкідливого ПЗ читається як перелік найнебезпечніших речей, які зловмисник міг би витягти з робочої станції розробника або виконавця CI/CD-конвеєра. Файли облікових даних AWS, Google Cloud Platform та Azure є основними цілями, оскільки ці ключі часто мають широкі дозволи на виробничу інфраструктуру. Приватні SSH-ключі та файли конфігурації Kubernetes доповнюють здобич, надаючи зловмисникам потенційні шляхи горизонтального переміщення у внутрішні мережі та кластери оркестрації контейнерів.
Для організацій, які використовують автоматизовані конвеєри збірки, ризик витоку посилюється. CI/CD-системи часто зберігають довготривалі хмарні облікові дані як змінні середовища або змонтовані секрети. Один заражений виконавець збірки може непомітно передати ключі, які контролюють цілі хмарні середовища, потенційно відчиняючи двері до викрадення даних, розгортання програм-вимагачів або постійного бекдор-доступу.
Це також причина, чому командам безпеки варто пам’ятати, що точки входу в ланцюг постачання часто ведуть до глибшої компрометації системи. Нещодавнє попередження CISA щодо CVE-2026-31431, вразливості локального підвищення привілеїв у Linux, є прямим нагадуванням: зловмисники, які потрапили в систему з викраденими обліковими даними або початковим доступом, рідко зупиняються на цьому. Вони шукають наступну ланку в ланцюзі.
Чому атаки на ланцюг постачання є сліпою зоною для стандартних засобів безпеки
Традиційні засоби безпеки побудовані на припущенні, що зовнішній, непідписаний або невідомий код становить загрозу. Брандмауери, агенти виявлення на кінцевих точках та сканери на основі сигнатур відкалібровано на позначення аномалій. Атаки на ланцюг постачання підривають цю модель, ховаючись усередині програмного забезпечення, яке має легітимний підпис і надходить очікуваним каналом.
У цьому випадку бренд Red Hat та пов’язана з ним історія облікового запису GitHub надали б скомпрометованим пакетам високий ступінь неявної довіри. Розробники, які працюють з інфраструктурою, пов’язаною з Red Hat, могли встановити ці пакети саме тому, що очікували від них належного обслуговування та безпеки.
Стандартні інструменти сканування залежностей, які перевіряють наявність відомих вразливих версій, не виявили б викрадачів облікових даних, що запускаються під час інсталяції, якщо шкідлива версія ще не була позначена в базі даних вразливостей. Атака використовує розрив між виявленням «відомого поганого» та поведінковим аналізом.
Багаторівневий захист: управління секретами, мережева сегментація та VPN
Жоден окремий засіб контролю не зупиняє витончену атаку на ланцюг постачання, але багаторівневий захист може значно зменшити радіус ураження.
Управління секретами замість локальних файлів облікових даних. Найефективніший спосіб зменшення ризику — повністю виключити статичні файли облікових даних із машин розробників та CI/CD-виконавців. Інструменти, які видають короткострокові, «якраз вчасно» облікові дані, означають, що навіть якщо їх викрадено, вони застаріють раніше, ніж зловмисник зможе ними скористатися.
Фіксація залежностей та перевірка цілісності. Замикання пакетів на конкретні, перевірені хеші комітів замість плаваючих діапазонів версій обмежує вплив неочікуваних змін коду. Поєднання цього з автоматизованими перевірками цілісності вмісту пакетів додає ще один рівень виявлення.
Мережева сегментація та фільтрація вихідного трафіку. Шкідливому ПЗ Mini Shai-Hulud потрібно кудись відправляти викрадені дані. Обмеження вихідних з’єднань із середовищ збірки та машин розробників лише до відомих кінцевих точок може запобігти витоку, навіть якщо шкідливе ПЗ успішно виконалося. VPN та мережеві архітектури з нульовою довірою можуть послідовно застосовувати ці політики вихідного трафіку для розподілених команд.
Багатофакторна автентифікація для кожного облікового запису розробника. Початковою компрометацією тут було захоплення облікового запису GitHub. Суворі вимоги MFA, особливо апаратні ключі безпеки або автентифікація на основі ключів доступу, значно ускладнюють захоплення облікового запису.
Поведінковий моніторинг у CI/CD-конвеєрах. Сповіщення про неочікувані вихідні DNS-запити або мережеві з’єднання під час фази збірки можуть виявити шкідливе ПЗ, яке спрацьовує під час інсталяції, ще до того, як викрадені облікові дані будуть використані.
Що це означає для вас
Якщо ваше середовище розробки або експлуатації залежить від будь-яких npm-пакетів Red Hat Cloud Services, негайним пріоритетом є аудит використовуваних версій пакетів, перевірка індикаторів компрометації в мережевих журналах навколо подій інсталяції та ротація всіх хмарних облікових даних, які могли бути присутні на уражених системах.
У ширшому сенсі цей інцидент є приводом переглянути гігієну ваших хмарних облікових даних від початку до кінця. Чи зберігаються облікові дані у вигляді файлів на машинах розробників? Чи мають змінні середовища CI/CD мінімально необхідні дозволи? Чи MFA застосовується до кожного облікового запису з правами публікації пакетів?
Атаки на ланцюг постачання досягають успіху, експлуатуючи довіру. Контрзаходом є побудова систем, які не покладаються лише на неявну довіру — перевірені ідентичності, обмежені в часі секрети та поведінковий моніторинг є основою. Почніть з аудиту облікових даних сьогодні та ставтеся до кожної залежності як до потенційної поверхні атаки, що заслуговує на ретельний контроль.
