Охота на атаки MS Exchange. Часть 2 (CVE-2020-0688, CVE-2020-16875, CVE-2021-24085)
Журналы и полезные события
В качестве источников событий мы будем использовать упомянутые ранее журналы MS Exchange и ОС Windows.
Название источника | Краткое описание источника | Путь к источнику |
---|---|---|
События Security аудита Windows | Журнал хранит все события (старты процессов, успешные/неуспешные входы и т. д.), которые настраиваются в политике аудита | Журнал Security |
События Application аудита Windows | Журнал Application содержит различную информацию о работе приложений в ОС Windows: ошибки запуска, heartbeat, изменение конфигурации и т. д. | Журнал Application |
События аудита PowerShell | Журнал содержит события, которые регистрируют выполнение скрипт-блоков, pipelines и модулей PowerShell | Журнал Windows PowerShell
Журнал Microsoft-Windows-PowerShell/Operational |
События управления MS Exchange | Журнал содержит информацию об управляющих действиях с компонентами Exchange. В нем отображаются все действия, выполненные с помощью Exchange Management Shell и ECP | Журнал MSExchange Management |
События IIS — Web OWA (Outlook Web Access) | Журнал хранит события — access-логи веб-сервера IIS, которые содержат все обращения к интерфейсу OWA | C:\inetpub\logs\LogFiles\W3SVC1\ u_ex*.log |
События IIS — Web ECP (Exchange Management Panel) | Журнал хранит события — access-логи веб-сервера IIS, которые содержат все обращения к интерфейсу ECP | C:\inetpub\logs\LogFiles\W3SVC2\ u_ex*.log |
События EWS | Журнал содержит информацию о клиентском взаимодействии с сервисом EWS | C:\Program Files\Microsoft\Exchange Server\<version number>\Logging\Ews\Ews_*.log
|
События Sysmon | Журнал содержит события утилиты Sysmon , которая позволяет
реализовывать расширенное логирование за счет установки
своего драйвера в систему |
Журнал Microsoft-Windows-Sysmon/Operational |
Клиентский RPC | Журнал содержит информацию об RPC-взаимодействии клиентов с сервером Exchange | C:\Program Files\Microsoft\Exchange Server\<version number>\Logging\RPC Client Access\RCA_*.log
|
Сервер ECP | Журнал содержит запросы к интерфейсу ECP | C:\Program Files\Microsoft\Exchange Server\<version number>\Logging\ECP\Server\ECPServer*.log
|
OAB Generator | Журнал содержит события генератора OAB | C:\Program Files\Microsoft\Exchange Server\V15\Logging\OABGeneratorLog\*.log
|
Обнаружение эксплуатации 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.
После формирования ViewState
на уязвимый сервис ECP отправляется запрос,
в результате чего сервер возвращает код ошибки 500.
Если пропустить запрос через утилиту Burp Suite
, то в декодере
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’
В журнале Application содержится событие, которое говорит об ошибке в приложении MSExchange Control Panel и имеет Event ID = 4.
Правило, детектирующее эксплуатацию 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).
Выдачу прав 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'))
Эксплоит для этой уязвимости последовательно выполняет следующие шаги:
- Аутентификация под заданной учетной записью для получения сессии через OWA.
- Получение параметра
ViewState
с помощью обращения к функциональности управления политикой DLP. - Добавление новой вредоносной DLP-политики, которая содержит исполняемую команду, запускаемую с помощью PowerShell.
Давайте запустим утилиту и посмотрим, как будут выглядеть события Exchange. Ниже можно увидеть, что запуск эксплоита под учетной записью dadmin был выполнен успешно.
В 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-политики по событиям журналов 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.
Обнаружить успешную эксплуатацию уязвимости 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 имеет схожую логику и выполняет следующие действия:
- Создает удаленную PowerShell-сессию с помощью компонента PowerShell сервера
Exchange. Подключение
осуществляется под учетной записью, имеющей роль
Data Loss Prevention
.
Фрагмент кода создания удаленной PowerShell-сессии - Создает новую политику с помощью командлета
New-DlpPolicy
. Полезная нагрузка хранится в переменной $xml:
ЗапускNew-DlpPolicy
в рамках удаленной PowerShell-сессии
Ниже показан результат запуска PowerShell-эксплоита с успешным подключением
под непривилегированным
пользователем user1 и выполнением команды whoami
с привилегиями
System.
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 более сложный. Для успешной реализации атаки требуется выполнить следующие шаги:
- Скомпрометировать произвольную доменную учетную запись, у которой имеется почтовый ящик.
- С помощью интерфейса ECP экспортировать сертификат.
- С помощью полученного сертификата сгенерировать CSRF-токен, он же параметр
msExchEcpCanary
. - Заставить администратора 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;
- загрузить новую надстройку из файла.
Надстройка представляет собой конфигурационный файл в формате XML. Злоумышленник может
создать
вредоносный конфиг, который, например, будет пересылать содержимое клиентских писем
на подконтрольный
сервер атакующего. Для загрузки конфигурационного файла используется интерфейс
/ecp/Handlers/UploadHandler.ashx
.
Ниже приведен фрагмент JavaScript-кода, который отработает у администратора Exchange
в случае его
перехода на сайт атакующего. Этот код получает содержимое вредоносной надстройки
evil.xml
,
которая также находится на ресурсе атакующего, и отправляет его POST-запросом
на URL
/ecp/Handlers/UploadHandler.ashx
. Параметр msExchEcpCanary
содержит CSRF-токен,
который был сгенерирован на предыдущем шаге. Также стоит учитывать, что на момент
перехода
администратора на сайт атакующего его сессия в ECP должна быть все еще
активной.
Правило для обнаружения загрузки надстройки будет иметь вид:
event_log_source:’IIS’ AND http_method=’POST’ AND http_code='200' AND url_path='/ecp/Handlers/UploadHandler.ashx'
Заключение
Попытки эксплуатации рассмотренных в статье уязвимостей встречаются и по сей день. Чаще всего они не приводят к успеху, но бывают и исключения. Сбор важных событий безопасности и реализация детектирующих правил позволят вовремя отреагировать на возможную атаку и устранить негативные последствия инцидента на ранней стадии.
В следующей статье мы поговорим о векторах повышения привилегий в домене Windows через сервер MS Exchange и о способах их обнаружения.