Полностью вооружённый CVE-2021-40444

Генератор вредоносных docx для эксплуатации CVE-2021-40444 (удалённое выполнение кода в Microsoft Office Word), работает с произвольными DLL-файлами.

Предыстория

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

Пока что единственные ценные ресурсы, которые я видел для создания полностью работоспособного генератора:

• Блог от Ret2Pwn
• Твит от j00sean

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

Exploit Chain

1. Docx открыт
2. Связь, хранящаяся в document.xml.rels, указывает на вредоносный HTML
3. Запускается предпросмотр IE, чтобы открыть HTML-ссылку
4. JScript в HTML содержит объект, указывающий на CAB-файл, и iframe, указывающий на INF-файл, с префиксом директивы ".cpl:"
5. CAB-файл открывается, INF-файл сохраняется в каталоге %TEMP%\Low
6. Из-за уязвимости обхода пути (ZipSlip) в CAB, можно сохранить INF в %TEMP%
7. Затем INF-файл открывается с директивой ".cpl:", что вызывает боковую загрузку INF-файла через rundll32 (если это DLL)

Упущенные требования

Существует довольно много упущенных требований для работы этого эксплойта, из-за которых даже хорошие PoC, например от lockedbyte, не работали должным образом.

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

HTML-файл

Согласно этому твиту от Will Dormann, HTML должен быть размером не менее 4096 байт, чтобы запустить «Предпросмотр» в MS Word.

CAB-файл

CAB-файл необходимо пропатчить на уровне байтов, чтобы избежать ошибок извлечения и добиться ZipSlip:

• filename.inf should become ../filename.inf
• filename.inf должно быть ровно <12-символов>.inf Не совсем верно, важнее изменить coffCabStart
• CFFOLDER.typeCompress должен быть 0 (несжатый)
• CFFOLDER.coffCabStart should be increased by 3 (due to the added '../'')
• CFFOLDER.cCfData должно быть 2
• CFFILE.cbFile should be greater than the whole CFHEADER.cbCabinet
• CFDATA.csum должна быть пересчитана (или обнулена) [НЕОБЯЗАТЕЛЬНО]

Причин для этих ограничений много, и я не потратил достаточно времени, чтобы глубоко понять их все, но давайте рассмотрим самые важные:

• TypeCompress: Если CAB сжат, трюк с открытием его внутри объектного файла для записи INF не сработает Ложно, мне удалось добиться того же результата с сжатым MSZIP образцом
• CoffCabStart: CoffCabStart задаёт абсолютную позицию первой структуры CFDATA; поскольку мы добавили '../', нам нужно увеличить это значение на 3, чтобы указывать на файл (это скорее предположение)
• cCfData: Так как есть только 1 файл, у нас должна быть только 1 CFDATA, я не совсем уверен, почему это должно быть 2 Действительно, можно оставить 1
• cbFile: Интересно, что если извлечение CAB завершится без ошибок, INF-файл будет помечен на удаление WORD, что сорвёт эксплойт. Единственный способ предотвратить это — заставить WORD думать, что извлечение не удалось. Если значение cbFile задано больше, чем сам CAB-файл, экстрактор достигнет EOF до того, как прочитает все байты, определённые в cbFile, что вызовет ошибку извлечения.
• [НЕОБЯЗАТЕЛЬНО] Похоже, что это значение не проверяется MS Word. В любом случае, для корректного CAB значение csum должно быть пересчитано. К счастью, как отметил j00sean и согласно документации Microsoft, это значение может быть 0.

ПРИМЕЧАНИЕ1: Defender теперь определяет, содержит ли CAB-файл PE, используя значение _IMAGE_DOS_HEADER.e_magic как сигнатуру, что потенциально предотвращает встраивание PE-файлов в CAB. Можно ли обойти эту сигнатуру? Я не уверен, но, как уже отмечалось, это исправленная уязвимость, поэтому я не планирую тратить на это больше времени. Любознательному читателю предоставляется возможность развить это дальше.

ПРИМЕЧАНИЕ2: Патч Microsoft блокирует произвольные URI-схемы, по-видимому, используя подход чёрного списка (это всего лишь предположение)

Атака DLL

Основная цепочка атаки, связанная с CVE-2021-40444, — это атака DLL, загружаемая через URI-схему .cpl. Чтобы использовать её, атакующему нужно сгенерировать специально подготовленную DLL. Если хотите протестировать, попробуйте мой скрипт evildll-gen.

JScript, VBScript, Javaw, MSIexec, ...

Как отметил Max Maluin, возможно взаимодействие с несколькими типами файлов, используя IE и связанные URI на основе расширений файлов. Хотя это может быть хорошим способом эксплуатации IE, у него есть ограничения.

Действительно, следует отметить, что метод, используемый в эксплойте для загрузки файлов, основан на обновлениях элементов управления ActiveX и не может использоваться для загрузки произвольных файлов. Согласно документации Microsoft, тег codebase может указывать только на несколько типов файлов: OCX, INF и CAB.

Даже если мы можем напрямую загрузить OCX или INF-файл, мы всё равно не можем быть уверены, что файл будет загружен в нужное место в системе. С помощью CAB-эксплойта можно переместить .inf-файл в известный путь, используя обход пути, но в любом другом случае файл будет сохранён в случайном каталоге, что делает его практически невозможным для ссылки.

На сегодняшний день я не нашёл способа объединить загрузку и выполнение БЕЗ CAB-файла.

Примечание: Говоря только об IE, HTML-смуглинг может быть возможным сценарием эксплуатации уязвимости.

Атака без CAB с использованием гибридного RAR-файла

Эта техника была впервые раскрыта Eduardo Braun в Twitter и далее объяснена в этой статье.

Обратите внимание, что при использовании этой техники цепочка атаки немного отличается. Эта атака требует, чтобы пользователь загрузил специально созданный RAR-файл, полученный путём объединения валидного WSF-скрипта и валидного RAR-файла. После открытия RAR будет содержать DOCX со ссылкой на HTML, который, в свою очередь, попытается загрузить RAR-файл как WSF-скрипт.

Резюмируя:

1. Специально созданный RAR-файл загружается (скорее всего, в папку Загрузки)
2. DOCX извлекается и открывается
3. Связь, хранящаяся в document.xml.rels, указывает на вредоносный HTML
4. Запускается предпросмотр IE, чтобы открыть HTML-ссылку
5. JScript в HTML содержит скрипт/iframe, указывающий на RAR-файл, с префиксом URI-схемы ".wsf:"
6. Поскольку RAR был спроектирован так, чтобы быть одновременно валидным RAR и валидным WSF-скриптом, скрипт выполняется

Какие PoC эксплойтов реализованы в инструменте

Утилита генератора в настоящее время может воспроизводить следующие атаки: