GitHub расследует инцидент с внутренними репозиториями после заявления TeamPCP о продаже приватного кода платформы. Изначально речь шла об «около 4 000» репозиториев, позднее GitHub подтвердил компрометацию примерно 3 800 внутренних репозиториев. Причиной назвали устройство сотрудника, на которое попало вредоносное расширение VS Code. Компания изолировала устройство, убрала расширение и запустила реагирование на инцидент.
GitHub сообщил, что сейчас не видит доказательств воздействия на клиентскую информацию, размещённую за пределами внутренних репозиториев: энтерпрайз-аккаунты, организации и репозитории пользователей отдельно упомянуты как зоны, по которым пока нет подтверждённого ущерба. Компания также заявила, что при появлении признаков затрагивания клиентов будет уведомлять их через обычные каналы реагирования.
TeamPCP разместила объявление на форуме Breached и заявила, что получила доступ к «исходному коду GitHub и внутренним организациям». В объявлении фигурировала цена от $50 000, продажа одному покупателю и угроза бесплатной публикации данных, если покупатель не найдётся. Проверять такие заявления нужно осторожно: хакерские объявления часто преувеличивают объём и ценность данных. В этом случае часть фактов совпала с расследованием GitHub: компания подтвердила компрометацию примерно 3 800 внутренних репозиториев, но не подтвердила ущерб для клиентских репозиториев.
Вредоносные расширения для Visual Studio Code стали удобной точкой входа в среды разработчиков. Они устанавливаются в IDE, получают доступ к рабочей директории, окружению, токенам, настройкам Git, npm, PyPI, облачным ключам и локальным файлам. Для атакующих это почти идеальный формат: разработчик сам ставит расширение, а оно работает рядом с исходным кодом и инструментами сборки.
Связь с VS Code особенно опасна для компаний с большим количеством внутренних репозиториев. Один заражённый рабочий компьютер может открыть доступ к приватным репозиториям, если на нём есть активные токены, SSH-ключи, сессии GitHub или доступ к корпоративным организациям. GitHub в этом инциденте описывает именно компрометацию устройства сотрудника, а не массовый взлом инфраструктуры хранения кода.
Риск вредоносных расширений не новый. В последние годы исследователи регулярно находили кампании против VS Code Marketplace и Open VSX Registry: от скрытого сбора токенов до атак через зависимости и поддельные популярные инструменты. Для разработчиков это уже не «плагин для подсветки синтаксиса», а полноценный исполняемый код внутри рабочей среды.
TeamPCP уже связывали с атаками на цепочки поставки разработки: GitHub Actions, npm, PyPI, Docker и OpenVSX. В марте группа фигурировала в истории с Trivy от Aqua Security. Тогда атакующие опубликовали вредоносные версии Trivy, trivy-action и setup-trivy, а полезная нагрузка искала SSH-ключи, файлы AWS, Google Cloud, Azure, Kubernetes-токены, Docker-учётные данные, базы паролей и Terraform state-файлы.
Позже TeamPCP связали с новой волной Mini Shai-Hulud — самораспространяющегося червя для npm и PyPI. JFrog писал, что кампания затронула более 170 npm-пакетов и 2 PyPI-пакета с суммарной недельной загрузкой свыше 200 млн. Нагрузка запускалась в средах разработчиков и CI/CD, крала учётные данные, отправляла их наружу и использовала полученный доступ для публикации новых заражённых пакетов.
StepSecurity разбирала атаку на пакеты TanStack. Там вредоносные версии выходили через легитимный release-пайплайн GitHub Actions, а часть заражённых пакетов получила валидные SLSA Build Level 3 provenance attestations.
Для обычных пользователей GitHub этот инцидент сейчас не означает, что их приватные репозитории утекли. GitHub отдельно говорит, что не видит подтверждённого воздействия на клиентские enterprise, организации и репозитории. Но для компаний это хороший момент проверить собственную защиту среды разработки.
Стоит предпринять такие шаги:
Инвентаризация расширений VS Code. Нужен allowlist-подход: разрешённые расширения, проверенные издатели, контроль версий, запрет установки случайных плагинов на рабочих машинах и dev-контейнерах. Расширение в IDE должно рассматриваться как исполняемый код с доступом к проектам, а не как косметическое дополнение.
Пересмотр токенов и секретов. Персональные токены доступа лучше заменить на короткоживущие и ограниченные по scope токены, где это возможно. GitHub Actions и CI/CD должны получать минимум прав, а секреты — храниться так, чтобы компрометация одного runner не давала доступ к десяткам проектов.
Мониторинг аномалий в репозиториях. Важны неожиданные force-push, массовые изменения тегов, публикация новых версий пакетов, появление странных workflow, добавление внешних Actions, нетипичный доступ к приватным репозиториям, массовое клонирование и обращения с новых устройств.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
