Простая XSS в OWA, которую годами не замечали, уже активно используют для компрометации почтовых сессий в корпоративных сетях. https://seberd.ru/25284
Механизм уязвимости строится на отсутствии санитизации пользовательского ввода при рендеринге HTML-контента писем в Outlook Web Access. Атакующий формирует специальное сообщение, которое при открытии в браузере жертвы выполняет JavaScript в контексте домена OWA. Скрипт получает доступ к кукам сессии, содержимому писем и элементам интерфейса почтового клиента.
Сценарий атаки выглядит так:
- Отправка письма с вредоносной полезной нагрузкой — почему: вектор доставки не требует аутентификации и обходит спам-фильтры за счёт легитимного формата MIME
- Открытие письма жертвой в OWA — почему: уязвимость триггерится только при рендеринге в веб-интерфейсе, десктопный Outlook не затронут
- Выполнение JavaScript в браузере — почему: отсутствие Content Security Policy и недостаточная экранировка позволяют коду исполниться в доверенном контексте
- Кража сессионных данных или манипуляция интерфейсом — почему: атакующий получает те же права, что и аутентифицированный пользователь
Exchange Online защищён архитектурно — там рендеринг сообщений происходит в изолированном окружении с принудительной санитизацией. On-prem версии 2016, 2019 и Subscription Edition обрабатывают HTML напрямую в процессе OWA, что и создаёт поверхность атаки.
Почему mitigation через IIS Rewrite требует осторожности
Временное решение от Microsoft опирается на правила URL Rewrite для блокировки подозрительных паттернов в запросах к OWA. Администратор добавляет правила в web.config, которые отфильтровывают специфичные последовательности в параметрах.
На практике это создаёт три сложности:
Правила могут конфликтовать с легитимными сценариями рендеринга — сложные письма с вложенными таблицами или кастомными стилями иногда содержат последовательности, попадающие под фильтр. Результат: пользователь видит обрезанный контент или ошибку загрузки интерфейса.
Mitigation требует ручного применения в сегментированных сетях — Exchange Emergency Mitigation Service не работает в air-gapped средах. Администратору приходится самостоятельно переносить правила, тестировать их и отслеживать обновления.
Отсутствует централизованный мониторинг срабатываний — IIS не логирует отклонённые запросы по Rewrite-правилам по умолчанию. Без дополнительной настройки вы не увидите, пытается ли кто-то эксплуатировать уязвимость в вашей среде.
Я проверял эти правила на тестовом стенде с Exchange 2019 CU14. При стандартном наборе писем из корпоративной рассылки ложных срабатываний не было. Но как только добавил письмо с HTML-формой и inline-скриптами для аналитики — OWA начал возвращать 404 на отдельные ресурсы. Пришлось исключать конкретные пути из фильтрации.
Неизвестно точно, насколько устойчивы эти правила к обфускации полезной нагрузки. Атакующие редко используют прямые сигнатуры — чаще кодируют, разбивают на части или динамически генерируют контент.
Где искать следы эксплуатации в логах
Поиск компрометации начинается с анализа доступа к OWA. Смотрите не только на успешные аутентификации, но и на аномалии в поведении сессии.
| Признак | Где смотреть | Что означает |
|---|---|---|
| Множественные запросы к /owa/auth с разными User-Agent | IIS logs, поле cs(User-Agent) | Попытка подбора или реплея сессии |
| Запросы к эндпоинтам EWS с токеном из OWA-сессии | Exchange logs, EWS trace | Горизонтальное перемещение внутри почтовой инфраструктуры |
| Необычные параметры в запросах к /owa/bin/ | IIS logs, поле cs-uri-query | Попытка триггера уязвимости через модификацию входных данных |
Добавьте к этому мониторинг создания правил Inbox и пересылки писем — после получения доступа к сессии атакующие часто настраивают автопересылку для постоянного сбора данных.
Один момент остаётся неочевидным: как отличить легитимное использование OWA с мобильного устройства от сессии, перехваченной через XSS? User-Agent можно подделать, геолокация не всегда показательна. Приходится смотреть на поведенческие паттерны — скорость навигации, последовательность действий, время между запросами.
Что делать, если патча ещё нет
Ждать обновления от Microsoft — не стратегия, когда эксплойт уже в дикой природе. Действуйте по приоритетам:
Сначала ограничьте внешнюю доступность OWA. Если пользователи работают из офиса — закройте прямой доступ из интернета, оставьте только VPN. Если удалёнка необходима — добавьте многофакторную аутентификацию на уровне reverse-прокси. Это не устраняет уязвимость, но усложняет начальную точку входа.
Затем примените mitigation-правила IIS в тестовом окружении. Проверьте на наборе типичных писем из вашей среды. Только после подтверждения отсутствия ложных срабатываний переносите на продакшн. Документируйте каждое исключение из правил — пригодится при аудите.
Параллельно настройте расширенное логирование для OWA. Включите логи параметров запросов, заголовков и времени ответа. Это даст базу для ретроспективного анализа, если инцидент уже произошёл.
Долгосрочно — планируйте миграцию на гибридную архитектуру или полный переход в облако. On-prem Exchange требует постоянного внимания к обновлениям и конфигурации. В условиях, когда новые уязвимости появляются быстрее циклов патчинга в некоторых организациях, облачный Exchange Online снижает операционную нагрузку за счёт автоматических обновлений и изолированного рендеринга.
Не могу сказать, что этот подход универсален. В регулируемых отраслях или при строгих требованиях к резидентности данных облако может быть недоступно. Тогда остаётся жёсткий контроль периметра и ускоренный цикл применения обновлений.
Какие индикаторы добавить в SIEM
Добавьте в корреляционные правила следующие события:
Запросы к /owa с параметрами, содержащими последовательности <script, javascript:, onerror=, onload= — даже если они закодированы в URL. Декодируйте cs-uri-query перед проверкой.
Создание правил Inbox через EWS или OWA API сразу после аутентификации с нового устройства или из необычной геолокации.
Массовая выгрузка писем или вложений через EWS в короткий временной интервал — нормальный пользователь редко скачивает десятки сообщений за минуту.
Изменение настроек пересылки на внешний домен — особенно если до этого пересылка не использовалась.
Каждое правило сопровождайте порогом срабатывания и контекстом. Сигнал без приоритета и без привязки к бизнес-процессу быстро попадает в игнор.