CVE-2026-20230 Cisco Unified Communications Manager SSRF: произвольная запись файлов с переходом в RCE — процесс построения PoC и анализ

Область применения: только локальные полигоны, авторизованные среды воспроизведения, проверка уязвимостей и анализ правил защиты. Не использовать против неавторизованных целей. В статье в основном анализируются цепочка эксплуатации CVE-2026-20230, проверяемые признаки, логика оценки и подходы к защите; здесь не приводятся готовые к копированию и выполнению атакующие запросы, содержимое WebShell или полезные нагрузки для выполнения команд.

1. Общие сведения об уязвимости

CVE-2026-20230 — это уязвимость подделки серверных запросов (SSRF) в Cisco Unified Communications Manager (Unified CM / CUCM) и Cisco Unified Communications Manager Session Management Edition (Unified CM SME). Уязвимость вызвана недостаточной проверкой входных данных в процессе обработки определённых HTTP-запросов: неаутентифицированный злоумышленник может сконструировать запрос, заставляющий уязвимое устройство от его имени обращаться к внутренним интерфейсам или локальным ресурсам.

Воздействие этой уязвимости не ограничивается обычным SSRF-сканированием. Согласно публичному техническому анализу, при определённых версиях и включённых службах SSRF может быть дополнительно объединена в цепочку с возможностью произвольной записи файлов: злоумышленник может записывать контролируемое содержимое в пути операционной системы, а затем, используя каталоги, доступные веб-контейнеру, или механизмы загрузки серверных компонентов, превратить запись файлов в выполнение кода.

Cisco присвоила этой уязвимости оценку 8.6 по CVSS v3.1, вектор:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:N

Хотя оценка CVSS соответствует уровню High, Cisco пометила Security Impact Rating этой уязвимости как Critical. Причина в том, что при успешной эксплуатации можно записывать файлы в операционную систему нижнего уровня и потенциально повысить привилегии до root.

Важно отметить, что ключевым предусловием эксплуатации этой уязвимости является включённая служба WebDialer. По умолчанию WebDialer отключён, поэтому нельзя делать вывод об эксплуатируемости уязвимости, просто обнаружив актив CUCM. Для реальной оценки риска необходимо одновременно подтвердить версию продукта, статус установленных исправлений, состояние службы WebDialer и доступность соответствующих интерфейсов.

2. Почему нельзя судить только по тому, возвращает ли один интерфейс 200?

Эта уязвимость — не обычная веб-уязвимость типа «существует, если при обращении к фиксированному URL возвращается 200». Её цепочка эксплуатации включает как минимум три уровня:

1. Внешне доступные интерфейсы WebDialer или cmplatform.
2. Логика внутренних обращений, на которую может повлиять SSRF.
3. Поведение записи файлов или развёртывания служб, которое может быть дополнительно инициировано внутренними запросами.

Поэтому получение HTTP 200, 302, 401, 404 или 500 при обращении к какому-либо интерфейсу в отдельности не может напрямую доказать наличие или отсутствие уязвимости.

Например, доступность интерфейса WebDialer WSDL лишь означает, что цель раскрыла функции, связанные с WebDialer, но не доказывает, что последующая SSRF обязательно пробьёт фильтрацию. Доступность интерфейса installClusterStatusExecute также лишь указывает на существование соответствующей точки входа и сама по себе не доказывает, что произвольная запись файлов реализована. И наоборот, если на каком-то шаге возвращается аномальный результат, это может быть вызвано версией цели, исправлениями, разрешением hostname, правами на пути, прокси-устройствами или состоянием служб — и не обязательно означает, что всей цепочки уязвимости не существует.

Более надёжная оценка должна использовать комбинацию многоступенчатых доказательств:

1. Подтвердить, что целью является Cisco Unified CM / Unified CM SME.
2. Подтвердить, что служба WebDialer включена.
3. Подтвердить, что можно получить реальный hostname цели или идентификатор внутренней службы.
4. Подтвердить, что точка входа SSRF достижима и существуют признаки исходящих внутренних запросов со стороны сервера.
5. На авторизованном полигоне подтвердить, можно ли получить доказательства контролируемой записи файлов.
6. Оценить, действительно ли уязвимость сработала, на основе журналов сервера, изменений файловой системы, журналов веб-контейнера и данных предупреждений.

Только при одновременном выполнении условий «WebDialer включён + уязвимая версия + подтверждено поведение SSRF + подтверждена контролируемая запись файлов» уязвимость следует считать эксплуатируемой с высокой степенью достоверности.

3. Подход к построению PoC

Ядро текущей публичной цепочки эксплуатации — не сам по себе SSRF, а комбинированное использование SSRF с механизмами Axis/Java Web-служб, записью журналов или логикой обработки дескрипторов развёртывания.

Общий подход можно обобщить следующим образом:

Сбор информации через WebDialer
    ↓
Получение реального hostname цели
    ↓
Запуск SSRF через интерфейсы cmplatform
    ↓
Обращение к внутренним путям управления WebDialer / Axis
    ↓
Запись или развёртывание контролируемого описания службы
    ↓
Формирование новой вызываемой службы или возможности записи файлов
    ↓
Преобразование возможности записи файлов в скрипт, доступный через Web
    ↓
Достижение выполнения команд в определённых условиях

С точки зрения проектирования цепочки hostname — ключевая точка. Некоторая логика фильтрации перехватывает распространённые локальные адреса, такие как 127.0.0.1, localhost, но реальный hostname цели может быть пропущен в последующий процесс запросов. Поэтому PoC сначала извлекает реальное имя хоста из WSDL-информации WebDialer, а затем использует его как префикс внутренних обращений в цепочке SSRF.

Второй ключевой момент — логика, связанная со службами Axis. PoC не загружает файлы напрямую в веб-каталог, а через цепочку обработки внутренних служб заставляет серверные компоненты записывать контролируемое злоумышленником содержимое в определённые пути. По сути, этот процесс представляет собой комбинацию «внутреннего запроса на сервере + поведения компонента по записи конфигурации/журналов + обхода/контроля путей».

Третий ключевой момент — двухэтапная запись. Первый этап обычно используется для создания более стабильной точки входа для записи файлов, а второй этап записывает скрипт выполнения команд в каталог, доступный через Web. Причина в том, что при непосредственной записи полной логики выполнения команд через SSRF за один шаг могут оказать влияние кодировка, длина, структура XML, права на пути и поведение серверного парсинга, тогда как двухэтапный подход позволяет проще разбить сложную полезную нагрузку на части.

В этой статье не приводятся полные эксплуатационные запросы и содержимое WebShell. Для защиты и проверки достаточно понимать следующие ключевые характеристики:

Точка входа внешних запросов: интерфейсы статуса установки cmplatform
Точка входа для сбора информации: интерфейсы WebDialer WSDL / services
Цели внутренней пересылки: пути WebDialer / Axis / AdminService
Ключевое поведение: SSRF, внутренние запросы на стороне сервера, контролируемая запись файлов, размещение файлов, доступных через Web
Конечный риск: произвольная запись файлов, размещение WebShell, выполнение команд, путь повышения привилегий до root

4. Логика получения hostname

В первую очередь PoC необходимо получить реальный hostname цели, а не только IP-адрес или внешнее доменное имя.

Причина в том, что логика фильтрации SSRF не обязательно проверяет только конечную цель подключения — она также может проверять поле hostname, строку URL, ключевые слова локальных адресов и т.д. Распространённые локальные адреса, такие как 127.0.0.1, localhost, могут блокироваться, тогда как реальный hostname устройства в некоторых сценариях рассматривается как допустимое имя узла.