Протягом 93 хвилин встановлення «офіційного» CLI Bitwarden перетворювало ноутбуки на Launchpad для захоплення облікових записів GitHub

22 квітня шкідлива версія інтерфейсу командного рядка Bitwarden з'явилася на npm під офіційною назвою пакета @bitwarden/[email protected]. Протягом 93 хвилин будь-хто, хто завантажував CLI через npm, отримував бекдорований замінник легітимного інструменту.

Bitwarden виявив компрометацію, видалив пакет і опублікував заяву, в якій зазначив, що не знайшов жодних доказів того, що зловмисники отримали доступ до даних сховища кінцевих користувачів або скомпрометували виробничі системи.

Компанія з дослідження безпеки JFrog проаналізувала шкідливе навантаження та виявила, що воно не мало особливого інтересу до сховищ Bitwarden. Воно було спрямоване на токени GitHub, токени npm, SSH-ключі, історію оболонки, облікові дані AWS, облікові дані GCP, облікові дані Azure, секрети GitHub Actions та файли конфігурації інструментів ШІ.

Це облікові дані, які керують тим, як команди збирають, розгортають і отримують доступ до своєї інфраструктури.

Bitwarden обслуговує понад 50 000 підприємств та 10 мільйонів користувачів, а його власна документація описує CLI як «потужний, повнофункціональний» спосіб доступу до сховища та керування ним, зокрема в автоматизованих робочих процесах, які автентифікуються за допомогою змінних середовища.

Bitwarden називає npm найпростішим і найкращим методом встановлення для користувачів, які вже знайомі з реєстром. Така комбінація використання автоматизації, встановлення на машині розробника та офіційного дистрибутива npm розміщує CLI саме там, де зазвичай зберігаються цінні секрети інфраструктури.

Аналіз JFrog показує, що шкідливий пакет перепрограмував як хук preinstall, так і точку входу бінарного файлу bw до завантажувача, який завантажував середовище виконання Bun і запускав обфускований пейлоад. Компрометація спрацьовує під час встановлення та під час виконання.

Організація могла запускати бекдорований CLI, не торкаючись жодних збережених паролів, тоді як шкідливе програмне забезпечення систематично збирало облікові дані, що керують її конвеєрами CI, хмарними обліковими записами та автоматизацією розгортання.

Компанія з безпеки Socket стверджує, що атака, схоже, використала скомпрометований GitHub Action у конвеєрі CI/CD Bitwarden, що відповідає шаблону, який відстежують дослідники Checkmarx.

Bitwarden підтвердив, що інцидент пов'язаний з більш широкою кампанією Checkmarx щодо ланцюга постачання.

Вузьке місце довіри

Npm створив свою модель надійної публікації саме для вирішення цього класу ризиків.

Замінюючи довготривалі токени публікації npm автентифікацією CI/CD на основі OIDC, система усуває один із найпоширеніших шляхів, які зловмисники використовують для захоплення випусків реєстру, і npm рекомендує надійну публікацію та розглядає її як значний крок вперед.

Складнішою поверхнею є сама логіка випуску, наприклад робочі процеси та дії, які викликають крок публікації. Власна документація npm рекомендує заходи контролю, що виходять за межі OIDC, наприклад середовища розгортання з вимогами ручного затвердження, правила захисту тегів та обмеження гілок.

Налаштування середовища GitHub дозволяють організаціям вимагати підпису рецензентів перед розгортанням робочого процесу. Фреймворк SLSA іде далі, вимагаючи від споживачів перевіряти, чи збігається походження з очікуваними параметрами, такими як правильний репозиторій, гілка, тег, робочий процес та конфігурація збірки.

Інцидент з Bitwarden показує, що складніша проблема знаходиться на рівні робочого процесу. Якщо зловмисник може використати сам робочий процес випуску, значок «офіційний» все одно супроводжує шкідливий пакет.

Надійна публікація переміщує тягар довіри вгору до цілісності робочих процесів та дій, які її викликають, — рівня, який організації здебільшого залишили непослідовним.

Один токен — багато дверей

Для команд розробників та інфраструктури скомпрометований робочий процес випуску розкриває конвеєри CI, інфраструктуру автоматизації та облікові дані, що ними керують.

Аналіз JFrog показує, що після отримання шкідливим програмним забезпеченням токена GitHub воно могло перевірити токен, перелічити записувані репозиторії, перелічити секрети GitHub Actions, створити гілку, зафіксувати робочий процес, дочекатися його виконання, завантажити отримані артефакти, а потім прибрати за собою.

Отримання токена створює автоматизований ланцюг, який перетворює єдиний вкрадений обліковий запис на постійний доступ до всієї інфраструктури автоматизації організації.

Ноутбук розробника, який встановлює отруєний офіційний пакет, стає мостом від локального сховища облікових даних хоста до доступу до GitHub та всього, чого може досягти цей токен GitHub.

Інцидент з Bybit є близькою структурною аналогією. Скомпрометована робоча станція розробника дозволила зловмисникам отруїти надійний інтерфейс вищого рівня, який потім досяг операційного процесу жертви.

Різниця полягає в тому, що Bybit стосувався підробленого веб-інтерфейсу Safe, тоді як Bitwarden стосувався підробленого офіційного пакета npm.

У середовищах криптовалют, фінтеху або кастодіальних середовищах цей шлях може пролягати від сховища облікових даних до підписантів випуску, хмарного доступу та систем розгортання, жодного разу не торкнувшись запису сховища.

Протягом 60 днів Checkmarx розкрив скомпрометовані робочі процеси GitHub Actions та плагіни OpenVSX, тоді як Cloud Security Alliance попередив, що кампанія TeamPCP активно компрометує проєкти з відкритим вихідним кодом та компоненти автоматизації CI/CD.

JFrog задокументував, як скомпрометований GitHub Action Trivy витік токен публікації LiteLLM та уможливив шкідливі випуски PyPI, а Axios розкрив, що дві шкідливі версії npm поширювалися приблизно три години через скомпрометований обліковий запис супровідника.

Sonatype нарахував понад 454 600 нових шкідливих пакетів лише у 2025 році, довівши загальний сукупний показник до понад 1,2 мільйона. Bitwarden приєднується до ланцюжка інцидентів, які підтверджують, що робочі процеси випуску та реєстри пакетів є основною поверхнею атаки.

Точна першопричина ще не є публічною, оскільки Bitwarden підтвердив зв'язок з кампанією Checkmarx, але не опублікував детального опису того, як зловмисник отримав доступ до конвеєра випуску.

Наслідки атаки

Найсильнішим результатом для захисників є те, що цей інцидент прискорює переосмислення значення слова «офіційний».

Сьогодні надійна публікація прикріплює дані про походження до кожного випущеного пакета, тим самим підтверджуючи ідентифікацію видавця в реєстрі. SLSA явно документує вищий стандарт для верифікаторів, щоб перевірити, чи відповідає походження очікуваному репозиторію, гілці, робочому процесу та параметрам збірки.

Якщо цей стандарт стане поведінкою споживача за замовчуванням, «офіційний» почне означати «створений правильним робочим процесом за правильних умов», і зловмисник, який компрометує дію, але не може задовольнити кожне обмеження походження, створює пакет, який автоматизовані споживачі відхиляють до його встановлення.

Більш правдоподібний короткостроковий шлях рухається у протилежному напрямку. Зловмисники продемонстрували щонайменше у 4 інцидентах за 60 днів, що робочі процеси випуску, залежності дій та облікові дані, суміжні з супровідником, дають результати з високою цінністю при відносно низькому опорі.

Кожен наступний інцидент додає ще одну задокументовану техніку до публічного посібника із компрометації дій, крадіжки токенів із результатів CI, захоплення облікового запису супровідника та зловживання надійним шляхом публікації.

Якщо верифікація походження не стане поведінкою споживача за замовчуванням, а не необов'язковим рівнем політики, офіційні назви пакетів матимуть більше довіри, ніж можуть виправдати їхні процеси випуску.

Публікація «Протягом 93 хвилин встановлення «офіційного» CLI Bitwarden перетворювало ноутбуки на Launchpad для захоплення облікових записів GitHub» вперше з'явилася на CryptoSlate.