На пентесте телеком-оператора в прошлом году я убил два дня на периметр - WAF, минимальная поверхность, стандартная история. Точка входа нашлась там, где не ждали: Jira Service Management, выставленная наружу для подрядчиков. Self-registration на Service Desk, аккаунт за три минуты, затем SSRF через batch endpoint Mobile Plugin. Через сорок минут после регистрации я уже читал метаданные облачного инстанса и токены IAM-роли. SOC увидел алерт через шесть часов. ITSM-платформы - Jira SM, ServiceNow, Freshservice - живут в привилегированной зоне доверия корпоративной сети, хранят данные об активах, учётках и инцидентах, интегрированы со Slack, GitHub, PagerDuty и AD. При этом в scope пентеста их включают в последнюю очередь - если включают вообще.
Бизнес-логика атаки: зачем ломать тикетинг
ITSM-платформа - не хелпдеск, а реестр всей IT-инфраструктуры и точка управления конфигурациями. Для атакующего ценность определяется тремя вещами.CMDB как карта инфраструктуры. В тикетинговой системе лежат списки серверов, сетевых сегментов, приложений и их владельцев - это Data from Information Repositories (T1213, Collection). Одна SSRF с доступом к внутренним API - и атакующий получает карту всей инфры без единого сканирования. Зачем шуметь nmap'ом, когда всё уже аккуратно разложено по полочкам?
Credential harvesting из тикетов. Сотрудники прикладывают конфиги с паролями, скриншоты, ссылки на внутренние ресурсы - Credentials In Files (T1552.001, Credential Access). ServiceNow Knowledge Base, Confluence рядом с Jira - хранилище секретов, к которым достаточно получить чтение.
Lateral movement через интеграции. Интеграции с GitHub, Slack, PagerDuty, Jenkins используют OAuth-токены и webhook-секреты - Trusted Relationship (T1199, Initial Access). Компрометация ITSM даёт доступ ко всем подключённым системам через доверенные связи - без необходимости ломать каждую по отдельности.
С точки зрения kill chain, атаки через тикетинг системы работают и на фазе initial access - Exploit Public-Facing Application (T1190) - когда Jira или ServiceNow торчат наружу для подрядчиков, - и при пост-эксплуатации во внутренней сети, когда атакующий ищет пути к domain admin через доверенные связи ITSM-платформы.
SSRF атаки через Mobile Plugin for Jira (CVE-2022-26135)
[Применимо: внешний пентест, Jira Server / Data Center 8.0.0–8.22.3 и Jira Service Management Server / Data Center 4.0.0–4.22.3 с Mobile Plugin]
CVE-2022-26135 - server-side request forgery в Mobile Plugin for Jira Data Center и Server, обнаруженная ребятами из Assetnote. Уязвимость затрагивает и Jira Service Management Server/Data Center, поскольку Mobile Plugin ставится в комплекте. CVSS 6.5 (MEDIUM), вектор CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. Классификация CWE-918 (Server-Side Request Forgery). CISA SSVC-решение - Track, подтверждённой массовой эксплуатации нет, CVE отсутствует в CISA KEV.
Затронуты Atlassian Jira Server и Data Center версий 8.0.0 ≤ v < 8.13.22, 8.14.0 ≤ v < 8.20.10, 8.21.0 ≤ v < 8.22.4, а также Jira Service Management Server и Data Center версий 4.0.0 ≤ v < 4.13.22, 4.14.0 ≤ v < 4.20.10, 4.21.0 ≤ v < 4.22.4. По CISA SSVC - technical impact partial, автоматизация не подтверждена, но EPSS 0.84 указывает на высокую модельную вероятность эксплуатации (EPSS - вероятностная оценка на основе признаков уязвимости и публичной активности, а не индикатор подтверждённых атак in-the-wild).
Механика уязвимости и цепочка эксплуатации
Корень проблемы - классBatchServiceImpl.java в Mobile Plugin. Endpoint /rest/ принимает JSON-массив запросов и выполняет их на стороне сервера. По данным Assetnote, URL формируется через конкатенацию URI.create(this.jiraBaseUrls.baseUrl() + path). Атакующий передаёт в location значение @targethost.com, и получается URL https://jira-host.com@targethost.com. HTTP-клиент OkHttpClient интерпретирует часть до @ как userinfo и отправляет запрос на targethost.com. Изящно и просто.Возможности SSRF (по данным Assetnote): отправка до 5 запросов одновременно через batch API, произвольный HTTP-метод, произвольные заголовки и тело запроса. Ограничения: протокол не контролируется напрямую (нужен HTTP-редирект для смены HTTPS на HTTP), Host-заголовок может не поддаваться подмене.
Критический нюанс - SSRF требует аутентификации. Но Jira Service Desk (часто установленный рядом с Jira Core) поддерживает self-registration через
/servicedesk/customer/user/signup. Учётная запись Service Desk даёт доступ к REST API Jira Core - Valid Accounts (T1078, Initial Access). По документам - аккаунт Service Desk ограничен. На практике - его хватает для SSRF.Полная цепочка атаки:
- Recon: обнаружение Jira на периметре, определение версии через
/rest/api/2/serverInfo - Self-registration: создание аккаунта через Service Desk signup (T1078)
- SSRF: запрос на batch endpoint с payload
@internal-host - Pivot: чтение облачных метаданных (
169.254.169.254), обращение к внутренним API - Post-exploitation: извлечение токенов, данных CMDB, пивот во внутренние сервисы
HTTP:
POST /rest/nativemobile/1.0/batch HTTP/1.1
Host: jira.target.com
Content-Type: application/json
Cookie: [session_cookie]
{"requests":[{"method":"GET",
"location":"@169.254.169.254/latest/meta-data/iam/security-credentials/"}]}
# ВНИМАНИЕ: это псевдокод, НЕ рабочий payload.
# Реальный формат полей batch-запроса отличается (см. имена полей в advisory).
# Точный формат и PoC: https://blog.assetnote.io/2022/06/09/atlassian-jira-ssrf/assetnote.io/resources/research). Существование отдельного публичного PoC-репозитория требует верификации перед использованием.Когда техника НЕ работает:
- Jira Cloud - другая архитектура, Mobile Plugin не установлен как on-prem-компонент
- Пропатченные версии (8.13.22+, 8.20.10+, 8.22.4+)
- Self-registration отключена и нет валидных учётных данных
- Сетевая сегментация: SSRF бесполезна, если Jira изолирована от чувствительных сервисов
- WAF с правилами на SSRF-паттерны в JSON body (встречается редко, но бывает)
SSTI уязвимость ServiceNow и Freshservice: шаблонизаторы как точка входа
[Применимо: внутренний пентест, on-premise инстансы с кастомизированными шаблонами]
ITSM-платформы используют шаблонизаторы для рендеринга email-уведомлений, порталов самообслуживания и дашбордов. Server-side template injection в helpdesk-шаблонизаторах - вектор, который русскоязычные источники не покрывают вообще, хотя на практике он встречается регулярно.
Freshservice работает с Liquid-подобными шаблонами для кастомизации email-уведомлений и портала. На одном из проектов я обнаружил, что поле "Тема обращения" рендерилось через шаблонизатор без экранирования: payload
{{7*7}} в теме тикета возвращал 49 в email-уведомлении оператору - классический маркер SSTI. Liquid имеет песочницу, ограничивающую набор доступных фильтров и тегов, так что полноценное RCE через чистый Liquid маловероятно без дополнительных примитивов. Но чтение конфигурации и переменных окружения - вполне реалистичный сценарий.ServiceNow использует Jelly (Apache Jelly) для серверного рендеринга UI-компонентов и Glide-скрипты на JavaScript (T1059.007, Execution) для бизнес-логики. Кастомные workflow-скрипты и Scripted REST API - основная поверхность для code injection. На нескольких проектах я эксплуатировал SSRF через кастомные workflow-скрипты ServiceNow, где пользовательский ввод из тикета попадал в серверный скрипт без санитизации. Инъекция в Glide-контекст может дать выполнение произвольного серверного кода, но для этого ввод должен попасть в
GlideRecord или GlideAjax запрос.Ограничения SSTI в ITSM:
- Атака требует, чтобы пользовательский ввод рендерился в шаблонном контексте - зависит от кастомизации конкретного инстанса
- SaaS-версии (облако) обычно строже изолируют шаблоны, чем on-premise
- ServiceNow ACL-политики ограничивают доступ к API доставки payload
- Тестирование SSTI генерирует email-уведомления - без согласования с заказчиком легко спалиться (и испортить отношения)
Злоупотребление webhook интеграциями: lateral movement через helpdesk
[Применимо: внутренний пентест, post-exploitation после получения admin-доступа к ITSM]Эксплуатация ITSM интеграций - пожалуй, самый недооценённый вектор. Каждая интеграция - trust boundary, которую никто не моделирует в threat model. Я на это натыкаюсь раз за разом.
Jira SM -> GitHub/Bitbucket. Webhook-уведомления при создании тикетов передают данные в репозитории. Обратная интеграция использует OAuth-токены с правами на чтение и запись. Компрометация Jira - доступ к исходному коду. По данным из интеграционного обзора Exalate, типичная связка Jira-ServiceNow синхронизирует поля тикетов, комментарии, вложения и статусы бидирекционально. Каждый из этих каналов - потенциальный вектор для инъекции данных или перехвата.
ServiceNow -> Slack/Teams. Интеграции для нотификаций используют bot-токены с широкими правами. Через эти токены можно читать каналы, отправлять сообщения от имени бота, собирать данные из чатов - Web Protocols (T1071.001, Command and Control).
Freshservice -> PagerDuty/OpsGenie. Webhook-секреты хранятся в конфигурации интеграции. При доступе к админ-панели эти секреты извлекаются и используются для манипуляции инцидентным процессом.
В red team-проектах OAuth-токены интеграций нередко хранятся в открытом виде в конфигурации ITSM-платформы. Получив административный доступ - например, через privilege escalation - например, CVE-2026-9614 (Improper Access Control в Ivanti Neurons for ITSM, CVSS 8.8 HIGH, CWE-284; технических деталей и публичных PoC нет, SSVC Exploitation=none, EPSS 0.004 - приведён исключительно как иллюстрация класса privilege escalation, а не работающий вектор) - атакующий потенциально извлекает токены всех подключённых систем (при наличии работающего эксплойта для конкретной уязвимости).
Webhook'и работают как двунаправленный вектор. Если атакующий контролирует целевой URL - через SSRF или административный доступ - открываются три пути: перехват данных из тикетов путём перенаправления webhook на контролируемый сервер, инъекция событий для триггера автоматизаций и создания ложных тикетов, credential harvesting из webhook-данных, которые содержат внутренние идентификаторы и иногда токены.
SSRF + pivot через интеграции по-настоящему ощущается, когда прогоняешь сценарий руками. Готовый стенд для отработки SSRF-примитивов есть на HackerLab.pro (https://hackerlab.pro) - web-задачи строятся вокруг аналогичной механики с batch-эндпоинтами и контролем URL.
Пентест ITSM платформ: fingerprinting и практика
Требования к окружению
- ОС: любая с поддержкой Burp Suite Pro (Windows/macOS/(GNU/Linux))
- RAM: минимум 8 ГБ (Burp Suite + браузер + nuclei), рекомендуется 16 ГБ при параллельной работе с несколькими инстансами
- Инструменты: Burp Suite Pro (2024.x+), nuclei (ProjectDiscovery, активно поддерживается, обновления еженедельно), curl
- Сеть: доступ к целевому ITSM-инстансу - внешний или через VPN для внутреннего пентеста
- Дополнительно: кастомные nuclei-шаблоны под CVE конкретных ITSM-платформ
Шаг 1: Определение платформы и версии
Для Jira - endpoint/rest/api/2/serverInfo возвращает версию, тип деплоя и build number. Без аутентификации: заголовок X-ASEN в ответах, паттерны в HTML страницы логина. ServiceNow - endpoint stats.do (если не закрыт ACL), паттерн cookies glide_session_store, версия в HTML-комментариях. Freshservice определяется по HTTP-заголовкам ответа, паттернам URL (/support/tickets/), мета-тегам.Шаг 2: Проверка self-registration
Для Jira: POST на/servicedesk/customer/user/signup. Наличие endpoint не гарантирует включённую регистрацию - нужно отправить реальный запрос (по данным Assetnote). Для ServiceNow: проверить /self_registration.do.Шаг 3: Сканирование известных CVE
Bash:
nuclei -u https://jira.target.com \
-t cves/2022/CVE-2022-26135.yaml \
-H "Cookie: session=xxx" -silent{{7*7}} в полях "тема", "описание", кастомных полях. Проверить рендеринг в email-уведомлениях и на портале. Согласовать с заказчиком заранее - тестирование генерирует реальные нотификации.Шаг 4: Аудит интеграций
При наличии административного доступа (или после privilege escalation): извлечь OAuth-токены, webhook-URL и API-ключи из раздела интеграций. Проверить права каждого токена - часто они избыточны. На практике я ни разу не видел, чтобы кто-то ревьюил права OAuth-токенов после первоначальной настройки.Сравнение векторов атак по платформам
| Вектор | Jira SM | ServiceNow | Freshservice | Предусловия | Ограничения |
|---|---|---|---|---|---|
| SSRF через плагины | CVE-2022-26135, EPSS Top 1% | Кастомные workflow-скрипты | Нет публичных CVE | Low-priv аутентификация | Cloud-версии не затронуты |
| SSTI в шаблонах | Ограниченный вектор (требует кастомизации, нет публичных CVE) | Jelly + Glide-скрипты | Liquid | Ввод в шаблонном контексте | Зависит от кастомизации |
| Privilege escalation | Плагинная архитектура | ACL bypass | Ролевая модель | Аутентификация | Патчи закрывают быстро |
| OAuth/webhook abuse | GitHub, Bitbucket, Slack | Slack, Teams, CMDB-sync | PagerDuty, Slack | Admin или priv esc | Ротация токенов снижает окно |
Безопасность корпоративных helpdesk систем: детектирование и защита
Чеклист для SOC и инфраструктурной команды - готов для передачи в отчёт:ITSM-платформы - слепое пятно корпоративной безопасности. На десятках пентестов scope включал "веб-приложения компании", и Jira или ServiceNow крайне редко попадали туда по умолчанию. Их добавляли только после моего вопроса. При этом именно через ITSM я получал initial access быстрее, чем через основное приложение - ITSM стоит за WAF реже, патчится позже, живёт по принципу "работает - не трогай".
Проблема глубже конкретных CVE. Jira, ServiceNow, Freshservice спроектированы как платформы интеграции - каждый webhook, каждый OAuth-токен, каждая связка со Slack или GitHub создаёт trust boundary, которую никто не включает в threat model. Команды защиты закрывают периметр и эндпоинты, а ITSM живёт в зоне "наш внутренний инструмент". С EPSS 0.84 для CVE-2022-26135 и публичным PoC от Assetnote модельная вероятность эксплуатации высока, хотя EPSS отражает вероятностную оценку, а не факт наблюдаемых атак - подтверждённой массовой эксплуатации в CISA KEV пока нет.
Мой прогноз: в ближайший год мы увидим целевые кампании, где ITSM-интеграции станут основным вектором lateral movement вместо классического kerberoasting. Supply chain через тикетинг проще, тише и не требует привилегий в домене. Если хочешь повторить SSRF-цепочку в контролируемой инфре - web-задачи на HackerLab.pro (https://hackerlab.pro) строятся вокруг аналогичных SSRF-примитивов.
Последнее редактирование модератором:
