Один забытый токен открыл Grafana приватные репозитории

Взлом Grafana Labs, связанный с атакой на цепочку поставки TanStack npm, похоже, свелся к одному пропущенному токену GitHub workflow.

По данным BleepingComputer, Grafana заметила вредоносную активность после того, как скомпрометированные пакеты TanStack попали в ее CI/CD workflow. В ответ Grafana сменила множество GitHub workflow tokens, но позже выяснила, что один токен не попал в ротацию. Атакующий использовал его для доступа к приватным репозиториям GitHub.

Что произошло#

Инцидент связан с более широкой кампанией вредоноса Shai-Hulud, которую в отчете приписывают хакерам TeamPCP. В этой кампании десятки пакетов TanStack, опубликованных в npm, были заражены кодом для кражи учетных данных.

Среда разработки Grafana оказалась среди затронутых. Когда вредоносный npm-пакет вышел, его подтянул CI/CD workflow Grafana. Компонент-инфостилер затем выполнился внутри GitHub-среды Grafana и вывел GitHub workflow tokens.

Grafana сообщила, что обнаружила вредоносную активность из скомпрометированных пакетов TanStack 1 мая и начала реагирование на инцидент. Среди мер была ротация GitHub workflow tokens.

Проблема оказалась в охвате.

Grafana сменила значительное число токенов, но один токен остался за пределами ротации. Позже компания выяснила, что GitHub workflow, который сначала сочли незатронутым, на самом деле был скомпрометирован. Этот пропущенный токен и стал путем атакующего в приватные репозитории Grafana.

Ранее Grafana уже говорила, что злоумышленники украли исходный код. Последующая проверка также показала, что атакующий скачал операционную информацию и деловые данные, которыми пользовалась Grafana. Компания описала эти данные как имена бизнес-контактов и адреса электронной почты, которыми обменивались в контексте профессиональных отношений.

Grafana подчеркивает: это не были клиентские production-данные и не данные, извлеченные из production-систем Grafana Cloud или обработанные через них.

Что, по словам Grafana, не пострадало#

Текущая позиция Grafana такова: нет доказательств, что клиентские production-системы или операции были скомпрометированы.

Компания также заявляет, что кодовая база во время инцидента не менялась. На основании этого Grafana считает код, скачанный пользователями в период инцидента, безопасным и говорит, что пользователям сейчас не нужно ничего предпринимать.

Это важное разграничение. Взлом приватного репозитория может создавать разные риски. Украденный исходный код — один риск. Измененный исходный код — другой. Скомпрометированные сборки или релизные артефакты — третий. Они связаны, но это не одно и то же.

В этом случае публичные сообщения говорят о краже исходного кода, но Grafana утверждает, что кодовая база не была изменена. Также, по последним данным и итогам расследования, компания не видит компрометации production-систем клиентов.

Отсюда две четкие границы:

• Grafana подтвердила доступ к репозиториям и кражу данных.
• Grafana не сообщала о компрометации клиентского production или о вредоносном изменении кода.

Эти границы стоит сохранять, пока новые факты их не изменят. Grafana заявила, что напрямую уведомит затронутых клиентов, если ее оценка изменится.

Почему один пропущенный токен так важен#

Этот взлом — наглядный пример частого сбоя в CI/CD: реагирование на инцидент зависит от того, знаете ли вы все учетные данные, которые имеют значение.

Ротация токенов звучит просто. На практике она упирается в инвентаризацию, карту workflow, права доступа, владельцев и предположения о том, какие jobs были под ударом. Если один workflow ошибочно признали безопасным, его токен может пережить зачистку. Если у этого токена остаются существенные права, инцидент продолжается.

Атакующему не понадобился второй экзотический эксплойт после компрометации npm-пакета. Украденного workflow token оказалось достаточно.

В этом и неприятный урок. Современные цепочки поставки ПО часто ломаются на стыках систем: npm, GitHub Actions, права репозиториев, сборочные jobs, пути деплоя и хранилища секретов. У каждого слоя свои логи и своя модель доступа. Во время инцидента защитникам приходится под давлением восстанавливать реальный граф доверия.

Пропущенный токен — не мелкая канцелярская ошибка, если он может читать приватные репозитории.

Что стоит проверить командам#

Согласно текущим заявлениям Grafana, от клиентов Grafana не требуется публичных действий. Но инженерные и security-команды могут использовать этот случай как практический чек-лист для своих сред.

Начните с инвентаризации CI/CD-токенов. Нужно понимать, какие workflows могут выпускать или использовать токены, к каким репозиториям они имеют доступ и какие у них права: только чтение или шире, чем нужно.

Проверьте, как сборочные среды потребляют пакеты. Если вредоносная зависимость выполнилась внутри CI, считайте, что она могла увидеть переменные окружения, workflow tokens, учетные данные реестров и любые доступные секреты.

Пересмотрите playbooks для ротации. Хороший playbook не должен ограничиваться фразой «сменить токены». Он должен описывать, как найти каждый класс токенов, каждый workflow, каждую установку app, каждый deploy key и каждую машинную учетную запись, которые могли быть раскрыты.

Проверьте настройки прав workflow по умолчанию. GitHub Actions и похожие CI-системы часто позволяют сузить права токенов. Если workflow нужен только доступ на чтение, у него не должно быть доступа на запись. Если ему не нужен доступ к содержимому репозитория, такого доступа быть не должно.

Ищите устаревшее доверие. Старые workflows, отключенные jobs, тестовые pipelines, заброшенные репозитории и разовые интеграции часто живут дальше, потому что не шумят. Но во время атаки на цепочку поставки «тихо» не значит «безопасно».

Чего не стоит утверждать сверх фактов#

Текущие публичные факты не подтверждают, что production-системы Grafana Cloud были скомпрометированы. Они также не подтверждают, что пользователи скачивали Grafana-код с бэкдором во время инцидента.

При этом взлом серьезный. Приватный исходный код и операционная бизнес-информация имеют ценность. Атакующие могут использовать украденный код для поиска уязвимостей, фишинга, имперсонации или будущих попыток проникновения. Деловые контактные данные помогают точечной социальной инженерии.

Но различие важно. Если считать каждый взлом репозитория компрометацией production, это создает шум. Если считать его безвредным только потому, что production-системы не пострадали, это тоже ошибка.

Более точная и полезная формулировка уже: скомпрометированный пакет привел к краже токенов; при ротации пропустили одну учетную запись; она дала доступ к приватным репозиториям и позволила украсть данные.

Этого достаточно, чтобы внимательно разобрать инцидент.

Где скрыт главный разрыв в контролях#

Инцидент Grafana показывает, почему реагирование на supply-chain атаку не может заканчиваться удалением вредоносной зависимости.

Как только чужой код выполнился в CI, вопрос меняется. Это уже не только «какой пакет был вредоносным?». Это «что этот пакет мог увидеть, украсть или запустить из этого контекста выполнения?».

Сюда входят workflow tokens. Секреты. Доступ к репозиториям. Соседние jobs. Бизнес-логика, спрятанная в сборочных скриптах.

Сложность в том, что CI/CD-системы специально спроектированы для соединения вещей. Они забирают код, ставят зависимости, гоняют тесты, публикуют артефакты, аутентифицируются в реестрах и иногда деплоят. Эта связность полезна. По этой же причине одна скомпрометированная зависимость может быстро превратиться в инцидент с учетными данными.

Пропущенный токен Grafana — именно тот тип ошибки, который могут допустить даже зрелые команды. Исправление не в лозунге про zero trust. Нужен скучный набор контролей: минимальные права, полная инвентаризация, токены с узкой областью действия, короткий срок жизни, надежная ротация и incident playbooks, которые исходят из того, что первая оценка ущерба может быть неверной.

Именно там находится главный урок.