Более 300 репозиториев на GitHub оказались заражены в рамках кампании Glassworm, а четыре канала управления ботнетом уже отключены. Для рынка это не просто еще одна история про вредоносный код: атаки на open source все заметнее смещаются с самих пакетов и библиотек на людей, которые их публикуют, подписывают и поддерживают. Для русскоязычных команд, которые собирают продукт из десятков внешних зависимостей, сигнал довольно прямой: компрометация одного разработчика теперь может аукнуться тысячам downstream-пользователей.
Об операции против Glassworm, как пишет TechCrunch, рассказала CrowdStrike, работавшая вместе с Google и некоммерческой организацией Shadowserver. Целью было нарушить работу ботнета, который киберпреступники использовали для доставки вредоносного ПО и кражи учетных данных у разработчиков open source. По оценке CrowdStrike, эта инфраструктура использовалась против более широкой цепочки поставок open source примерно два года. Ключевой вывод здесь неприятно практичный: злоумышленники больше не ждут, пока уязвимость появится в релизе сама собой. Они идут к тем, кто этот релиз собирает.
Схема Glassworm выглядела не как одна яркая атака, а как конвейер. Преступники публиковали вредоносные расширения в маркетплейсе для разработчиков, покупали рекламные размещения в поиске, чтобы жертва скачивала поддельные инструменты, а также использовали логины и пароли, украденные в прежних взломах. Уже через захваченные аккаунты разработчиков они внедряли вредоносный код в проекты. Такой подход особенно опасен именно для атак на open source: если команда доверяет репозиторию, поддерживаемому знакомым автором, вредоносное обновление может пройти в инфраструктуру почти без сопротивления.
Техническая часть истории тоже примечательна. CrowdStrike сообщила, что злоумышленники управляли зараженными машинами через четыре канала command-and-control, опираясь на Solana, сеть BitTorrent, Google Calendar и виртуальные private server. Набор выглядит как хороший пример того, почему современные supply chain-атаки сложно не только остановить, но и просто заметить. Если командный трафик размазан между блокчейном, пиринговой сетью, обычным облачным сервисом и арендованными серверами, защита на периметре уже не спасает. После отключения этих каналов атакующие потеряли доступ к зараженным устройствам и возможность доставлять новый вредоносный код, но сама операция не отвечает на более неудобный вопрос: сколько уже скомпрометированных сборок успело уйти дальше по цепочке.
Разработчик как новая точка входа
CrowdStrike сформулировала проблему довольно жестко: атакуют уже не только продукты, атакуют тех, кто их пишет. Для злоумышленника рабочая станция разработчика стала активом высокого класса. Доступ к ней может дать токены, SSH-ключи, cookie сессий, доступ к пакетным реестрам, CI/CD и корпоративным GitHub-организациям. Дальше каскад знакомый: вредоносный коммит, обновление зависимости, автоматическая сборка, и вот проблема уже не у одного maintainer, а у всей цепочки клиентов. Именно поэтому атаки на open source перестают быть нишевой темой для security-команд и становятся вопросом общей инженерной гигиены.
Контекст у этой истории довольно плотный. За последние месяцы несколько групп уже целились в разработчиков и open source-проекты, чтобы распространять вредоносные обновления через доверенные каналы. TechCrunch напоминает о недавней кампании Mini Shai-Hulud, в ходе которой были скомпрометированы несколько open source-проектов. По данным издания, как минимум два разработчика OpenAI также пострадали от действий этой группы. В марте, в другой атаке на цепочку поставок, подозреваемый северокорейский хакер захватил популярный инструмент разработки Axios, которым пользуются миллионы разработчиков. Это уже не серия случайных эпизодов, а вполне читаемый тренд: компрометировать maintainers и авторов инструментов иногда выгоднее, чем ломать конечную компанию напрямую.
Любопытно и то, чего в этой истории пока нет. CrowdStrike не раскрыла, на каком именно техническом или юридическом основании была проведена ликвидация инфраструктуры Glassworm. По запросу TechCrunch представитель компании отказался от дополнительных комментариев за пределами опубликованного блога. Для индустрии это важная деталь: частные компании все чаще участвуют в активных операциях против ботнетов, но прозрачность таких действий все еще хромает. С точки зрения бизнеса результат понятен и полезен, с точки зрения правил игры остаются вопросы.
Что делать командам, которые живут на внешних зависимостях
Практический вывод для разработчиков и IT-руководителей довольно прозаичный: защита цепочки поставок больше не сводится к сканированию CVE в пакетах. Нужен контроль над учетными записями разработчиков, обязательная MFA в GitHub и пакетных реестрах, ограничение прав токенов, проверка рекламных переходов к «инструментам для разработчиков» и нормальная дисциплина вокруг рабочих станций. Стоит смотреть не только на код зависимостей, но и на то, кто и как их публикует. Если в компании до сих пор принято скачивать утилиты по первой ссылке из поиска, хранить длинноживущие токены без ротации и не разделять личные и рабочие аккаунты, это уже не вопрос удобства, а вполне конкретная дыра в модели угроз.
История с Glassworm показывает еще одну неприятную вещь: open source сегодня ломают не потому, что он слабый, а потому, что он слишком важен. Чем больше компаний строят продукты на общих библиотеках, инструментах и SDK, тем выше экономический смысл атаки на одного maintainer или одну developer workstation. Следующая большая волна в supply chain, похоже, будет измеряться не числом найденных уязвимостей, а числом доверенных разработчиков, через которых злоумышленники сумеют пройти внутрь.