ProxyLogon: нулевые дни в Exchange и срочный аудит у клиентов

2 марта Microsoft выпустила внеплановые патчи для Exchange Server - это само по себе сигнал тревоги. Плановый Patch Tuesday был через неделю; когда Microsoft не ждёт - значит, дыра активно эксплуатируется. Что и подтвердилось: к моменту публикации бюллетеней интернет уже несколько дней методично сканировался на предмет уязвимых серверов.

Что за уязвимости

Речь о четырёх CVE, которые вместе образуют цепочку удалённого выполнения кода без аутентификации:

• CVE-2021-26855 - SSRF в компоненте Exchange, который позволяет обойти аутентификацию и отправить запросы от имени сервера. Это стартовая точка цепочки.
• CVE-2021-26857 - небезопасная десериализация в Unified Messaging Service, даёт выполнение кода с привилегиями SYSTEM.
• CVE-2021-26858 и CVE-2021-27065 - запись произвольных файлов после аутентификации. В связке с первой CVE аутентификация не нужна.

Результат цепочки - веб-шелл на сервере Exchange, полный доступ к почте и возможность двигаться дальше по сети. Exchange, как правило, стоит в центре корпоративной инфраструктуры и имеет доверенные отношения с Active Directory. Это не просто почтовый сервер - это плацдарм.

Атаки атрибутированы группе HAFNIUM - предположительно связана с Китаем, по оценке Microsoft. До публичного раскрытия группа успела поработать достаточно долго, чтобы засветиться у исследователей Volexity и Dubex.

Кто под угрозой

Уязвимы on-premise версии Exchange: 2013, 2016 и 2019. Exchange Online - облачный, не затронут. Но именно это и создаёт проблему: среди наших клиентов on-premise Exchange держат те, кто по разным причинам не перешёл в облако - в основном компании с требованиями к размещению данных, иногда просто инерция.

Патчи закрывают конкретные CU (Cumulative Update) под каждую версию. Если сервер не обновлялся последние несколько месяцев - велика вероятность, что нужный CU сначала придётся доустановить, и только потом накатывать Security Update. Exchange в этом плане всегда был неудобен: патчи зависят от текущего CU, а CU-апдейты у Exchange тяжёлые и требуют обслуживания.

Как мы узнали и что сделали

Первые сообщения об атаках пошли через исследовательские каналы ещё до официального патча. Когда Microsoft выпустила бюллетень - стало ясно: ждать некогда.

Первым делом - инвентаризация. У нас несколько клиентов с on-premise Exchange, и нужно было понять, кто и в каком состоянии. Позвонили и написали всем до обеда того же дня.

Картина оказалась предсказуемо неоднородной:

• Один клиент - Exchange 2016 CU18, свежий. Патч встал быстро, без вопросов.
• Второй - Exchange 2016 CU14. Нужен сначала CU19, потом Security Update. Это несколько часов работы с обслуживанием.
• Третий - Exchange 2013, давно не обновлявшийся. Здесь сложнее всего: версия ещё в поддержке, но CU-долг накопился.

Параллельно с обновлениями - проверка логов на предмет следов эксплуатации до установки патча. Microsoft опубликовала скрипт для поиска индикаторов компрометации: проверка логов IIS на подозрительные запросы к /ecp/ и /owa/, поиск нехарактерных файлов в директориях Exchange. Это важный шаг, который легко пропустить в спешке установки патча: заткнуть дыру нужно, но если к тому моменту там уже был веб-шелл - он никуда не денется.

Что проверяли в логах

Microsoft и сообщество выложили конкретные паттерны для поиска. Мы прошлись по нескольким точкам:

• Логи IIS (W3SVC) - ищем POST-запросы к /ecp/DDI/DDIService.svc/GetObject с подозрительными параметрами и нехарактерные запросы к /ecp/*.js с телом.
• Путь \inetpub\wwwroot\aspnet_client\ и аналогичные директории - Exchange не должен туда писать. Чужие .aspx-файлы - красный флаг.
• Application Event Log - события от MSExchange Unified Messaging с нестандартными путями в параметрах.
• Лог аутентификаций - подозрительные успешные аутентификации от IP-адресов, которые не должны знать Exchange.

На двух из трёх клиентов логи оказались чистыми - никаких следов до момента патчинга. На третьем, с Exchange 2013, пришлось покопаться дольше: логи IIS частично ротировались, полной картины не было. Это отдельная история про то, зачем Exchange нужен нормальный log management, а не дефолтные настройки хранения.

Неудобный вопрос про Exchange Online

Клиенты, у которых почта в Exchange Online или Microsoft 365, этот инцидент почти не почувствовали. Максимум - пришёл вопрос «а нас это касается?». Ответ: нет, не касается. Это не реклама облака - у on-premise есть свои причины существования. Но история повторяется: SolarWinds в декабре ударил по инфраструктурным инструментам, теперь Exchange. On-premise означает что ответственность за патчинг на вас, и она требует реакции в часы, не в дни.

Где мы сейчас

Патчи у всех трёх клиентов установлены. Следов активной эксплуатации до установки патча не обнаружено - насколько это можно утверждать при неполных логах на одном из серверов. По последнему клиенту договорились на отдельное занятие: настройка централизованного сбора логов Exchange и минимальный аудит конфигурации - что с правами сервисных аккаунтов, что с сетевой доступностью OWA/ECP.

Хорошая новость: все трое среагировали быстро. Плохая новость: если бы не наш звонок - неизвестно, через сколько дней они бы самостоятельно добрались до этого бюллетеня.