На пентесте Azure-инфраструктуры финтех-клиента в начале 2026 года я нашёл SSRF в кастомном API-прокси за 40 минут: параметр
source_url в webhook-конфигураторе не фильтровал внутренние адреса. Ещё через час - managed identity токен с ролью Contributor через обращение к IMDS на 169.254.169.254. Заказчик был уверен, что allowlist URL на уровне приложения закрывает вектор. Не закрывает.Две CVE с CVSS 10.0, опубликованные в августе 2026 - CVE-2026-69502 в Azure SQL Database и CVE-2026-76193 в Adobe Campaign Classic - подтвердили, что SSRF работает не только через пользовательские мисконфигурации. Обе уязвимости сидели на уровне инфраструктуры, которую контролирует вендор, а не клиент. Никакой allowlist на стороне приложения не помогал - запросы летели изнутри доверенной сети провайдера.
Бизнес-логика атаки: зачем SSRF в облаке опаснее on-premise
На on-premise сервере SSRF позволяет прочитать/etc/passwd через file:// или просканировать порты внутренней сети - импакт ограничен. В облаке тот же примитив открывает доступ к Instance Metadata Service, который отдаёт токены аутентификации managed identity или service account. Один HTTP-запрос к 169.254.169.254 - и атакующий получает JWT-токен, с которым можно рулить облачными ресурсами: читать базы данных, вытаскивать секреты из Key Vault, разворачивать виртуальные машины, скачивать бэкапы из Blob Storage. Подробнее - в нашем обзоре мисконфигурация облака атаки.SSRF (CWE-918) в облаке - не просто «чтение данных». По классификации CWE, последствия Server-Side Request Forgery включают: чтение данных приложения (Confidentiality), выполнение несанкционированного кода (Integrity), обход механизмов защиты доступа (Access Control). Оба разбираемых CVE получили CVSS 10.0 именно потому, что цепочка SSRF → IMDS → privilege escalation превращает сетевой примитив в полную компрометацию облачного окружения. Финальная цель атакующего - монетизация: от продажи доступа на подпольных форумах до развёртывания криптомайнеров или кражи коммерческих данных.
CVE-2026-69502: Azure SQL Database уязвимость с CVSS 10.0
CVSS-вектор и анализ импакта
Согласно NVD, CVE-2026-69502: «Server-side request forgery (SSRF) in Azure SQL Database allows an unauthorized attacker to elevate privileges over a network.» CVSS-вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N - итоговая оценка 10.0 (CRITICAL). CWE-918.Разбор вектора по компонентам:
| Компонент | Значение | Интерпретация |
|---|---|---|
| AV:N | Network | Атака удалённо, через сеть |
| AC:L | Low | Специальных условий не требуется |
| PR:N | None | Аутентификация не нужна |
| UI:N | None | Действия пользователя не требуются |
| S:C | Changed | Уязвимый и импактнутый компоненты - разные |
| C:H / I:H | High | Полная утрата конфиденциальности и целостности |
| A:N | None | Доступность не затронута |
Scope: Changed - самый интересный элемент этой CVE. Уязвимый компонент - внутренний механизм Azure SQL Database, managed-сервис, код которого контролирует Microsoft. Импактнутый компонент - ресурсы Azure, доступные из сетевой позиции этого сервиса: metadata endpoint, Azure Management API, потенциально другие сервисы в подписке клиента. SSRF произошёл на уровне инфраструктуры Microsoft, а не на уровне пользовательской конфигурации. Клиент Azure SQL Database не мог предотвратить эксплуатацию собственными средствами - ни allowlist URL, ни WAF-правило, ни Network Security Group не спасали, потому что уязвимый код сидел внутри платформы.
По данным Microsoft Security Response Center (MSRC), уязвимость затрагивает Azure SQL Database, серьёзность - Critical, импакт - Elevation of Privilege. Поскольку Azure SQL Database - managed-сервис с автоматическим обновлением, Microsoft накатила патч на стороне инфраструктуры без участия клиента.
Предусловия и ограничения
CISA ADP (Vulnrichment) определяет SSVC-решение как Track (мониторить): эксплуатация в дикой природе не зафиксирована (exploitation: none), автоматизация атаки возможна (automatable: yes), технический импакт - total.[Применимо: внешний пентест, облачная инфраструктура Azure]
Техника НЕ работает: после применения патча Microsoft (managed-сервис обновляется автоматически); если между уязвимым компонентом и metadata endpoint были настроены дополнительные сетевые ограничения. Воспроизвести эксплуатацию на пропатченной инфраструктуре невозможно - клиент не контролирует версию сервиса.
CVE-2026-76193: Adobe Campaign Classic уязвимость - от SSRF до RCE
Поверхность атаки ACC и вектор
Adobe Campaign Classic (ACC) - enterprise-платформа для маркетинговых кампаний, которая разворачивается как self-hosted решение или через Adobe Managed Services. ACC обрабатывает входящие данные через несколько серверных компонентов: XML-парсеры конфигураций кампаний, обработчики изображений для email-персонализации, webhook-интеграции, модули импорта данных по URL. Каждый из них принимает URL от пользователя и выполняет серверный запрос - классическая поверхность для SSRF. На пентестах enterprise-SaaS я чаще всего нахожу SSRF-точки именно в обработчиках изображений и импортёрах: они по дизайну должны ходить по внешним URL, а фильтрация внутренних адресов - ну вы понимаете - часто отсутствует.Согласно NVD, CVE-2026-76193: «Adobe Campaign Classic (ACC) is affected by a Server-Side Request Forgery (SSRF) vulnerability that could result in arbitrary code execution in the context of the current user. Exploitation of this issue does not require user interaction. Scope is changed.» CVSS-вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H - 10.0 (CRITICAL). CWE-918.
Ключевое отличие от Azure-сценария - Availability: High (A:H). Эксплуатация не просто крадёт данные: она приводит к выполнению произвольного кода в контексте серверного процесса ACC и может положить сервис целиком. Переход от SSRF к RCE (arbitrary code execution) указывает на то, что SSRF используется для обращения к внутреннему сервису с функцией исполнения кода - доступ к нему ограничен на сетевом уровне, но открыт для запросов от самого ACC. По сути, ACC сам себе открывает дверь.
Предусловия и ограничения
CISA ADP: SSVC-решение Track, exploitation: none, automatable: yes, technical impact: total. EPSS - 0.0062 (percentile 0.4699), ниже медианы. Публичных PoC-эксплойтов не обнаружено.[Применимо: внешний пентест, self-hosted ACC инсталляции]
Техника НЕ работает: ACC обновлён до версии с исправлением; перед ACC развёрнут WAF с валидацией URL-параметров; ACC полностью изолирован в сети без доступа к внутренним сервисам, допускающим выполнение кода. Adobe Managed Services может получить патч раньше self-hosted инсталляций.
Kill chain: SSRF атака на metadata service с маппингом на MITRE ATT&CK
Типичная цепочка privilege escalation SSRF в облаке укладывается в пять шагов:Шаг 1. Exploit Public-Facing Application (T1190, Initial Access). Атакующий находит серверный эндпоинт, принимающий URL для исходящего запроса. Типичные параметры:
callback, image_url, webhook_url, source, redirect_uri, feed. Подтверждение - через OOB-канал (Burp Collaborator, interactsh): если callback пришёл с IP сервера, SSRF подтверждена.Шаг 2. Cloud Instance Metadata API (T1552.005, Credential Access). Через SSRF атакующий обращается к IMDS (169.254.169.254 для Azure и AWS, metadata.google.internal для GCP) и запрашивает токен managed identity. Это точка перегиба: без него SSRF остаётся low-impact информационной утечкой, с ним - полноценный credential theft.
Шаг 3. Cloud Accounts (T1078.004, Privilege Escalation). Украденный токен используется для аутентификации в облачных API. В зависимости от назначенных ролей (Reader, Contributor, Owner) атакующий получает соответствующий доступ.
Шаг 4. Cloud Infrastructure Discovery (T1580, Discovery). Перечисление облачных ресурсов с полученным токеном: виртуальные машины, сети, базы данных, Key Vault, App Service.
Шаг 5. Cloud Storage Object Discovery (T1619, Discovery). Поиск объектов в хранилищах - бэкапы баз данных, конфигурационные файлы, SSL-сертификаты, ключи шифрования.
Сравнение metadata endpoint по облачным провайдерам
Не все облака одинаково уязвимы к SSRF. По данным SSRF Prevention Guide 2026:| Провайдер | Endpoint | Требуемый заголовок | Уровень SSRF-риска |
|---|---|---|---|
| Azure IMDS | 169.254.169.254 | Metadata: true | Высокий (обходится через WireServer 168.63.129.16) |
| Azure WireServer | 168.63.129.16 | Не подтверждено | Требует проверки |
| AWS IMDSv1 | 169.254.169.254 | Не требуется | Критический |
| AWS IMDSv2 | 169.254.169.254 | Требуется PUT для токена | Средний (SSRF обычно только GET) |
| GCP Legacy | metadata.google.internal | Не требуется | Критический |
| GCP Current | metadata.google.internal | Metadata-Flavor: Google | Высокий |
AWS IMDSv1 и GCP Legacy - тут даже заголовков не надо, просто GET-запрос. IMDSv2 ситуацию усложняет (нужен PUT для получения сессионного токена), но не закрывает полностью. Azure WireServer (168.63.129.16) - предположительно не требует заголовков и может возвращать конфигурацию VM, настройки расширений и SAS-URL для storage accounts [все утверждения о поведении WireServer требуют проверки по документации Azure, MSRC не раскрывает технические детали].
Пентест облачных сервисов: эксплуатация SSRF в Azure через IMDS
,
resource. Если SSRF не позволяет управлять заголовками - идём на WireServer (168.63.129.16), который заголовков не требует.Использование токена. Полученный
access_token подставляем в Authorization: Bearer:
Bash:
# Перечисление подписок с украденным токеном
TOKEN="<access_token из ответа IMDS>"
curl -s -H "Authorization: Bearer $TOKEN" \
"https://management.azure.com/subscriptions?\
api-version=2020-01-01" | python3 -m json.tool/subscriptions/{id}/resourceGroups, секреты Key Vault, connection strings к Azure SQL.Когда техника НЕ работает
Managed identity не назначена. IMDS вернёт 400 Bad Request. Проверяем через запрос кhttp://169.254.169.254/metadata/instance?api-version=2021-02-01.NSG блокирует IMDS. Нестандартная конфигурация, но встречается - трафик к 169.254.169.254 запрещён правилом NSG.
Минимальные роли. Managed identity с ролью Reader на пустой ресурсной группе - техническая эксплуатация удалась, практический импакт нулевой. Бывает обидно.
SSRF только URL, без заголовков, WireServer недоступен. Если оба альтернативных endpoint (WireServer и HostGAPlugin) заблокированы - стандартный IMDS отклонит запрос без
Metadata: true.Обход защит при эксплуатации SSRF в облаке
Типовая защита - blacklist внутренних IP (127.0.0.1, 169.254.169.254, 10.0.0.0/8). Проблема: ОС и сетевые библиотеки принимают IP в нескольких форматах. Для обхода blacklist 169.254.169.254 по данным SSRF Prevention Guide 2026:- Десятичный:
http://2852039166(169.254.169.254 как 32-битное число) - Шестнадцатеричный:
http://0xA9FEA9FE - Octal:
http://0251.0376.0251.0376 - IPv6-маппинг:
http://[::ffff:169.254.169.254]
DNS rebinding обходит валидаторы с TOCTOU-уязвимостью: домен с TTL=0 при первом DNS-запросе возвращает легитимный IP (проходит проверку), при втором - 169.254.169.254. Приложение проверяет хост в момент T1, реальный запрос уходит в момент T2 уже на внутренний адрес.
[Применимо: оба сценария - внешний и внутренний пентест]
Ограничение: DNS rebinding не работает, если приложение кэширует DNS-ответы или резолвит адрес один раз и запоминает. Также не работает, если валидатор проверяет финальный resolved IP, а не hostname.
Детектирование SSRF-цепочки в облачной инфраструктуре
Со стороны blue team - три ключевых сигнала, на которые стоит ставить алерты.Исходящие запросы к metadata endpoint. Мониторинг обращений к 169.254.169.254 и 168.63.129.16 от application-tier серверов. В Azure - через Network Watcher flow logs и Microsoft Defender for Cloud. Любое обращение web-сервера к metadata endpoint - алерт: нормальное приложение не ходит за токенами managed identity через HTTP-запросы к IMDS напрямую (для этого есть SDK).
Аномальное использование managed identity. Если токен managed identity запрашивается с нехарактерной частотой или используется для доступа к ресурсам за пределами штатного скоупа приложения - сигнал. Azure AD Sign-in logs и Azure Monitor фиксируют эти операции.
Egress-трафик к внутренним диапазонам. Запросы от web-серверов к 10.0.0.0/8, 172.16.0.0/12, 127.0.0.0/8 - повод для алерта.
Похожие баги всплывают регулярно. CVE-2026-33626 в LMDeploy (CVSS 7.5, CWE-918, S:U/I:N - в отличие от главных CVE статьи Scope здесь Unchanged, а Integrity None, то есть SSRF ведёт только к утечке данных, не к RCE) - функция
load_image() принимала произвольные URL без валидации, открывая доступ к metadata и внутренним сетям. EPSS - 0.4525 (Top 5%), CISA ADP отмечает статус exploitation: poc. Аналогичная CVE-2026-64849 в MLflow (CVSS 9.3, SSRF через webhook-эндпоинт с redirect-based обходом валидации) - тот же паттерн: неаутентифицированный доступ к metadata-сервисам через серверный запрос. Детали эксплуатации в дикой природе и конкретная атрибуция требуют проверки по актуальным данным CISA KEV.Обе CVE из этой статьи - CVE-2026-69502 и CVE-2026-76193 - получили максимальный CVSS 10.0 и оценку automatable: yes от CISA ADP. Сейчас эксплуатация в дикой природе для них не зафиксирована, но при наличии автоматизируемого вектора и историческом примере MLflow (от disclosure до массовой эксплуатации - часы) времени на раскачку нет.
Две инфраструктурные SSRF с CVSS 10.0 за один месяц в managed-сервисах Azure и Adobe - это не совпадение, это системная проблема. Облачные провайдеры годами строили нарратив разделённой ответственности: «мы закрываем инфраструктуру, вы - приложение». CVE-2026-69502 прямо ломает эту модель: уязвимость в managed service, которую клиент не контролирует и не видит, даёт неаутентифицированному атакующему путь к escalation over a network (NVD). Вероятный механизм - обращение к metadata endpoint, хотя MSRC не раскрывает технические детали эксплуатации. Никакой hardening на стороне клиента это не предотвратит.
На практике я вижу, что большинство blue team-команд мониторят входящий трафик, но почти никто не отслеживает исходящие запросы application-серверов к 169.254.169.254. А это первый детектируемый шаг в цепочке T1190 → T1552.005 → T1078.004. Если в flow logs нет алерта на обращение к metadata endpoint от web-tier - цепочка пройдёт незамеченной.
Думаю, в ближайший год рост SSRF-атак сместится на AI/ML-инфраструктуру: vision-language модели, загружающие изображения по URL без валидации, - это SSRF by design, и они работают в облаке с полным доступом к IMDS. Формула на бумаге понятна, но SSRF-цепочка от IMDS до захвата подписки по-настоящему ощущается только когда сам прогоняешь шаги руками. Хочется руки в крови - на HackerLab есть лаба, где SSRF-цепочку до облачного privilege escalation нужно собрать end-to-end.
