Как один токен GitHub пробил периметр глобального фармацевтического гиганта

Novo Nordisk поддерживает многоуровневую инфраструктуру безопасности. Компания использует передовые системы обнаружения угроз на конечных точках, сегментацию сети и выделенный центр мониторинга безопасности (SOC). Эти средства защиты обходятся в миллионы долларов ежегодно. Тем не менее, вся архитектура рухнула из-за одной текстовой строки на публичном веб-сайте. Взлом датского фармацевтического гиганта — это наглядный пример архитектурного парадокса современной разработки программного обеспечения. Масштабные инвестиции в защиту периметра оказались бесполезными, так как в неположенном месте оказался один-единственный токен аутентификации.

Я провел годы, общаясь с исследователями безопасности через Signal и каналы с PGP-шифрованием. Большинство из них не ищут сложные уязвимости нулевого дня в защищенных межсетевых экранах. Они ищут путь наименьшего сопротивления. В инциденте с Novo Nordisk этим путем оказался персональный токен доступа (PAT) GitHub с высокими привилегиями, оставленный в клиентском JavaScript на малозаметном поддомене. Это не был изощренный взлом. Это было упражнение по поиску данных. Как только хакерская группа, известная под названием FulcrumSec, обнаружила токен в марте, формальный периметр безопасности перестал иметь значение. Токен обеспечил аутентифицированный доступ. Для внутренних систем злоумышленники выглядели как легитимные разработчики.

Анатомия скрытого вторжения

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

К тому времени, когда Novo Nordisk раскрыла информацию об инциденте 11 июня, злоумышленники похитили 1,3 ТБ данных. Этот архив включал 700 000 файлов. Хотя компания изначально описывала последствия как ограниченные псевдонимизированными данными пациентов и записями медицинских работников, реальность кажется более серьезной. Украденные данные включают конфиденциальную информацию о продаваемых и еще не выпущенных препаратах, исследованиях в рамках клинических испытаний и внутренних моделях ИИ. FulcrumSec утверждает, что эта информация может сэкономить конкурентам от трех до пяти лет разработки. Это определение системного сбоя. Взлом перерос из простой утечки токена в потерю ключевой интеллектуальной собственности.

Почему конвейеры разработки — это производственные системы

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

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

Невидимый риск машинных идентификаторов

Организации относятся к управлению секретами как к проблеме инструментов. Они покупают хранилище (vault) и полагают, что проблема решена. Инцидент с Novo Nordisk доказывает, что управление секретами — это проблема идентификации. Утекший токен GitHub — это машинный идентификатор. В отличие от человеческих учетных записей, у машинных учетных данных часто нет четких владельцев. У них нет последовательных графиков ротации. Им часто не хватает осмысленного мониторинга. Эти токены существуют месяцами или годами без изменений.

Шейн Барни, CISO в Keeper Security, указывает, что эта невидимость превращает один токен в долгосрочное вторжение. Когда машинные учетные данные обладают широкими полномочиями и никто не отслеживает их использование, злоумышленнику не нужно повышать привилегии. Доступ уже есть. Радиус поражения — вся среда. Вот почему злоумышленники оставались необнаруженными 60 дней. Они не взламывали систему. Они использовали систему так, как она была спроектирована для использования.

Появление вторичных субъектов угроз

Вторая хакерская группа, называющая себя TheUSERS007, также заявила о доступе к системам Novo Nordisk в период с 5 по 7 июня. Эта группа нацелилась на данные, связанные с исследованиями в области ИИ. Это говорит о том, что как только происходит крупная утечка, другие участники начинают прощупывать ту же инфраструктуру. Одна уязвимость в конвейере разработки часто указывает на более широкие системные недостатки. Если один разработчик оставляет токен в публичном скрипте, другие разработчики, вероятно, следуют таким же небезопасным шаблонам. Поверхность атаки — это не статичная карта. Это динамичная среда, где одна ошибка провоцирует пристальное внимание со стороны множества противников.

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

Переход от реактивных инструментов к проактивному контролю идентификации

Чтобы минимизировать эти риски, организации должны изменить свой взгляд на доступ разработчиков. Хранилище — это коробка для секретов. Управление идентификацией — это контроль того, кто может открыть коробку и на какой срок. Цель состоит в том, чтобы сократить «срок годности» каждого секрета. Если срок действия токена истекает через четыре часа, утечка в JavaScript-файле — это временная неприятность. Если токен действует год, утечка — это катастрофа.

Централизация управления секретами — необходимый шаг. Каждый идентификатор в среде должен следовать принципу наименьших привилегий. Это означает, что токен GitHub должен иметь доступ только к конкретным репозиториям, необходимым для выполнения задачи. У него не должно быть широких административных полномочий над всей организацией. Автоматическая ротация гарантирует, что учетные данные не переживут свою цель. Эта дисциплина не мешает злоумышленнику найти токен, но она ограничивает то, что он может с ним сделать.

Практические шаги по обеспечению безопасности конвейеров

Организациям следует начать с инвентаризации нечеловеческих идентификаторов. Большинство компаний не знают, сколько API-ключей или сервисных аккаунтов существует в их среде. Вы не можете защитить то, чего не видите. Эта инвентаризация должна включать область действия каждого ключа и дату его последнего использования. Многие организации обнаруживают, что большой процент их активных токенов больше не нужен. Эти «осиротевшие» секреты являются ценными целями для злоумышленников.

Мониторинг машинных идентификаторов так же важен, как и мониторинг входов пользователей. Группы безопасности должны определить базовый уровень нормального поведения для сервисных аккаунтов. Если токен GitHub обычно обращается к трем репозиториям с известного IP-адреса и вдруг начинает клонировать 500 репозиториев из другого региона, система должна выдать предупреждение. Обнаружение должно происходить на уровне идентификации. Исправление программного обеспечения важно, но в эпоху, когда идентификаторы являются основной целью, видимость использования учетных данных — единственный способ поймать скрытого злоумышленника.

Шаги для немедленного снижения рисков

1. Просканируйте все публичные активы на наличие открытых секретов. Используйте автоматизированные инструменты для поиска токенов, API-ключей и учетных данных баз данных в клиентском коде.
2. Внедрите краткосрочные токены. Замените долгоживущие персональные токены доступа на детализированные учетные данные с ограниченным сроком действия везде, где это поддерживает платформа.
3. Проведите аудит разрешений репозитория. Удалите административный доступ у токенов разработчиков. Убедитесь, что ни один токен не обладает правом клонировать всю кодовую базу.
4. Включите сканирование секретов в конвейере CI/CD. Блокируйте любой коммит, содержащий секрет в открытом виде, до того, как он попадет в репозиторий.
5. Мониторьте аномальную активность в репозиториях. Настройте оповещения о массовом клонировании или доступе из необычных мест.

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

Источники: NIST Cybersecurity Framework, MITRE ATT&CK Framework (Technique T1528: Steal Application Access Token), отчетность DataBreaches.net.

Отказ от ответственности: Данная статья носит исключительно информационный и образовательный характер. Она не заменяет профессиональный аудит кибербезопасности или услуги по реагированию на инциденты.