Обнаружение уязвимостей ProxyLogon в MS Exchange. Часть 1

Обнаружение уязвимостей ProxyLogon в MS Exchange. Часть 1

Life-Hack [Жизнь-Взлом]/Хакинг

#Обучение

Среди наиболее популярных почтовых серверов, используемых тысячами компаний по всему миру, можно выделить Microsoft Exchange (Microsoft Mail). По этой причине популярность и доступность Интернета делают его привлекательной целью для злоумышленников.

В этой статье мы коротко расскажем об архитектуре сервера MS Exchange, а также о том, как обнаружить эксплуатацию уязвимостей ProxyLogon. На данный момент мы продемонстрируем, как ProxyLogоn может быть обнаружен с помощью стандартных событий ОС и журналов Exchange, как в реальном времени, так и с использованием упреждающих подходов к отслеживанию угроз и атак, произошедших в прошлом. 

Векторы атак на MS Exchange 

Основные компоненты сервера MS Exchange и связи между ними представлены на схеме ниже.

Архитектура MS Exchange

В зависимости от версии у MS Exchange могут быть следующие роли: 

  • Сервер почтовых ящиков (Mailbox server).
  • Сервер клиентского доступа (Client Access) — фронтенд-сервис, который проксирует клиентские запросы на бэкенд-серверы.
  • Транспорт (Transport), который отвечает за управление почтовым потоком.
  • Единая система обмена сообщениями (Unified Messaging), которая позволяет использовать голосовые сообщения и другие возможности телефонии (роль недоступна на серверах версии 2019).
  • Управление (Management role), суть которого состоит в администрировании и гибкой настройке компонентов MS Exchange.
Основные протоколы, используемые MS Exchange

Основные компоненты Exchange и их краткое описание приведены ниже: 

  • Outlook Web Access (OWA) — веб-интерфейс для предоставления доступа к почтовым ящикам и работы с ними (чтение/отправка/удаление почты, редактирование календаря и т. д.)
  • Exchange Control Panel (ECP) — веб-интерфейс для администрирования компонентов Exchange: управления почтовыми ящиками, создания различных политик для управления почтовым потоком, подключения новых почтовых серверов и т. д.
  • Autodiscover — служба, позволяющая клиентам получать информацию о расположении различных компонентов сервера Exchange, например URL для службы EWS. Для получения информации требуется предварительная аутентификация пользователя.
  • Exchange Web Services (EWS) — API для предоставления различным приложениям доступа к компонентам почтовых ящиков.
  • Exchange ActiveSync (EAS) — сервис, позволяющий пользователям мобильных устройств получать доступ к электронной почте, календарю, контактам, задачам и работать с этой информацией без подключения к интернету.
  • RPC — служба клиентского доступа через протокол RPC, который работает поверх HTTP.
  • Offline Address Book (OAB) — служба автономной адресной книги сервера Exchange, которая позволяет пользователям Outlook кешировать содержимое GAL (Global Address List) и обращаться к нему даже при отсутствии подключения к Exchange. 

Все вышеописанные компоненты функционируют как приложения на веб-сервере Microsoft IIS. 

Атакуя сервер MS Exchange, злоумышленники, как правило, преследуют следующие цели: 

  • Получение доступа к конфиденциальной информации, содержащейся в корпоративной почте.
  • Запуск вредоносной рассылки с адресов компании-жертвы для проникновения в инфраструктуру другой организации.
  • Компрометация УЗ с помощью компонентов Exchange (успешная брутфорс-атака или обнаружение учетных данных в почтовой переписке) для входа в сеть компании через один из корпоративных сервисов.
  • Закрепление в сети компании (например, с помощью веб-шелла на сервисе OWA).
  • Повышение привилегий в домене с помощью сервера Exchange.
  • Выведение из строя сервера Exchange для нарушения внутренних бизнес-процессов компании (например, полное шифрование данных сервера). 

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

Для обнаружения различных атак на сервер MS Exchange будут полезны события источников, приведенных в табл. 2.

Характеристика источников событий

Уязвимости ProxyLogon 

2 марта 2021 года Microsoft выпустила обновления безопасности для ряда критических уязвимостей сервера MS Exchange. Обновления также исправили цепочку критических уязвимостей CVE-2021-26857, CVE-2021-26855, CVE-2021-26858, CVE-2021-27065, под общим названием ProxyLogon. После выпуска обновлений безопасности и публикации первых статей об этих уязвимостях по всему миру стали фиксироваться кибератаки с их использованием. Большинство атак были направлены на загрузку основной веб-оболочки на сервер для дальнейшего развития атаки. Хотя американские компании приняли на себя основную атаку, мы также зафиксировали ряд аналогичных атак, направленных на наших клиентов в России и Азии.

Цепочка уязвимостей ProxyLogon

Давайте подробнее рассмотрим цепочку уязвимостей ProxyLogon. Уязвимость CVE-2021-26857 на самом деле не является частью цепочки уязвимостей ProxyLogon, поскольку она приводит к выполнению кода на сервере и не требует предварительного использования других уязвимостей. Уязвимость CVE-2021-26857 связана с небезопасной десериализацией данных в службе единой системы обмена сообщениями. Для использования этой уязвимости требуется установка и настройка роли единой системы обмена сообщениями на сервере Exchange. Поскольку эта роль используется редко, на сегодняшний день не зарегистрировано никаких свидетельств использования этой уязвимости. Вместо этого злоумышленники используют цепочку уязвимостей CVE-2021-26855, CVE-2021-26858 и CVE-2021-27065, которая также позволяет удаленно выполнять произвольный код на почтовом сервере, но с ней проще работать.

 

ProxyLogon — это название уязвимости CVE-2021-26855 (SSRF), которая позволяет внешнему злоумышленнику обойти механизм аутентификации в MS Exchange и выдать себя за любого пользователя. Создавая запрос на стороне сервера, злоумышленник может отправить произвольный HTTP-запрос, который будет перенаправлен на другую внутреннюю службу от имени учетной записи компьютера почтового сервера. Чтобы воспользоваться этой уязвимостью, злоумышленник должен сформировать специальный запрос POST для статического файла в неавторизованных каталогах для чтения, например /ecp/x.js, если присутствие файла в каталоге не требуется. Тело запроса POST также будет перенаправлено на службу, указанную в файле cookie, под названием X-BEResource. 

Например, злоумышленник, использующий ProxyLogon, может выдать себя за администратора и пройти аутентификацию в панели управления Exchange (ECP), а затем перезаписать любой файл в системе с уязвимостями CVE-2021-26858 или CVE-2021-27065. 

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

После использования цепочки уязвимостей злоумышленник может запускать команды через веб-оболочку на сервере Exchange с привилегиями учетной записи, под которой запущен пул приложений на сервере IIS (по умолчанию NT AUTHORITY \ SYSTEM). Чтобы успешно использовать цепочку уязвимостей, злоумышленнику необходимо иметь сетевой доступ через порт 443 к серверу MS Exchange с установленной ролью клиентского доступа и знать имя почтового ящика пользователя с правами администратора. 

Эксплуатация CVE-2021-26855 

Уязвимость CVE-2021-26855 позволяет внешнему злоумышленнику отправить произвольный HTTP-запрос, который будет перенаправлен на указанную внутреннюю службу из учетной записи компьютера почтового сервера. Таким образом, уязвимость может обойти механизм аутентификации Exchange Server и выполнить запрос с наивысшими привилегиями. 

Поскольку злоумышленник может указать службу, на которую будет перенаправлен произвольный HTTP-запрос, эту уязвимость SSRF можно использовать различными способами. Рассмотрим два способа использования этой уязвимости: чтение электронной почты через EWS и загрузка веб-оболочки через ECP (CVE-2021-26858 и CVE-2021-27065). 

С помощью CVE-2021-26855 вы легко сможете загружать письма от любого пользователя, зная только его адрес электронной почты. Для работы требуется как минимум два сервера MS Exchange в атакуемой инфраструктуре. Например, запрос отправляется на сервер exchange.lab.local, а оттуда перенаправляется на exchange02.lab.local с помощью SSRF. На снимке экрана ниже показан пример такого вызова EWS API с использованием запроса SOAP для получения последних 10 электронных писем из почтового ящика user1@lab.local. Ответ от сервера содержит идентификаторы сообщений и другую информацию о них (например, заголовок или дату получения).

SOAP-запрос для получения списка писем

Если подставить идентификатор искомого письма в другой SOAP-запрос, можно получить оригинал этого письма.

SOAP-запрос для получения письма

Ответ от сервера будет содержать base64-представление оригинального письма.

Таким образом, все сообщения из любого почтового ящика могут быть загружены с сервера без аутентификации. Почта часто используется для передачи конфиденциальной информации, такой как платежные поручения, файлы конфигурации, идентификаторы пользователей, пароли или инструкции по подключению к серверам VPN и т. д. Этот вектор атаки не менее опасен, чем загрузка веб-оболочки на сервер. 

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

  • event_log_source:'EWS' AND AuthenticatedUser end with:'$' AND SoapAction IS NOT NULL AND UserAgent contains:'ExchangeWebServicesProxy/CrossSite/' AND NOT (SoapAction = 'GetUserOofSettings')

Вторая возможность использовать уязвимость SSRF — использовать ECP-аутентификацию с последующей эксплуатацией уязвимостей CVE-2021-26858 / CVE-2021-27065 для загрузки веб-оболочки на сервер. Чтобы направлять запросы в ECP, вы должны установить полный сеанс в ECP. Чтобы злоумышленник при установлении сеанса выдавал себя за администратора, он должен узнать SID учетной записи администратора почтового сервера. 

Из ответа на запрос NTLM к /rpc/rpcproxy.dll злоумышленник может сначала определить полное доменное имя почтового сервера, которое требуется в следующих шагах: оно указывается в ответе NTLM, который необходимо расшифровать.

Получение FQDN почтового сервера

Следующим шагом является получение LegacyDN и идентификатора почтового ящика с помощью HTTP-запроса для автообнаружения. Полное доменное имя почтового сервера, полученное на предыдущем шаге, указывается в файле cookie с именем X-BEResource.

Запрос к Autodiscover для получения информации о почтовом ящике администратора

Затем злоумышленник может получить SID целевого пользователя с помощью HTTP-запроса MAPI. Злоумышленник отправляет запрос на делегирование доступа к почтовому ящику. Этот запрос также перенаправляется в MAPI от имени пользователя учетной записи компьютера и вызывает ошибку доступа. Ошибка содержит SID разыскиваемого пользователя.

Запрос к MAPI для получения SID администратора

Наконец, получив SID пользователя, злоумышленник сможет пройти аутентификацию на сервере, представившись администратором, отправив специально сформированный запрос POST на /ecp/proxyLogon.ecp.

Аутентификация на ECP под администратором

Запрос содержит заголовок с именем msExchLogonMailBox, который указывает SID пользователя, для которого вы хотите пройти аутентификацию. Тело запроса POST также включает SID этого пользователя. Сервер отвечает двумя файлами cookie с именами ASP.NET_SessionId и msExchEcpCanary, которые злоумышленник может использовать для последующих запросов ECP. Получение этих файлов cookie является конечным результатом использования злоумышленником уязвимости ProxyLogon (CVE-2021-26855), если он планирует использовать уязвимости CVE-2021-26858 и CVE-2021-27065, а затем загрузить веб-оболочку на сервер. 

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

  • event_log_source:'IIS' AND cs-method:'POST' AND cs-uri-stem:'/ecp/proxyLogon.ecp' AND cs-username end with:'$'

Продолжение следует…

Источник


Report Page