
Technischer Bericht und Proof-of-Concept für CVE-2022-44666, eine Escape-Schwachstelle im href-Attribut des Syslink-Steuerelements von Windows-Kontakten, die Remote-Codeausführung über präparierte VCF/.contact-Dateien und den LDAP-Protokollhandler ermöglicht.
Dies ist die Geschichte über einen weiteren vergessenen 0day, der vor mehr als 4 Jahren von [John Page (aka hyp3rlinx)][R.1] vollständig offengelegt wurde. Um den Bericht zu verstehen, müssen Sie bedenken, dass ich dumm bin :-) Und meine Dummheit treibt mich dazu, längere Wege zu gehen, um einfache Probleme zu lösen, führt mich aber auch dazu, andere Wege zu finden, einige Bugs auszunutzen. Warum sage ich das? Weil ich nicht schnell verstanden habe, dass der Weg, eine .contact-Datei zu erstellen, einfach darin besteht, zum Kontakt-Ordner zu navigieren, um den Kontakt zu erstellen. Stattdessen habe ich diese Information verwendet, um zuerst eine VCF-Datei zu erstellen, und dann dachte ich fälschlicherweise, dass dies eine Art Variante sei. Das lag auch daran, dass mein Gehirn nicht verstehen kann, dass einige 0days so lange vergessen werden ¯\(ツ)/¯ Nachdem das erledigt war und nach den „wontfix“-Antworten von [MSRC][R.2] und [ZDI][R.3], wurden weitere Untersuchungen durchgeführt, um die Schwere zu erhöhen, und schließlich wurden .contact-Dateien und der Windows-URL-Protokollhandler „ldap“ erreicht.
Während ich den Exploit-Code für [diese Schwachstelle][R.4] las, die tatsächlich als 0day veröffentlicht wurde und [ZDIs Bericht][R.5] zu finden ist.
Update 2022/07/21: Nach der Meldung dieses Falls an MS wiesen mich die MSRC-Leute zu Recht darauf hin, dass Windows Kontakte nicht das Standardprogramm zum Öffnen von VCF-Dateien ist.

Weitere Untersuchungen zeigen dennoch, dass das Standardprogramm für VCF-Dateien unter Win7 ESU & WinServer2019 Windows Kontakte (wab.exe) ist, ansonsten wird MS People (PeopleApp.exe) verwendet. Hier ist eine vollständige Tabelle dieser Tests:
Jedenfalls argumentieren sie weiterhin, dass ein gewisses Social Engineering damit verbunden ist, wie das Öffnen einer manipulierten VCF-Datei und das Klicken auf einige Links, um den Bug auszunutzen, sodass es die MSRC-Bug-Bar für ein Sicherheitsupdate nicht erfüllt.

Update 2022/07/25: Nun, nach weiteren Recherchen ist es derselbe Bug. Ich konnte endlich einen Proof-of-Concept für eine .contact-Datei finden. Es ist tatsächlich möglich, eine .contact-Datei mit HTML-Entities korrekt zu parsen. Beachten Sie, dass dies das vorherige Problem löst (Update 2022/07/21) und dieses Dateiformat (.contact) von Windows Kontakte geöffnet wird, dem Standardprogramm für diese Dateierweiterung, selbst wenn MS Office auf dem System installiert ist. Es wird lediglich eine erste Dateizuordnung benötigt, falls noch nicht geschehen, aber das einzige standardmäßig installierte Programm dafür ist Windows Kontakte.
Update 2022/07/25: Diese weiteren Recherchen führten mich zu einem Punkt, den ich schon vor einiger Zeit erreichen wollte: Verwenden Sie einen URL-Protokollhandler, um automatisch manipulierte Kontaktdaten zu öffnen und den Bug auszunutzen. Ich konnte es schließlich dank des ldap-URI-Schemas zum Laufen bringen, das standardmäßig mit der Windows Kontakte-Anwendung verknüpft ist. Indem man also einen betrügerischen LDAP-Server einrichtet und die Payload-Daten unter den Attributen mail, url oder wwwhomepage bereitstellt, wird die Auswirkung des Exploits erhöht, da es nun nicht mehr erforderlich ist, eine bösartige VCF-/Contact-Datei doppelt anzuklicken; wir können dies über URL-Protokolle ausliefern.
Update 2023/02/08: Als Zeichen des guten Willens von MSRC wurde [John Page (aka hyp3rlinx)][R.1] in die Anerkennungsseite für die Entdeckung von [CVE-2022-44666][R.10] aufgenommen.

Der Bericht ist im Grunde derselbe wie die obigen Links, jedoch habe ich das Social Engineering etwas verbessert. Tatsächlich bestand das Erste, was ich tat, darin, die Art und Weise zu verbessern, wie die Links gesehen werden, ähnlich wie bei einer XSS-Schwachstelle. Es handelt sich tatsächlich um eine HTML-Injection, sodass es möglich ist, das erste Ankerelement zu schließen und ein neues einzufügen. Dann wollte ich die Sichtbarkeit für diese HTML-Elemente entfernen, sodass das Setzen eines möglichst langen „innerHTML“ ausreichen würde, um sie zu verbergen (da es Zeichenbegrenzungen gibt).
Dies ist die endgültig verwendete Payload:```html URL;WORK:">CLICKMEEEEE...
Um zu sehen, was passiert, führen Sie procmon aus und richten Sie ein gefälschtes Ziel des href-Attributs wie folgt ein:```html
URL;WORK:"></a><a href="https://github.com/j00sean/cve-2022-44666/blob/main/foo.exe">CLICKMEEEEE...</a>
Nachdem der Link angeklickt wurde, wird in procmon eine Ausgabe wie diese beobachtet:
