JetBrains не установила патч для TeamCity: злоумышленники получили доступ к AWS-ключам, резервным копиям и секретам разработчиков
Уязвимый сервер JetBrains стал отправной точкой для атаки на внутреннюю инфраструктуру компании. Через экземпляр TeamCity, связанный с сервисом Cadence, злоумышленники смогли добраться не только до самого приложения, но и до облачных ресурсов, резервных копий и конфиденциальных данных разработчиков.
Инцидент затронул сервис Cadence, интегрированный с PyCharm. Он предназначен для запуска проектов на внешних вычислительных мощностях и выступает связующим звеном между средой разработки, облачной инфраструктурой и сторонними платформами. Скомпромированный сервер был доступен по адресу api.cadence.jetbrains.com.
Для проникновения атакующие использовали критическую уязвимость CVE-2026-63077 в TeamCity. На момент атаки исправление для этой проблемы уже существовало, однако установленный в инфраструктуре JetBrains сервер так и не обновили. В результате публично доступная система сохранила уязвимость, которую смогли применить злоумышленники.
По оценке компании, подозрительная активность продолжалась как минимум с 8 по 24 августа. За этот период атакующие получили доступ к персональным данным пользователей, полной резервной копии Cadence за 2024 год, учётным записям AWS IAM, принадлежавшим сотрудникам JetBrains, а также к хранилищам Amazon S3.
Потенциальные последствия оказались серьёзнее, чем обычная утечка данных с одного сервера. Cadence мог обрабатывать или передавать различные секреты, необходимые для сборки, тестирования и публикации программного обеспечения. В их число входили исходный код, токены GitHub, GitLab и Bitbucket, ключи для npm, PyPI и Maven, данные доступа к контейнерным реестрам, SSH-ключи, ключи подписи и другие учётные данные.
Иными словами, злоумышленники могли получить не только информацию о пользователях сервиса, но и инструменты для дальнейшего перемещения по инфраструктуре. Например, токен репозитория способен открыть доступ к исходному коду, ключ публикации пакета - позволить загрузить вредоносную версию библиотеки, а облачные ключи - предоставить возможность создавать ресурсы, читать данные или изменять настройки AWS.
JetBrains признала, что сервер TeamCity должен был быть защищён обновлением для CVE-2026-63077. Отсутствие патча стало основной причиной компрометации. Этот случай особенно показателен: даже крупный разработчик программных средств не застрахован от базовой ошибки управления обновлениями, когда исправление для критической уязвимости не устанавливается на публичную систему.
Ситуацию усугубляет то, что TeamCity - собственный продукт JetBrains. Компания развивает платформу для автоматизации сборки и доставки программного обеспечения, однако один из её серверов оказался уязвимым именно из-за несвоевременного обновления. Таким образом, недостаток в процессе эксплуатации продукта привёл к атаке на инфраструктуру его разработчика.
Почему CI/CD-системы особенно опасны при взломе
Серверы непрерывной интеграции и доставки обычно обладают широкими полномочиями. Им требуется получать код из репозиториев, запускать сборки, обращаться к облачным сервисам, публиковать пакеты и взаимодействовать с контейнерными платформами. Поэтому компрометация CI/CD-системы часто даёт атакующему больше возможностей, чем взлом обычного веб-сайта.
Даже если на самом сервере нет важных пользовательских файлов, он может хранить переменные окружения, токены автоматизации, временные ключи и конфигурации подключённых сервисов. Злоумышленнику достаточно извлечь один действующий секрет, чтобы продолжить атаку уже через другой компонент инфраструктуры.
Особый риск представляют резервные копии. В них могут содержаться не только записи базы данных, но и настройки приложений, хеши паролей, токены, журналы операций и удалённые с сервера секреты. Поэтому резервная копия должна защищаться не слабее основной системы, а доступ к ней необходимо ограничивать отдельными ролями и ключами.
Облачные учётные данные также требуют минимальных полномочий. Если одному ключу AWS разрешено выполнять слишком много операций, его утечка способна привести к чтению данных из S3, запуску дорогостоящих ресурсов, изменению сетевых правил или удалению информации. Разделение ролей и регулярная замена ключей существенно уменьшают масштаб возможного ущерба.
Что следует сделать пользователям Cadence
Пользователям, которые передавали через Cadence токены, ключи или пароли, следует считать эти данные потенциально скомпрометированными. В первую очередь необходимо отозвать старые секреты и выпустить новые, не дожидаясь завершения расследования.
Нужно заменить ключи доступа к AWS и другим облачным платформам, персональные токены GitHub, GitLab и Bitbucket, пароли к реестрам пакетов и контейнеров, SSH-ключи, сертификаты и ключи подписи. Если один и тот же секрет использовался в нескольких системах, менять его требуется во всех связанных сервисах.
После ротации важно проверить журналы аудита. Особое внимание стоит уделить неизвестным входам, созданию новых пользователей и ключей, изменениям политик IAM, операциям чтения и выгрузки из S3, публикации пакетов и запуску необычных облачных ресурсов.
Компаниям также стоит временно усилить контроль над сборочными процессами. Полезно включить обязательное подтверждение публикаций, ограничить права сервисных аккаунтов, проверить целостность артефактов и убедиться, что в автоматические сборки не подмешаны неизвестные зависимости или скрипты.
Инцидент JetBrains показывает, что безопасность зависит не только от выпуска исправлений, но и от того, насколько быстро они устанавливаются во всей инфраструктуре. Для критичных систем должны действовать автоматическая инвентаризация серверов, контроль версий, приоритетное развёртывание патчей и регулярные проверки внешних сервисов. Один забытый сервер может стать каналом доступа сразу к исходному коду, облаку, резервным копиям и цепочке поставки программного обеспечения.
