Вредоносная версия CLI Bitwarden на 93 минуты превратила ноутбуки в платформы для захвата аккаунтов GitHub

22 апреля 2023 года на платформе npm появилась вредоносная версия командной строки Bitwarden под официальным названием @bitwarden/cli@2026.4.0. В течение 93 минут любой, кто загружал этот инструмент через npm, получал подмененный пакет вместо легитимного инструмента. Bitwarden обнаружил компрометацию, удалил пакет и выпустил заявление, в котором указал, что не нашел доказательств того, что злоумышленники получили доступ к данным пользователей или скомпрометировали производственные системы.

Анализ вредоносного кода

Исследовательская компания JFrog проанализировала вредоносный код и обнаружила, что он не имел особого интереса к хранилищам Bitwarden. Основные цели злоумышленников включали токены GitHub, токены npm, SSH-ключи, историю команд, учетные данные AWS, GCP, Azure, секреты GitHub Actions и конфигурационные файлы инструментов искусственного интеллекта. Эти данные представляют собой учетные записи, которые управляют тем, как команды создают, развертывают и взаимодействуют со своей инфраструктурой.

Типы целевых данных и их важность

Каждый из типов данных, на которые нацелились злоумышленники, имеет свою специфику и важность:

• Токены GitHub: Хранятся на ноутбуках разработчиков и в средах CI, могут предоставить доступ к репозиториям и автоматизации.
• Токены npm: Используются в локальных конфигурациях и средах релиза, могут быть использованы для публикации вредоносных пакетов.
• SSH-ключи: Хранятся на машинах разработчиков, могут открыть доступ к серверам и внутренним репозиториям.
• История команд: Хранится на локальных машинах, может раскрыть секреты и команды.
• Учетные данные AWS, GCP, Azure: Хранятся в локальных конфигурационных файлах, могут раскрыть облачные рабочие нагрузки и системы развертывания.
• Секреты GitHub Actions: Используются в средах CI/CD, могут предоставить доступ к автоматизации и развертываниям.
• Конфигурационные файлы инструментов ИИ: Хранятся в директориях проектов, могут раскрыть API-ключи и внутренние конечные точки.

Как произошла компрометация

Анализ JFrog показывает, что вредоносный пакет изменил как предустановочный хук, так и точку входа bw бинарника, чтобы загрузить обфусцированный код. Компрометация происходила как во время установки, так и во время выполнения. Организация могла запускать подмененный CLI, не затрагивая хранящиеся пароли, в то время как вредоносное ПО систематически собирало учетные данные, управляющие ее CI-пайплайнами, облачными аккаунтами и автоматизацией развертывания.

Безопасная компания Socket утверждает, что атака, похоже, использовала скомпрометированное действие GitHub в CI/CD-пайплайне Bitwarden, что соответствует паттерну, который исследователи Checkmarx отслеживают. Bitwarden подтвердил, что инцидент связан с более широкой кампанией поставок Checkmarx.

Проблемы доверия в экосистеме npm

Npm разработал свою модель доверенной публикации, чтобы справиться с подобным риском. Заменив долгосрочные токены публикации npm на аутентификацию на основе OIDC, система устраняет один из самых распространенных путей, которые злоумышленники используют для захвата релизов реестра. Npm рекомендует доверенную публикацию и рассматривает ее как значительный шаг вперед. Однако более сложной задачей остается логика релиза, такая как рабочие процессы и действия, которые вызывают этап публикации.

Документация npm рекомендует использовать дополнительные меры контроля, такие как среды развертывания с требованиями к ручному одобрению, правила защиты тегов и ограничения на ветки. Это создает дополнительные уровни защиты, которые могут помочь предотвратить подобные атаки в будущем.

Последствия инцидента

Точные причины инцидента пока не раскрыты, так как Bitwarden подтвердил связь с кампанией Checkmarx, но не опубликовал подробный анализ того, как злоумышленник получил доступ к пайплайну релиза. Наиболее сильным результатом для защитников является то, что этот инцидент может ускорить переосмысление того, что значит «официальный» пакет.

Сегодня доверенная публикация прикрепляет данные о происхождении к каждому выпущенному пакету, подтверждая личность издателя в реестре. Если этот стандарт станет обычной практикой, «официальный» пакет будет означать «созданный правильным рабочим процессом в правильных условиях». Это может помочь предотвратить распространение вредоносных пакетов в будущем.

Заключение

Инцидент с Bitwarden подчеркивает важность защиты рабочих процессов и механизмов публикации в экосистеме программного обеспечения. Злоумышленники продемонстрировали, что даже официальные пакеты могут стать вектором атаки, если рабочие процессы и учетные данные, связанные с ними, не защищены должным образом. Это требует от организаций более тщательного анализа и улучшения своих процессов безопасности, чтобы предотвратить подобные инциденты в будущем. Важно, чтобы разработчики и компании осознавали риски и принимали меры для защиты своих систем и данных.