Охота на атаки MS Exchange. Часть 2 (CVE-2020-0688, CVE-2020-16875 и CVE-2021-24085)

Автор статьи: Антон Медведев
Ревью статьи: Вадим Хрыков

Наша прошлая статья была посвящена различным методам обнаружения эксплуатации уязвимостей ProxyLogon. В этот раз мы поговорим о методах обнаружения других нашумевших уязвимостей на сервере MS Exchange, а именно CVE-2020-0688, CVE-2020-16875 и CVE-2021-24085.

Несмотря на то что эти уязвимости не такие свежие, как ProxyLogon, мы продолжаем обнаруживать следы их эксплуатации (в том числе успешной) у наших клиентов. А своевременное обнаружение попыток эксплуатации позволит минимизировать последствия атаки для организации или избежать их вовсе.

Журналы и полезные события

В качестве источников событий мы будем использовать упомянутые ранее журналы MS Exchange и ОС Windows.

Обнаружение эксплуатации CVE-2020-0688

Уязвимость CVE-2020-0688 содержится в компоненте Exchange Control Panel (ECP) и связана с тем, что сервер не может должным образом создавать уникальные криптографические ключи, поскольку ключи не генерируются случайным образом, а предустановлены и имеют одинаковые значения. Если просмотреть содержимое настроек ECP в файле web.config из директории C:\Program Files\Microsoft\Exchange Server\<Version Number>\ClientAccess\ecp, то мы увидим уже заданные значения validationKey и decryptionKey. Эти ключи используются для обеспечения безопасности параметра ViewState.

Фрагмент файла web.config

В одной из статей на сайте Microsoft параметр ViewState описывается следующим образом:

На страницах ASP.NET View State представляет состояние страницы в момент, когда она была в последний раз обработана на сервере. Этот параметр используется для создания контекста вызова и сохранения значений в двух последовательных запросах одной и той же страницы. По умолчанию состояние сохраняется на клиенте с использованием скрытого поля, добавленного на страницу, и восстанавливается на сервере до обработки запроса страницы. View State перемещается вперед и назад вместе с самой страницей, но не представляет и не содержит никакой информации, относящейся к отображению страницы на стороне клиента.

Таким образом, предустановленные ключи позволяют авторизованному пользователю отправить приложению ECP специально сформированный параметр ViewState, вследствие десериализации которого на сервере Exchange будет выполнен вредоносный код в контексте System.

Создать вредоносный объект нам поможет небезызвестная утилита ysoserial, позволяющая эксплуатировать небезопасную десериализацию в .NET-приложениях.

Ниже приведен пример генерации ViewState, полезной нагрузкой которого выступает запуск whoami.

Запуск утилиты ysoserial

Параметры validationkey и generator, как было описано ранее, предустановлены и не меняются. Значение viewstateuserkey требуется взять из сессионного значения ASP.NET_SessionId пользователя, авторизованного на сервисе ECP.

Значения cookie пользователя, авторизованного на сервисе ECP

После формирования ViewState на уязвимый сервис ECP отправляется запрос, в результате чего сервер возвращает код ошибки 500.

Ответ сервера при эксплуатации CVE-2020-0688

Если пропустить запрос через утилиту BurpSuite, то в декодере ViewState можно увидеть, что полезная нагрузка передается в теге вместе с другими пользовательскими параметрами:

Декодированное значение ViewState

В случае успешной эксплуатации уязвимости процесс w3wp.exe, отвечающий за ECP (MSExchangeECPAppPool), выполнит полезную нагрузку, переданную в параметре ViewState. Правило обнаружения выполнения команд процессом веб-сервера w3wp.exe с использованием cmd.exe или интерпретатора PowerShell выглядит следующим образом:

• event_log_source:'Security' AND event_id:'4688' AND proc_parent_file_path end with:'\w3wp.exe' AND proc_file_path end with:('\cmd.exe' OR '\powershell.exe')

В access-логах IIS содержится запрос на URL /ecp/default.aspx, на который сервер ответил со статусом 500 (внутренняя ошибка сервера). Правило, детектирующее эксплуатацию CVE-2020-0688 с помощью событий IIS:

• event_log_source:’IIS’ AND http_method=’GET’ AND http_status_code=’500’ AND url_path=’/ecp/default.aspx’ AND url_query contains ‘__VIEWSTATEGENERATOR’ AND hurl _query contains ‘__VIEWSTATE’

Событие эксплуатации CVE-2020-0688 (IIS)

В журнале Application содержится событие, которое говорит об ошибке в приложении MSExchange Control Panel и имеет Event ID = 4.

Результат эксплуатации CVE-2020-0688 (журнал Application)

Правило, детектирующее эксплуатацию CVE-2020-0688 с помощью событий журнала Application:

• event_log_source:’Application’ AND event_id=’4’ AND (Message contains ‘__VIEWSTATE’)

Обнаружение эксплуатации CVE-2020-16875

Успешная эксплуатация уязвимости CVE-2020-16875 позволяет злоумышленнику выполнять произвольный код на сервере Exchange в контексте пользователя System. В дальнейшем атакующий может повысить свои привилегии в домене и скомпрометировать всю сеть организации.

Для успешной аутентификации требуется доменная учетная запись от корпоративного почтового ящика, которая состоит в группе с правами Data Loss Prevention (дальше будем называть ее DLP). Эксплуатация производится через компонент DLP. Настройка DLP осуществляется через интерфейс ECP. Механизм DLP позволяет фильтровать почтовый поток по заданным паттернам и правилам на основе анализа содержимого писем и их вложений.

Поскольку мы уже знаем, что для успешной эксплуатации атакующий должен состоять в DLP-группе, то на эту активность можно реализовать правило на создание новой группы с ролью Data Loss Prevention, а также добавление в группу нового пользователя. Такие действия можно осуществить как с помощью интерфейса ECP, так и с помощью Exchange Management Shell, используя следующие команды:

• New-RoleGroup -Name "dlp users" -Roles "Data Loss Prevention" -Members "user1" (создание группы dlp users с ролью Data Loss Prevention и добавление в нее пользователя user1);

  
  

• Update-RoleGroupMember -Members "dadmin" -identity "dlp users" (добавление пользователя dadmin в группу dlp users).

  
  

Ниже приведен скриншот события добавления пользователя dadmin в группу с помощью интерфейса ECP. Также эту активность можно проследить по событиям аудита PowerShell (Event ID 800 и 4104).

Добавление пользователя dadmin в группу dlp users (журнал MSExchange Management)

Выдачу прав Data Loss Prevention с помощью событий аудита PowerShell и журнала MSExchange Management можно отследить при помощи следующего правила:

• event_log_source:('PowershellAudit' OR 'MSExchange Management') AND event_id:('1' OR ’800’ OR '4104') AND ((Message contains ‘New-RoleGroup’ AND Message contains ‘Data Loss Prevention’) OR (Message contains ‘Update-RoleGroupMember’ AND Message contains ‘<Имя группы с правами DLP>’ AND Message contains '-Members'))

Эксплоит для этой уязвимости последовательно выполняет следующие шаги:

1. Аутентификация под заданной учетной записью для получения сессии через OWA.
2. Получение параметра ViewState с помощью обращения к функциональности управления политикой DLP.
3. Добавление новой вредоносной DLP-политики, которая содержит исполняемую команду, запускаемую с помощью PowerShell.

Давайте запустим утилиту и посмотрим, как будут выглядеть события Exchange. Ниже можно увидеть, что запуск эксплоита под учетной записью dadmin был выполнен успешно.

Успешная эксплуатация уязвимости CVE-2020-16875

В access-логах ECP содержится событие успешного добавления новой DLP-политики:

• 2021-03-09 12:03:31 10.3.132.20 POST /ecp/DLPPolicy/ManagePolicyFromISV.aspx ActID=3b6c5adc-c7d0-4aeb-82ec-711c2257ece6 444 LAB\dadmin 192.168.1.20 python-requests/2.22.0 - 200 0 0 863

Правило на создание новой DLP-политики с использованием событий IIS:

• event_log_source:’IIS’ AND http_method=’POST’ AND http_code='200' AND url_path='/ecp/DLPPolicy/ManagePolicyFromISV.aspx'

При эксплуатации уязвимости создается новая политика, поэтому в журнале MSExchange Management мы увидим событие добавления этой политики со случайным именем, содержащее вредоносную полезную нагрузку в параметре TemplateData:

Событие создания новой DLP-политики (журнал MSExchange Management)

Обнаружить создание новой DLP-политики по событиям журналов PowerShell и MSExchange Management можно при помощи следующего правила:

• event_log_source:('PowershellAudit' OR 'MSExchange Management') AND event_id:('1' OR ’800’ OR '4104') AND (Message contains ‘New-DlpPolicy’ AND Message contains '-TemplateData')

Результат эксплуатации уязвимости — запуск Notepad. В событиях старта процессов, содержащихся в журнале Security, можно увидеть запуск процесса Notepad родительским процессом w3wp.exe с привилегиями System.

Событие старта процесса (журнал Security)

Обнаружить успешную эксплуатацию уязвимости CVE-2020-16875 можно при помощи уже рассмотренного выше правила:

• event_log_source:'Security' AND event_id:'4688' AND proc_parent_file_path end with:'\w3wp.exe' AND proc_file_path end with:('\cmd.exe' OR '\powershell.exe')

Другой вариант эксплоита на PowerShell имеет схожую логику и выполняет следующие действия:

1. Создает удаленную PowerShell-сессию с помощью компонента PowerShell сервера Exchange. Подключение осуществляется под учетной записью, имеющей роль `Data Loss Prevention`.
   
   
   Фрагмент кода создания удаленной PowerShell-сессии
2. Создает новую политику с помощью командлета `New-DlpPolicy`. Полезная нагрузка хранится в переменной $xml:
   
   
   Запуск New-DlpPolicy в рамках удаленной PowerShell-сессии

Ниже показан результат запуска PowerShell-эксплоита с успешным подключением под непривилегированным пользователем user1 и выполнением команды whoami с привилегиями System.

В событиях IIS видно создание удаленной сессии:

• 2021-03-09 13:47:04 10.3.132.20 POST /powershell serializationLevel=Full;ExchClientVer=15.1.1591.10;clientApplication=ManagementShell;TargetServer=;PSVersion=5.1.14393.693&sessionID=Version_15.1_(Build_1590.10)=rJqNiZqNgZqHnJeekZia0bO+vdGzsLy+s4HOxsvNz8nNycvIgc3Pzc7Sz8zSz8arzszFysvFz8s= 444 lab\dadmin 192.168.1.20 Microsoft+WinRM+Client - 500 687 0 180002

Правило, детектирующее эту активность:

• event_log_source:’IIS’ AND http_method=’POST’ AND url_path='/powershell' AND (Message contains ‘serializationLevel=Full AND Message contains 'clientApplication=ManagementShell') AND user_agent='Microsoft+WinRM+Client'

В журнале Security можно обнаружить факт успешного старта процесса whoami с родительским процессом w3wp.exe. Выполнение команды New-DlpPolicy по журналу аудита PowerShell обнаруживается одним из ранее упомянутых правил.

Событие запуска whoami

Обнаружение эксплуатации CVE-2021-24085

Процесс эксплуатации уязвимости CVE-2021-24085 более сложный. Для успешной реализации атаки требуется выполнить следующие шаги:

1. Скомпрометировать произвольную доменную учетную запись, у которой имеется почтовый ящик.
2. С помощью интерфейса ECP экспортировать сертификат.
3. С помощью полученного сертификата сгенерировать CSRF-токен, он же параметр msExchEcpCanary.
4. Заставить администратора Exchange перейти на вредоносную страницу атакующего, которая от лица администратора отправит запрос на сервер Exchange с предустановленным значением токена.

В случае успешной эксплуатации уязвимости злоумышленник повысит свои привилегии до администратора Exchange.

Для реализации атаки можно использовать GitHub-проект, где файл poc.py отвечает за получение сертификата, который будет использоваться для генерации CSRF-токена.

YellowCanary — проект, написанный на языке на C# и отвечающий за генерацию токена.

Poc.js — полезная JavaScript-нагрузка, размещаемая злоумышленником на подконтрольном веб-сервере, куда должен перейти администратор Exchange.

На скриншоте ниже видно, что в результате работы скрипта poc.py сертификат был успешно экспортирован в файл testcert.der.

Успешный экспорт сертификата

Событие из access-логов ECP, которое содержит следы сохранения сертификата:

• 2021-03-09 15:52:55 10.3.132.20 POST /ecp/DDI/DDIService.svc/SetObject schema=ExportCertificate&msExchEcpCanary=yylkJJJocUWa3HVCEcQli7B3FcF--tgI2nbpJpHLcFZ60E9sZ2gmDpi_sFqf3jl9YcG9qcRMzek.&ActID=cf99b7d2-4eac-4435-a041-f0adaa44ed94 444 LAB\dadmin 192.168.1.20 python-requests/2.22.0 - 200 0 0 500

Сертификат сохраняется в файловой системе сервера Exchange — в файл poc.png, расположенный в каталоге IIS, после чего успешно скачивается с помощью того же скрипта poc.py.

Событие скачивания сертификата:

• 2021-03-09 15:52:55 10.3.132.20 GET /ecp/poc.png - 444 LAB\EXCHANGE$ 192.168.1.20 python-requests/2.22.0 - 200 0 0 7

Таким образом, мы можем реализовать правило, детектирующее событие экспорта сертификата по access-логам IIS:

• event_log_source:’IIS’ AND http_method=’POST’ AND http_code='200' AND url_path='/ecp/DDI/DDIService.svc/SetObject' AND (Message contains 'schema=ExportCertificate')

После получения сертификата злоумышленник с помощью утилиты YellowCanary генерирует параметр msExchEcpCanary, необходимый для реализации CSRF-атаки. Первый параметр — это SID пользователя, от лица которого мы хотим совершить действия на ECP:

Генерация параметра msExchEcpCanary

Далее злоумышленник должен заставить привилегированного пользователя (в идеале — администратора Exchange) перейти по заранее сформированной ссылке, содержащей вредоносный JavaScript-код. Этот код может отправлять от лица администратора запросы на ECP. Таким образом можно, например, проэксплуатировать уязвимость CVE-2021-27065, о которой мы рассказывали в предыдущей статье. В результате злоумышленник получит доступ к серверу Exchange с привилегиями System с помощью загруженного веб-шелла.

Помимо описанного способа данную атаку можно реализовать через добавление вредоносной надстройки MS Outlook — приложения, которое предоставляет пользователям расширенные возможности.

Существует три способа добавления надстройки Outlook:

• добавить через URL, по адресу которого находится надстройка;
• скачать из Office Store;
• загрузить новую надстройку из файла.

Добавление новой надстройки через интерфейс ECP

Настройка представляет собой конфигурационный файл в формате XML. Злоумышленник может создать вредоносный конфиг, который, например, будет пересылать содержимое клиентских писем на подконтрольный сервер атакующего. Для загрузки конфигурационного файла используется интерфейс /ecp/Handlers/UploadHandler.ashx.

Ниже приведен фрагмент JavaScript-кода, который отработает у администратора Exchange в случае его перехода на сайт атакующего. Этот код получает содержимое вредоносной надстройки evil.xml, которая также находится на ресурсе атакующего, и отправляет его POST-запросом на URL /ecp/Handlers/UploadHandler.ashx. Параметр msExchEcpCanary содержит CSRF-токен, который был сгенерирован на предыдущем шаге. Также стоит учитывать, что на момент перехода администратора на сайт атакующего его сессия в ECP должна быть все еще активной.

Добавление надстройки с помощью JavaScript

Правило для обнаружения загрузки надстройки будет иметь вид:

• event_log_source:’IIS’ AND http_method=’POST’ AND http_code='200' AND url_path='/ecp/Handlers/UploadHandler.ashx'

Заключение

Попытки эксплуатации рассмотренных в статье уязвимостей встречаются и по сей день. Чаще всего они не приводят к успеху, но бывают и исключения. Сбор важных событий безопасности и реализация детектирующих правил позволят вовремя отреагировать на возможную атаку и устранить негативные последствия инцидента на ранней стадии.

В следующей статье мы поговорим о векторах повышения привилегий в домене Windows через сервер MS Exchange и о способах их обнаружения.