Zero-days в Microsoft Exchange

vulnerability vulnerability

В конце сентября GTSC сообщила об атаке на критическую инфраструктуру, которая произошла в августе. В ходе расследования эксперты обнаружили, что в атаке использовались две уязвимости 0-day в Microsoft Exchange Server. Первая, позже идентифицированная как CVE-2022-41040, представляет собой уязвимость подделки запросов на стороне сервера (SSRF), которая позволяет аутентифицированному злоумышленнику удаленно задействовать следующую уязвимость - CVE-2022-41082. Вторая уязвимость, в свою очередь, позволяет удаленное выполнение кода (RCE), когда MS Exchange PowerShell доступен злоумышленнику. Как отмечается в отчете GTSC, обе уязвимости эксплуатировались вместе в дикой природе для создания бэкдора на уязвимом сервере и осуществления бокового перемещения.

После обнаружения CVE-2022-41040 и CVE-2022-41082 компания Microsoft предоставила руководство по устранению уязвимостей, а также несколько обновлений. По данным компании, уязвимости затрагивают MS Exchange Server 2013, MS Exchange Server 2016 и MS Exchange Server 2019.

11 октября 2022 года Microsoft выпустила патчи для устранения этих уязвимостей в рамках обновления Patch Tuesday. После этого, 17 ноября, исследователь безопасности опубликовал первый рабочий PoC. Это был скрипт на языке Python, который принимает следующие параметры: пользователя, пароль, почтовый адрес и командную строку для выполнения на хосте жертвы.

Сообщество кибербезопасности окрестило пару уязвимостей ProxyNotShell. Название относится к недавней цепочке атак ProxyShell, содержащей аналогичные уязвимости в серверах Exchange, которые были раскрыты в 2021 году. ProxyShell - это набор из трех уязвимостей: CVE-2021-34473, CVE-2021-34523 и CVE-2021-31207. Злоумышленники использовали их для создания веб-оболочек и выполнения произвольного кода на уязвимых серверах Microsoft Exchange Servers.

Подробности эксплуатации ProxyNotShell

Первым шагом в этой атаке является эксплуатация CVE-2022-41040 для получения доступа к конечной точке PowerShell API. Используя недостаточную фильтрацию входных данных в механизме Exchange Autodiscover, злоумышленник с известной комбинацией логина и пароля для зарегистрированной учетной записи может получить доступ к привилегированной конечной точке Exchange Server API (https://%exchange server domain%/powershell). Этот доступ позволяет злоумышленнику выполнять команды PowerShell в среде Exchange на серверной машине, передавая их в полезной нагрузке по протоколу XML SOAP.

На следующем этапе злоумышленник должен получить доступ к Web-Based Enterprise Management (WBEM) через протокол WSMAN. Злоумышленник инициирует shell на уязвимой системе для дальнейшего выполнения сценариев PowerShell через Windows Remote Management (PsRemoting).

HTTP POST запрос с XML SOAP для инициирования PsRemoting

После инициирования оболочки злоумышленник должен немедленно продлить время ее жизни, иначе оболочка будет закрыта, так как по умолчанию ее время истечения слишком мало. Это необходимо для дальнейшего выполнения команд на Exchange Server. Для этого злоумышленник немедленно отправляет специальный запрос через WSMAN, который включает опцию keep alive.

HTTP POST запрос с XML SOAP для продления времени жизни оболочки

После этого злоумышленник эксплуатирует вторую уязвимость - CVE-2022-41082. Используя PowerShell Remoting, злоумышленник отправляет запрос на создание адресной книги, передавая в качестве параметра закодированные и сериализованные данные со специальной полезной нагрузкой. В опубликованном PoC эти закодированные данные содержат гаджет System.UnitySerializationHolder, который порождает объект класса System.Windows.Markup.XamlReader. Этот класс обрабатывает XAML-данные из полезной нагрузки, которая создает новый объект класса System.Diagnostics и содержит вызов метода для открытия нового процесса на целевой системе. В опубликованном PoC этим процессом является calc.exe.

HTTP POST запрос с XML SOAP для запуска нового процесса

Постэксплуатация ProxyNotShell

Через несколько недель после раскрытия уязвимости "Kaspersky Lab," обнаружили успешную эксплуатацию ProxyNotShell в дикой природе. Атакующий выполнил следующие действия:

  1. Разведка (пользователи, группы, домены).
  2. Различные попытки взлома (даже сброс уязвимых двоичных файлов)
  3. Удаленная инъекция процесса
  4. Закрепление
  5. Обратный shell

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

На стороне сервера все процессы, запускаемые с помощью эксплуатации, имеют главный родительский процесс с определенными параметрами: w3wp.exe -ap "msexchangepowershellapppool".

Эти этапы атаки после эксплойта очень похожи на этапы атаки, о которой сообщает TrendMicro, с единственным отличием - уязвимости, которые эксплуатируются.

Эксплуатация ProxyNotShell после устранения уязвимости

Indicators of Compromise

IPv4

  • 193.149.185.52

IPv4 Port Combinations

  • 193.149.185.52:443

Domains

  • sync.service.auzreservices.com
  • ync.service.auzreservices.com

MD5

  • 379f87daa6a23400adf19c1cdd6b0dc9
  • 47a0814408210e6fca502b3799b3952b
  • a2fae32f116870e5a94b5fab50a1cb71
  • f77e55fd56fdad21766caa9c896734e9
  • f9322ead69300501356b13d751165daa

SHA1

  • 32b545353f4e968dc140c14bc436ce2a91aacd82
  • c7fec59ecf6608efe00db5d29ba1d80143bd1655

SHA256

  • 07bbd8a80b5377723b13dbb40a01ca44cbc203369f5e5652a25b448e27ca108c
  • 935e10f5169397a67f4c36bffbc3ba46c3957b7521edd3fa83bd975157b79bd8

 

Добавить комментарий