ProxyLogon, ProxyOracle, ProxyShell, ProxyToken

отредактировано 15 ноя Раздел: Уязвимости систем и приложений
В апреле 2021 года Orange Tsai из исследовательской группы DEVCORE продемонстрировал уязвимость удаленного выполнения кода в Microsoft Exchange во время конкурса Pwn2Own Vancouver 2021. С тех пор он обнаружил несколько других ошибок в Exchange и представил некоторые из своих выводов на недавней конференции Black Hat. Теперь, когда Microsoft исправила ошибки, Orange предоставил подробный отчет об уязвимостях, которые он называет «ProxyShell».

ProxyShell состоит из 3 уязвимостей:

- CVE-2021-34473 - Запутывание пути перед аутентификацией приводит к обходу ACL
(Pre-auth Path Confusion leads to ACL Bypass)
- CVE-2021-34523 - Повышение привилегий в серверной части Exchange PowerShell.
- CVE-2021-31207 - Запись произвольного файла после авторизации приводит к RCE

С ProxyShell неаутентифицированный злоумышленник может выполнять произвольные команды на Microsoft Exchange Server через открытый порт 443!

CVE-2021-34473 - Pre-auth Path Confusion leads to ACL Bypass

Первая уязвимость ProxyShell похожа на SSRF в ProxyLogon. Он также появляется, когда внешний интерфейс (известный как службы клиентского доступа или CAS) вычисляет внутренний URL-адрес. Когда клиентский HTTP-запрос классифицируется как явный запрос на вход, Exchange нормализует URL-адрес запроса и удаляет часть адреса почтового ящика, прежде чем направить запрос на серверную часть.

Явный вход в систему - это специальная функция в Exchange, которая позволяет браузеру встраивать или отображать почтовый ящик или календарь определенного пользователя с одним URL-адресом. Для реализации этой функции этот URL-адрес должен быть простым и включать отображаемый адрес почтового ящика. Например:
https: //exchange/OWA/[email protected]/Default.aspx

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

Эта неправильная нормализация URL-адресов позволяет нам получить доступ к произвольному внутреннему URL-адресу при работе с учетной записью компьютера Exchange Server. Хотя эта ошибка не так сильна, как SSRF в ProxyLogon, и мы могли манипулировать только частью URL-адреса, она все же достаточно мощная, чтобы мы могли проводить дальнейшие атаки с произвольным доступом к серверной части.

by655xjrowms.png

CVE-2021-34523 - повышение привилегий для серверной части Exchange PowerShell

Пока что мы можем получить доступ к произвольным URL-адресам серверной части. Остальная часть - постэксплуатационная. Из-за углубленной защиты Exchange RBAC (ProtocolType в / Autodiscover отличается от / Ecp) непривилегированная операция, используемая в ProxyLogon, которая генерирует сеанс ECP, запрещена. Итак, мы должны найти новый подход к его использованию. Здесь мы сосредоточимся на функции, называемой удаленным взаимодействием Exchange PowerShell!

Удаленное взаимодействие Exchange PowerShell - это функция, которая позволяет пользователям отправлять почту, читать почту и даже обновлять конфигурацию из командной строки. Удаленное взаимодействие Exchange PowerShell построено на WS-Management и реализует множество командлетов для автоматизации. Однако части аутентификации и авторизации по-прежнему основаны на исходной архитектуре CAS.

Следует отметить, что, хотя мы можем получить доступ к серверной части Exchange PowerShell, мы по-прежнему не можем правильно с ней взаимодействовать, поскольку для пользователя NT AUTHORITY \ SYSTEM нет действительного почтового ящика. Мы также не можем внедрить заголовок X-CommonAccessToken, чтобы подделать нашу личность и выдать себя за другого пользователя.

Так что мы можем сделать? Мы тщательно изучили реализацию серверной части Exchange PowerShell и нашли интересный фрагмент кода, который можно использовать для указания личности пользователя через URL-адрес.

Из фрагмента кода, когда серверная часть PowerShell не может найти заголовок X-CommonAccessToken в текущем запросе, она попытается десериализовать и восстановить личность пользователя с помощью параметра X-Rps-CAT строки запроса. Похоже, фрагмент кода предназначен для внутреннего взаимодействия Exchange PowerShell. Однако, поскольку мы можем напрямую обращаться к бэкэнду и указывать произвольное значение в X-Rps-CAT, у нас есть возможность выдавать себя за любого пользователя. Мы используем это, чтобы «понизить» себя с учетной записи SYSTEM, у которой нет почтового ящика, до Exchange Admin.

И теперь мы можем выполнять произвольные команды Exchange PowerShell от имени администратора Exchange!

CVE-2021-31207 - произвольная запись файла после авторизации

Последняя часть цепочки эксплойтов - это поиск метода RCE после авторизации с помощью команд Exchange PowerShell. Это несложно, потому что мы администратор и есть сотни команд, которые можно использовать. Здесь мы нашли команду New-MailboxExportRequest, которая экспортирует почтовый ящик пользователя по указанному пути.
New-MailboxExportRequest -Mailbox [email protected] -FilePath
  \\ 127.0.0.1 \ C $ \ путь \ к \ shell.aspx
Эта команда полезна для нас, поскольку позволяет создать файл по произвольному пути. Чтобы улучшить ситуацию, экспортированный файл представляет собой почтовый ящик, в котором хранятся сообщения пользователя, поэтому мы можем доставлять вредоносные данные через SMTP. Но единственная проблема в том, что кажется, что содержимое почты не хранится в формате открытого текста, потому что мы не можем найти полезную нагрузку в экспортированном файле :(

Мы обнаружили, что вывод находится в формате личных папок Outlook (PST). Прочитав официальную документацию от Microsoft, мы узнали, что PST просто использует простую перестановочную кодировку (NDB_CRYPT_PERMUTE) для кодирования нашей полезной нагрузки. Таким образом, мы можем закодировать полезную нагрузку перед ее отправкой, и когда сервер пытается сохранить и закодировать нашу полезную нагрузку, он превращает ее в исходный вредоносный код.

Exploit

Соберем все вместе!

Шаг 1. Доставка вредоносных данных

Сначала мы доставляем нашу закодированную веб-оболочку в целевой почтовый ящик через SMTP. Если целевой почтовый сервер не поддерживает отправку почты от неавторизованного пользователя, Gmail также можно использовать в качестве альтернативного способа доставки вредоносных данных извне.

Шаг 2 - создание сеанса PowerShell

Поскольку PowerShell основан на протоколе WinRM и реализовать универсальный клиент WinRM непросто, мы используем прокси-сервер, чтобы перехватить соединение PowerShell и изменить трафик. Сначала мы переписываем URL-адрес на путь EwsAutodiscoverProxyRequestHandler, что вызовет ошибку запутывания пути и позволит нам получить доступ к бэкэнду PowerShell. Затем мы вставляем параметр X-Rps-CAT в строку запроса, чтобы выдать себя за любого пользователя. Здесь мы указываем SID администратора Exchange, чтобы стать администратором!


Шаг 3. Выполнение вредоносной команды PowerShell.

В установленном сеансе PowerShell мы выполняем следующие команды PowerShell:

New-ManagementRoleAssignment, чтобы предоставить себе роль импорта и экспорта почтовых ящиков.
New-MailboxExportRequest для экспорта почтового ящика, содержащего нашу вредоносную полезную нагрузку, в webroot, чтобы действовать как наша веб-оболочка.

Дополнительные замечания

После ProxyLogon Defender начал блокировать опасное поведение. Чтобы успешно создать оболочку в Pwn2Own, мы потратили немного времени на обход Defender.

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

https://www.zerodayinitiative.com/blog/2021/8/17/from-pwn2own-2021-a-new-attack-surface-on-microsoft-exchange-proxyshell
Мы ищем точки опоры не с целью перевернуть мир, но чтобы не позволить миру опрокинуть нас.

Комментарии

  • отредактировано 20 авг PM
    +
    https://blog.orange.tw/2021/08/proxyoracle-a-new-attack-surface-on-ms-exchange-part-2.html
    +
    https://blog.orange.tw/2021/08/proxyshell-a-new-attack-surface-on-ms-exchange-part-3.html
    Microsoft Exchange, как одно из наиболее распространенных решений для электронной почты в мире, стал частью повседневной работы и обеспечения безопасности для правительств и предприятий. В январе этого года мы сообщили Microsoft о серии уязвимостей Exchange Server и назвали ее ProxyLogon. ProxyLogon может быть самой серьезной и серьезной уязвимостью в истории Exchange за всю историю. Если вы обращали внимание на новости отрасли, значит, вы их слышали.

    Изучая ProxyLogon с архитектурного уровня, мы обнаружили, что это не просто уязвимость, а поверхность для атаки, которая является совершенно новой, о которой никто никогда раньше не упоминал. Эта поверхность атаки может привести хакеров или исследователей безопасности к большему количеству уязвимостей. Поэтому мы решили сосредоточиться на этой поверхности атаки и в итоге обнаружили как минимум 8 уязвимостей. Эти уязвимости охватывают серверную и клиентскую стороны и даже криптографические ошибки.

    Мы объединили эти уязвимости в 3 атаки:

    ProxyLogon: наиболее известная и эффективная цепочка эксплойтов Exchange.
    ProxyOracle: атака, которая могла восстановить любой пароль в текстовом формате пользователей Exchange.
    ProxyShell: Цепочка эксплойтов, которую мы продемонстрировали на Pwn2Own 2021, чтобы захватить Exchange

    вступление

    Я хотел бы заявить, что все упомянутые уязвимости были зарегистрированы в рамках процесса ответственного раскрытия уязвимостей и исправлены Microsoft. Вы можете найти более подробную информацию об CVE и графике отчета в следующей таблице.

    Время отчета Имя CVE Время исправления CAS [1] Автор сообщения

    5 января 2021 г. ProxyLogon CVE-2021-26855 2 марта 2021 г. Да Orange Tsai, Volexity и MSTIC
    5 января 2021 г. ProxyLogon CVE-2021-27065 2 марта 2021 г. - Orange Tsai, Volexity и MSTIC
    17 января 2021 г. ProxyOracle CVE-2021-31196 13 июля 2021 г. Да Orange Tsai
    17 января 2021 г. ProxyOracle CVE-2021-31195 11 мая 2021 г. - Orange Tsai
    2 апреля 2021 г. ProxyShell [2] CVE-2021-34473 13 апреля 2021 г. Да Orange Tsai работает с ZDI
    2 апреля 2021 г. ProxyShell [2] CVE-2021-34523 13 апреля 2021 г. Да Orange Tsai работает с ZDI
    2 апреля 2021 г. ProxyShell [2] CVE-2021-31207 11 мая 2021 г. - Orange Tsai работает с ZDI.
    2 июня 2021 г. - - - Да Orange Tsai
    2 июня 2021 г. - CVE-2021-33768 13 июля 2021 г. - Orange Tsai и Dlive

    Почему Exchange Server стал горячей темой? С моей точки зрения, вся поверхность атаки ProxyLogon фактически находится на ранней стадии обработки запросов Exchange. Например, если вход Exchange равен 0, а 100 - это основная бизнес-логика, ProxyLogon будет где-то около 10. Опять же, поскольку уязвимость находится в самом начале, я полагаю, что любой, кто внимательно изучил безопасность Exchange, заметит поверхность атаки. По этой же причине я написал в Твиттере, что беспокоюсь о столкновении с ошибками после сообщения в Microsoft. Уязвимость была настолько серьезной, но при этом простая и обнаружена на столь ранней стадии.

    Все вы знаете, что произошло дальше, Volexity обнаружила, что группа APT использовала тот же SSRF (CVE-2021-26855) для доступа к электронной почте пользователей в начале января 2021 года, и сообщила об этом в Microsoft. Microsoft также выпустила срочные исправления в марте. Из опубликованной впоследствии публичной информации мы обнаружили, что, хотя они использовали один и тот же SSRF, группа APT использовала его совсем не так, как мы. Мы завершили цепочку атак ProxyLogon через CVE-2021-27065, в то время как группа APT использовала EWS и две неизвестные уязвимости в своей атаке. Это убедило нас в том, что существует коллизия ошибок в уязвимости SSRF.

    ejxp18h4vzwu.png

    Что касается PoC ProxyLogon, о котором мы сообщили MSRC, он появился в свободном доступе в конце февраля. Нам было так же любопытно, как и всем остальным, после тщательного расследования исключения возможности утечки с нашей стороны. С появлением более четкой временной шкалы и появлением большего количества дискуссий кажется, что это не первый раз, когда что-то подобное происходит с Microsoft. Может быть, вам будет интересно узнать отсюда несколько интересных историй.

    Зачем нужен таргетинг на Exchange Server?

    Почтовый сервер - это очень ценный актив, который хранит самые конфиденциальные секреты и корпоративные данные. Другими словами, управление почтовым сервером означает контроль над жизненным циклом компании. Как наиболее часто используемое решение для электронной почты, Exchange Server долгое время был главной целью хакеров. Согласно нашим исследованиям, в Интернете доступно более четырехсот тысяч серверов Exchange. Каждый сервер представляет компанию, и вы можете себе представить, насколько это ужасно, когда в Exchange Server появилась серьезная уязвимость.

    Обычно я просматриваю существующие статьи и ошибки перед тем, как начать исследование. Есть ли среди всей биржевой истории какой-нибудь интересный случай? Конечно. Хотя большинство уязвимостей основаны на известных векторах атак, таких как десериализация или неправильная проверка ввода, все же есть несколько ошибок, о которых стоит упомянуть.

    Самый особенный

    Самым особенным из них является арсенал Equation Group в 2017 году. Это единственный практический и общедоступный RCE с предварительной авторизацией в истории Exchange. К сожалению, этот арсенал работает только на древнем Exchange Server 2003. Если утечка арсенала случится раньше, это может закончиться еще одним кризисом ядерного уровня.

    Самое интересное

    Самый интересный - CVE-2018-8581, раскрытый кем-то, кто сотрудничал с ZDI. Хотя это был просто SSRF, с этой функцией его можно было объединить с NTLM Relay, и злоумышленник мог превратить скучный SSRF в нечто действительно необычное. Например, он может напрямую управлять всем контроллером домена через учетную запись с низким уровнем привилегий.

    Самое удивительное

    Самым удивительным является CVE-2020-0688, который также был раскрыт кем-то, работающим с ZDI. Основная причина этой ошибки связана с жестко запрограммированным криптографическим ключом в Microsoft Exchange. С помощью этого жестко запрограммированного ключа злоумышленник с низкими привилегиями может захватить весь Exchange Server. И, как видите, даже в 2020 году глупый, жестко закодированный криптографический ключ все еще можно будет найти в таком важном программном обеспечении, как Exchange. Это указывало на то, что в Exchange отсутствует проверка безопасности, что также вдохновило меня на более глубокое изучение безопасности Exchange.

    Где новая поверхность атаки

    Exchange - очень сложное приложение. С 2000 года Exchange выпускает новую версию каждые 3 года. Всякий раз, когда Exchange выпускает новую версию, архитектура сильно меняется и становится другой. Изменения архитектуры и итераций затрудняют обновление Exchange Server. Чтобы обеспечить совместимость между новой и старой архитектурой, Exchange Server был понесен ряд проектных долгов, что привело к обнаруженной нами новой поверхности атаки.

    upload_6dd25fe5fd7416cd0b4baf6e9a61adfc.png
    Мы ищем точки опоры не с целью перевернуть мир, но чтобы не позволить миру опрокинуть нас.
  • отредактировано 20 авг PM
    На чем мы сосредоточились в Microsoft Exchange? Мы сосредоточились на службе клиентского доступа, CAS. CAS - это фундаментальный компонент Exchange. Вернувшись к версии 2000/2003, CAS был независимым Frontend-сервером, отвечающим за всю логику веб-рендеринга Frontend. После нескольких переименований, интеграции и различий в версиях CAS был понижен до уровня службы с ролью почтового ящика. В официальной документации Microsoft указано, что:
    Серверы почтовых ящиков содержат службы клиентского доступа, которые принимают клиентские подключения для всех протоколов. Эти внешние службы отвечают за маршрутизацию или проксирование подключений к соответствующим внутренним службам на сервере почтовых ящиков.

    Из повествования вы могли понять важность CAS, и вы могли представить, насколько это важно, когда в такой инфраструктуре обнаруживаются ошибки. CAS была тем местом, на котором мы сосредоточились и где появилась поверхность атаки.

    Архитектура CAS

    CAS - это фундаментальный компонент, отвечающий за принятие всех подключений со стороны клиента, независимо от того, являются ли они HTTP, POP3, IMAP или SMTP, и проксирует подключения к соответствующей серверной службе. Как исследователь веб-безопасности, я сосредоточился на веб-реализации CAS.

    upload_7a3f4330935bae8bb28c68eb18b0d41f.png

    Сеть CAS построена на Microsoft IIS. Как видите, внутри IIS есть два веб-сайта. «Веб-сайт по умолчанию» - это интерфейс, о котором мы говорили ранее, а «Серверная часть Exchange» - это бизнес-логика. Внимательно изучив конфигурацию, мы замечаем, что Frontend связывается с портами 80 и 443, а Backend прослушивает порты 81 и 444. Все порты связываются с 0.0.0.0, что означает, что любой может получить доступ к Frontend и Backend. Обменять напрямую. Разве это не опасно? Помните об этом вопросе, и мы ответим на него позже.

    Exchange реализует логику Frontend и Backend через модуль IIS. В Frontend и Backend есть несколько модулей для выполнения различных задач, таких как фильтр, проверка и ведение журнала. Фронтенд должен содержать прокси-модуль. Модуль Proxy принимает HTTP-запрос со стороны клиента и добавляет некоторые внутренние настройки, а затем пересылает запрос в Backend. Что касается Backend, все приложения включают в себя модуль Rehydration Module, который отвечает за анализ запросов Frontend, заполнение информации о клиенте и продолжение обработки бизнес-логики. Позже мы рассмотрим, как работают прокси-модуль и модуль регидратации.

    upload_bb52a1d73b4ba00ddfc1675f805fe6d6.png

    Модуль Frontend Proxy

    Прокси-модуль выбирает обработчик на основе текущего ApplicationPath для обработки HTTP-запроса со стороны клиента. Например, при посещении / EWS будет использоваться EwsProxyRequestHandler, поскольку для / OWA будет запускаться OwaProxyRequestHandler. Все обработчики в Exchange наследуют класс от ProxyRequestHandler и реализуют его основную логику, например, как обрабатывать HTTP-запрос от пользователя, какой URL-адрес от Backend к прокси-серверу и как синхронизировать информацию с Backend. Класс также является наиболее центральной частью всего модуля Proxy, мы разделим ProxyRequestHandler на 3 раздела:

    upload_0aa5c69e644b59186216c5a3aa1639a9.png

    Раздел запросов внешнего интерфейса

    Раздел запроса проанализирует HTTP-запрос от клиента и определит, какой файл cookie и заголовок могут быть проксированы на серверную часть. Frontend и Backend полагались на заголовки HTTP для синхронизации информации и внутреннего статуса прокси. Поэтому Exchange определил черный список, чтобы избежать неправильного использования некоторых внутренних заголовков.

    HttpProxy \ ProxyRequestHandler.cs

    На последнем этапе запроса Proxy Module вызовет метод AddProtocolSpecificHeadersToServerRequest, реализованный обработчиком, чтобы добавить информацию, которая будет передаваться с Backend в заголовок HTTP. В этом разделе также будет сериализована информация от текущего пользователя, вошедшего в систему, и помещена в новый HTTP-заголовок X-CommonAccessToken, который позже будет перенаправлен на серверную часть.

    Например, если я вхожу в Outlook Web Access (OWA) с именем Orange, X-CommonAccessToken, который прокси-сервер Frontend для Backend будет:

    upload_8796d1b24d746c44f0f856c14da2cec1.png

    Раздел Frontend Proxy

    В разделе «Прокси» сначала используется метод GetTargetBackendServerURL, чтобы вычислить, на какой URL-адрес Backend должен быть перенаправлен HTTP-запрос. Затем инициализируйте новый запрос HTTP-клиента с помощью метода CreateServerRequest.

    HttpProxy \ ProxyRequestHandler.cs

    Exchange также сгенерирует билет Kerberos через класс обслуживания HTTP серверной части и поместит его в заголовок авторизации. Этот заголовок предназначен для предотвращения прямого доступа анонимных пользователей к Backend. С помощью билета Kerberos серверная часть может проверять доступ из внешнего интерфейса.

    HttpProxy \ ProxyRequestHandler.cs

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

    Раздел ответа внешнего интерфейса

    Последний - это раздел Ответа. Он получает ответ от серверной части и решает, какие заголовки или файлы cookie разрешено отправлять обратно во фронтенд.


    Модуль внутренней регидратации

    Теперь давайте продолжим и проверим, как Backend обрабатывает запрос от Frontend. Backend сначала использует метод IsAuthenticated, чтобы проверить, аутентифицирован ли входящий запрос. Затем серверная часть проверит, снабжен ли запрос расширенным правом под названием ms-Exch-EPI-Token-Serialization. При настройке по умолчанию только учетная запись компьютера Exchange будет иметь такую ​​авторизацию. Вот почему билет Kerberos, сгенерированный Frontend, может пройти контрольную точку, но вы не можете получить доступ к Backend напрямую с учетной записью с низким уровнем авторизации.

    После прохождения проверки Exchange восстановит идентификацию входа, используемую во Frontend, путем десериализации заголовка X-CommonAccessToken обратно в исходный токен доступа, а затем поместит его в объект httpContext для перехода к бизнес-логике в Backend.

    Аутентификация \ BackendRehydrationModule.cs

    Поверхность атаки

    После краткого введения в архитектуру CAS мы теперь понимаем, что CAS - это просто хорошо написанный HTTP-прокси (или клиент), и мы знаем, что реализовать прокси непросто. Так что мне было интересно:

    Могу ли я использовать один HTTP-запрос для доступа к разным контекстам во Frontend и Backend соответственно, чтобы вызвать некоторую путаницу?


    Если бы мы могли это сделать, maaaaaybe-может быть, я мог бы обойти некоторые ограничения Frontend для доступа к произвольным Backends и злоупотребить некоторым внутренним API. Или мы можем перепутать контекст, чтобы использовать несогласованность определения опасных HTTP-заголовков между Frontend и Backend для дальнейших интересных атак.

    Помня об этих мыслях, приступим к охоте!
    Мы ищем точки опоры не с целью перевернуть мир, но чтобы не позволить миру опрокинуть нас.
  • отредактировано 20 авг PM
    ProxyLogon

    Первый эксплойт - это ProxyLogon. Как указывалось ранее, это может быть самая серьезная уязвимость в истории Exchange за всю историю. ProxyLogon связан с двумя ошибками:

    CVE-2021-26855 - SSRF с предварительной аутентификацией приводит к обходу аутентификации
    CVE-2021-27065 - Запись произвольного файла после авторизации приводит к RCE


    CVE-2021-26855 - SSRF до авторизации

    Существует более 20 обработчиков, соответствующих различным путям приложений во Frontend. При просмотре реализаций мы обнаружили, что метод GetTargetBackEndServerUrl, который отвечает за вычисление Backend URL в статическом обработчике ресурсов, напрямую назначает Backend target с помощью файлов cookie.

    Теперь вы понимаете, насколько проста эта уязвимость после изучения архитектуры!

    HttpProxy \ ProxyRequestHandler.cs

    Из фрагмента кода видно, что свойство BackEndServer.Fqdn объекта AnchoredRoutingTarget назначается напрямую из файла cookie.

    HttpProxy \ OwaResourceProxyRequestHandler.cs

    Хотя мы можем управлять только частью URL-адреса, связанной с хостом, но подождите, разве управление парсером URL-адресов не является именно тем, в чем я разбираюсь? Exchange создает внутренний URL-адрес с помощью встроенного UriBuilder. Однако, поскольку C # не проверял хост, мы можем заключить весь URL-адрес в некоторые специальные символы для доступа к произвольным серверам и портам.

    https: // [foo] @ example.com: 443 / путь #]: 444 / owa / auth / x.js

    Пока что у нас есть супер SSRF, который может контролировать почти все HTTP-запросы и получать все ответы. Самым впечатляющим является то, что интерфейс Exchange генерирует для нас билет Kerberos, а это означает, что даже когда мы атакуем защищенную и присоединенную к домену HTTP-службу, мы все равно можем взломать ее с аутентификацией учетной записи машины Exchange.

    Итак, какова основная причина этого произвольного назначения Backend? Как уже упоминалось, Exchange Server меняет свою архитектуру при выпуске новых версий. Он может иметь разные функции в разных версиях даже с одним и тем же компонентом под одним и тем же именем. Microsoft приложила большие усилия для обеспечения архитектурной совместимости между новыми и старыми версиями. Этот файл cookie является быстрым решением, и долг разработки Exchange по созданию Frontend в новой архитектуре может определить, где находится старый Backend.

    CVE-2021-27065 - произвольная запись файла после авторизации

    Благодаря супер SSRF, позволяющему получить доступ к Backend без ограничений. Следующее - найти ошибку RCE, чтобы связать ее вместе. Здесь мы используем внутренний API Backend /proxyLogon.ecp, чтобы стать администратором. API также является причиной того, что мы назвали его ProxyLogon.

    Поскольку мы используем обработчик статических ресурсов Frontend для доступа к Backend панели управления ECExchange (ECP), заголовок msExchLogonMailbox, который является специальным заголовком HTTP в Backend ECP, не будет заблокирован Frontend. Воспользовавшись этим незначительным несоответствием, мы можем указать себя как пользователя SYSTEM и сгенерировать действительный сеанс ECP с внутренним API.

    Из-за несогласованности между Frontend и Backend мы можем получить доступ ко всем функциям ECP путем подделки заголовка и внутреннего злоупотребления Backend API. Затем мы должны найти ошибку RCE в интерфейсе ECP, чтобы связать их вместе. ECP обертывает команды Exchange PowerShell как абстрактный интерфейс с помощью /ecp/DDI/DDIService.svc. DDIService определяет несколько конвейеров выполнения PowerShell с помощью XAML, чтобы к нему можно было получить доступ через Интернет. При проверке реализации DDI мы обнаружили, что тег WriteFileActivity не проверял должным образом путь к файлу и приводил к произвольной записи файла.

    DDIService \ WriteFileActivity.cs

    Есть несколько способов вызвать уязвимость записи произвольного файла. Здесь мы используем ResetOABVirtualDirectory.xaml в качестве примера и записываем результат Set-OABVirtualDirectory в корневой каталог в качестве нашей веб-оболочки.

    upload_1425afd691cdfb0d742d5adb624a6902.png

    Теперь у нас есть работающая цепочка эксплойтов RCE до авторизации. Злоумышленник, не прошедший проверку подлинности, может выполнять произвольные команды на сервере Microsoft Exchange Server через открытый порт 443. Вот демонстрационное видео:

    Эпилог

    ProxyLogon, как первый блог этой серии, прекрасно показывает, насколько серьезной может быть эта поверхность для атаки. У нас будет больше примеров. Будьте на связи!

    https://blog.orange.tw/2021/08/proxylogon-a-new-attack-surface-on-ms-exchange-part-1.html
    Мы ищем точки опоры не с целью перевернуть мир, но чтобы не позволить миру опрокинуть нас.
  • отредактировано 31 авг PM
    Ошибка Microsoft Exchange ProxyToken может позволить хакерам переслать сообщения из электронной почты пользователя

    Появились технические подробности о серьезной уязвимости в Microsoft Exchange Server, получившей название ProxyToken, которая не требует аутентификации для доступа к электронной почте из целевой учетной записи.

    Злоумышленник может воспользоваться уязвимостью, создав запрос к веб-службам в приложении панели управления Exchange (ECP) и похитив сообщения из почтового ящика жертвы.

    Путаница при делегировании

    ProxyToken, отслеживаемый как CVE-2021-33766, дает неаутентифицированным злоумышленникам доступ к параметрам конфигурации почтовых ящиков пользователей, где они могут определить правило пересылки электронной почты.

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

    Ошибка была обнаружена Ле Суаном Туеном, исследователем из Центра информационной безопасности Вьетнамской почтовой и телекоммуникационной группы (VNPT-ISC), и о ней было сообщено в рамках программы Zero-Day Initiative (ZDI) в марте.

    Он обнаружил, что внешний сайт Microsoft Exchange (Outlook Web Access, панель управления Exchange) в основном функционирует как прокси для внутреннего сайта (Exchange Back End), которому он передает запросы аутентификации.

    В развертываниях Microsoft Exchange, где активна функция «Делегированная аутентификация», интерфейс пересылает запросы, требующие аутентификации, в бэкэнд, который идентифицирует их по наличию cookie «SecurityToken».

    Если в запросе в «/ ecp» есть непустой файл cookie «SecurityToken», внешний интерфейс делегирует решение об аутентификации серверной части.

    Однако конфигурация Microsoft Exchange по умолчанию не загружает для внутреннего сайта ECP модуль, ответственный за делегирование процесса проверки (DelegatedAuthModule).

    «Таким образом, когда интерфейсная часть видит файл cookie SecurityToken, она знает, что только серверная часть отвечает за аутентификацию этого запроса. Между тем, серверная часть совершенно не знает, что ей необходимо аутентифицировать некоторые входящие запросы на основе cookie SecurityToken, поскольку DelegatedAuthModule не загружается в установках, которые не были настроены для использования специальной функции делегированной аутентификации »- Zero-Day Initiative

    Использование уязвимости ProxyToken не обходится без другой проблемы, хотя и незначительной: для запросов страницы / ecp требуется билет, известный как «ECP canary», который можно получить при запуске ошибки HTTP 500.

    Оказывается, запросы без билета вызывают ошибку HTTP 500, содержащую допустимую строку, необходимую для успешной выдачи неаутентифицированного запроса.

    ProxyTokenTicket.jpg

    Патч доступен от Microsoft с июля, согласно публичному сообщению компании. Том Селлерс из Rapid7 отмечает, что номера версий и даты указывают на то, что патчи были выпущены еще в апреле.

    Уязвимость не критична. NIST подсчитал, что его серьезность составляет 7,5 из 10. Это связано с тем, что злоумышленнику требуется учетная запись на том же сервере Exchange, что и жертва.

    Например, запрос злоумышленника выглядит так:

    ProxyTokenTriggerReq.jpg

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

    Попытки использовать

    Хотя технические подробности для ProxyToken были опубликованы только сегодня, попытки использования уязвимостей были зафиксированы еще три недели назад.

    https://www.bleepingcomputer.com/news/security/microsoft-exchange-proxytoken-bug-can-let-hackers-steal-user-email/
    Мы ищем точки опоры не с целью перевернуть мир, но чтобы не позволить миру опрокинуть нас.
Войдите или Зарегистрируйтесь чтобы комментировать.