Архив метки: CICD

Про уязвимость Remote Code Execution - TeamCity (CVE-2026-63077)

Добавить комментарий

Про уязвимость Remote Code Execution - TeamCity (CVE-2026-63077)

Про уязвимость Remote Code Execution - TeamCity (CVE-2026-63077). TeamCity - проприетарное решение компании JetBrains, предназначенное для автоматизации сборки, тестирования и развёртывания программного обеспечения. TeamCity использует центральный сервер для координации сборок и отдельные агенты сборки (build agents) для их выполнения. Агент может взаимодействовать с сервером через протокол опроса агентов: он регистрируется, запрашивает у сервера следующую команду и сообщает, была ли эта команда выполнена успешно или завершилась ошибкой. Уязвимость позволяет неаутентифицированному удалённому злоумышленнику, имеющему доступ к on-premises инсталляции TeamCity Server по HTTP(S), выполнить произвольные команды операционной системы с привилегиями процесса TeamCity Server посредством протокола опроса агентов (agent polling protocol). Уязвимость вызвана небезопасной десериализацией XML-данных (CWE-502). В зависимости от привилегий, предоставленных процессу TeamCity Server, успешная эксплуатация уязвимости может привести к раскрытию данных TeamCity, конфигураций и сохранённых учётных данных, изменению состояния сервера, а также потенциальной компрометации целостности артефактов сборки и CI/CD-конвейеров.

⚙️ Сообщение об этой критической уязвимости было опубликовано в блоге компании JetBrains 27 июля. Уязвимость затрагивает все версии TeamCity On-Premises. Для устранения уязвимости необходимо обновиться до версии 2025.11.7 или 2026.1.3. В качестве компенсирующей меры можно установить плагин для TeamCity 2017.1 и более поздних версий, блокирующий эксплуатацию уязвимости. Для TeamCity 2017.1-2018.1 после установки плагина необходимо перезапустить сервер. Начиная с TeamCity 2018.2, плагин можно активировать без перезапуска сервера TeamCity. Также в качестве долгосрочной меры защиты серверов TeamCity вендор рекомендует ограничить сетевой доступ к странице входа в TeamCity и REST API доверенными сетями. Рекомендуется запускать сервер TeamCity от имени учётной записи операционной системы с минимально необходимым набором привилегий. Серверы TeamCity должны размещаться на выделенных хостах отдельно от агентов сборки, как описано в документации.

👾 Уязвимость была добавлена в CISA KEV 5 августа. Сообщение об эксплуатации уязвимости в реальных атаках было опубликовано в блоге компании JetBrains 7 августа. Вендор рекомендовал проверить журналы TeamCity на наличие сообщений com.thoughtworks.xstream.converters.ConversionException, которые могут указывать на успешную эксплуатацию уязвимости и необходимость проведения дополнительного расследования. После обновления сервера или установки блокирующего плагина можно проверять журналы на com.thoughtworks.xstream.security.ForbiddenClassException - это сообщение свидетельствует о блокировке попытки эксплуатации. Также на попытки эксплуатации могут указывать неавторизованные агенты сборки, особенно с именами, начинающимися на scan.

🛠 Технический разбор уязвимости и ссылка на публичный эксплойт были опубликованы 7 августа в блоге компании Rapid7. С 28 августа доступен Metasploit-модуль для упрощённой эксплуатации уязвимости.

🌐 По данным JetBrains, TeamCity используют более 30 000 организаций по всему миру из государственного, технологического, финансового, медицинского и других секторов, включая некоторые компании из Fortune 500. На 30 июля Censys детектировали около 4 500 инсталляций TeamCity, доступных из Интернет. Из них 450 использовали версии 2025.11.7 или 2026.1.3. Большинство остальных работали на более ранних версиях или не раскрывали информацию о версии.

Посмотрел, какие кейсы победителей премии Pentest award 2026 от Awillix были непосредственно связаны с уязвимостями

Добавить комментарий

Посмотрел, какие кейсы победителей премии Pentest award 2026 от Awillix были непосредственно связаны с уязвимостями

Посмотрел, какие кейсы победителей премии Pentest award 2026 от Awillix были непосредственно связаны с уязвимостями. Подробности, как обычно, будут в осеннем спецвыпуске журнала "Хакер". Но общее впечатление можно составить и по краткому описанию кейсов в Хабр-статье с итогами церемонии награждения.

🔻 L3G5, победивший в номинации "AI", обнаружил схожие уязвимости в архитектуре ИИ-агентов двух крупных российских компаний, которые позволяли агентам выполнять привилегированные действия. L3G5 удалось показать, что эксплуатация этих уязвимостей в одном случае могла привести к утечке пользовательских запросов на адрес злоумышленника при анализе отравленного документа, а во втором - к раскрытию исходного кода всей агентской системы и получению доступа на запись в S3-хранилище с диалогами пользователей компании.

🔻 Хайдар Кабибо, победивший в номинации "Out of Scope", обнаружил уязвимость PhantomRPC в архитектуре Windows RPC (Remote Procedure Call), которая позволяет локально повышать привилегии до уровня SYSTEM. "Поскольку проблема связана с архитектурной уязвимостью, количество потенциальных векторов атаки фактически неограничено: любой новый процесс или служба, зависящие от RPC, могут ввести дополнительный путь повышения привилегий". Занимательно, что в Microsoft решили не заводить CVE-идентификатор для этой уязвимости. 🤷‍♂️

🔻 Денис Горюшев, победивший в категории "Девайс", обнаружил серию уязвимостей в Bluetooth-стеке некоторого embedded-устройства крупного китайского вендора. Уязвимости находятся в процессе ответственного раскрытия.

🔻 Владимир Кононович (DrMefistO), занявший второе место в категории "Девайс", продемонстрировал возможность загрузить собственную прошивку на автомобильные сигнализации (иммобилайзеры).

🔻 Иван Глинкин, занявший третье место в категории "Девайс", продемонстрировал возможность частичного восстановления данных из криптографических USB-накопителей после заявленного производителем полного сброса устройств.

🔻 Алексей Соловьев и Никита Свешников, победившие в категории "Системный взлом (Web & Logic)", обнаружили скрытые уязвимости в Си-компонентах языка PHP. В качестве последствий упоминают SQL-инъекции и каскадную десинхронизацию данных.

🔻 Влад Дриев и Олег Лабынцев, победившие в категории "Kill Chain", продемонстрировали цепочку от total black-box до компрометации двух доменов AD и ряда целевых сервисов вне доменной инфраструктуры. Георгий Кумуржи и Даниил Мамонтов, занявшие второе место в этой категории, получили доступ из Интернета к ЛВС организации, закрепились в инфраструктуре и реализовали ряд недопустимых событий, однако из описания непонятно, о каких именно событиях идёт речь. Cotsom, занявший третье место, продемонстрировал полную цепочку компрометации кластера Kubernetes: от первоначального проникновения через внешний периметр и захвата корпоративного кластера ClearML до реализации двух независимых векторов атаки на production-инфраструктуру. Упоминаются компрометация CSI-провайдера, злоупотребление механизмами GitLab CI/CD, а также обход политик Kyverno, позволивший развернуть привилегированный pod и получить административный контроль над кластером.

К сожалению, в статье с итогами вообще нет CVE/БДУ-идентификаторов. Если для уязвимостей, находящихся в процессе раскрытия (ну или отклонённых вендором), это понятно, то идентификаторы публично известных уязвимостей можно было бы и упоминать - для лучшего понимания кейсов и приоритизации устранения таких уязвимостей в инфраструктурах организаций. 😉

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security

Добавить комментарий

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security

Почитал, что там пишут про вторую серию инцидента с Trivy от Aqua Security. А там мощный движ! 🔥🙂 Вообще у меня всегда было весьма скептическое отношение к Trivy. В первую очередь из-за качества детектирования уязвимостей. Каждый раз, когда я пытался использовать его для анализа докер-образов, я наталкивался на какие-то жуткие фолз-позитивы. Причём логику детектирования уязвимостей было отследить весьма непросто. Поэтому я Trivy использовал только в крайних случаях. Если образ можно было просканировать, детектируя чётко по бюллетеням безопасности через Vulners API, - делал так. Если нельзя из-за того, что образ был на основе какого-то дистрибутива, который Vulners на тот момент не поддерживал (например Alpine), то вынужденно использовал Trivy. Лучше, чем ничего. И тем более Trivy же БЕСПЛАТНЫЙ! 🙂 И если не задумываться о качестве детектирования, то бесплатный сканер - это ведь очевидный и лучший выбор, так ведь? 😅 Правда, я Trivy не пользовался уже года 3-4. Возможно, что с детектированием уязвимостей ситуация у них стала получше. Но вот с собственной безопасностью похоже стало хуже. Иначе как объяснить, что вместо бесплатного сканера с официального репозитория Trivy на GitHub распространяется малварь (и это уже во второй раз за два месяца!). 😱

В конце прошлой недели, 20 марта, исследователь безопасности Paul McCarty сообщил о крупной атаке на цепочку поставок, нацеленной на Trivy.

"Внимание! Trivy версии 0.69.4 скомпрометирована ⚠️ Контейнерные образы и GitHub-релизы версии 0.69.4 являются вредоносными, поэтому если вы используете Trivy в CI, стоит срочно обратить на это внимание. К счастью, версия через Homebrew не была скомпрометирована, как я сообщал ранее. Вредоносная нагрузка представляет собой бинарный файл, и мы пока не провели его анализ, но обновим информацию, как только узнаем больше. Огромное спасибо команде, которая оперативно отреагировала сегодня - вы спасли ОЧЕНЬ много людей от крайне неприятного дня."

Подробности по малвари на opensourcemalware.

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

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

Исследователи из Socket и Wiz в выходные установили подробности атаки. Атака затронула несколько компонентов проекта Trivy: основной сканер, GitHub Action trivy-action и GitHub Action setup-trivy. Злоумышленники принудительно обновили 75 из 76 тегов trivy-action до вредоносных версий, что означает: любой, кто использовал Trivy в своем пайплайне разработки, запускал инфостилер-вредонос при обращении к сканеру.

Исследователи также обнаружили, что TeamPCP расширила свои операции, начав заражать экосистему npm с помощью ранее неизвестного червя под названием CanisterWorm, используя похищенные publish-токены из первоначального взлома Trivy.

В воскресенье Socket зафиксировали дополнительные вредоносные образы, опубликованные в Docker Hub, а Paul McCarty отметил высокий импакт атаки: "44 внутренних репозитория были взломаны, переименованы и сделаны публичными - включая исходный код Tracee, внутренние форки Trivy, CI/CD-пайплайны, Kubernetes-операторы и базы знаний команд (team knowledge bases)". Socket отмечают, что, хотя полный масштаб доступа остаётся неясным, наличие этих репозиториев указывает на более глубокий уровень контроля во время компрометации.

Charles Carmakal, директор Mandiant Consulting, на мероприятии Google заявил:

"Нам известно о более чем 1 000 затронутых SaaS-средах, которые прямо сейчас активно сталкиваются с этим конкретным злоумышленником. Количество этих жертв, вероятно, вырастет ещё на 500, ещё на 1 000, возможно, ещё на 10 000. И мы знаем, что эти акторы сейчас сотрудничают с рядом других групп".

В общем, излишнее доверие к сторонним бесплатным компонентам и излишняя автоматизация вышли компаниям боком. Снова. 😏🍿