playboisk8/poc-cve-2017-8464-opencalculatorAusnutzen der .lnk-Schwachstelle und der Behandlungsmechanismen des Betriebssystems in Bezug auf explorer.exe und USB-Laufwerke.
Erstelle 1 Shortcut + 1 .DLL mit schädlichem Payload => Auf USB legen und an das Opfer senden => Opfer öffnet USB => Payload wird automatisch ausgelöst!
Zunächst müssen wir genau wissen, woher dieser Fehler stammt! Er beruht auf der Funktion Plug-and-Play (Einstecken und Loslegen). Das Betriebssystem erkennt Geräte automatisch, weist Ressourcen zu und lädt den passenden Treiber, sodass sie sofort funktionieren, ohne den Computer neu zu starten. Wenn man ein USB-Laufwerk einsteckt und den Ordner mit dem Windows-Explorer explorer.exe öffnet, durchsucht das Betriebssystem die Dateien, um die entsprechenden Symbole (Icons) für den Benutzer anzuzeigen!
Seit älteren Windows-Versionen wollte Microsoft, dass Verknüpfungen (Shortcuts .lnk), die auf Funktionen der Systemsteuerung (Control Panel) verweisen (im Wesentlichen .cpl- oder .dll-Dateien), dynamische Symbole flexibel anzeigen können. Daher wurde in der zentralen Shell-Bibliothek von Windows, shell32.dll, eine Funktion namens CPL_LoadCPLModule entworfen.
LoadLibrary blind verwenden: Um das Symbol aus einer Control-Panel-Applet-Datei zu erhalten, liest das Betriebssystem nicht einfach eine statische Bilddatei, sondern verwendet die Funktion LoadLibraryW, um die gesamte DLL direkt in den Speicherbereich des Prozesses explorer.exe zu laden. Nach dem Laden ruft es eine Standard-Exportfunktion namens CPlApplet auf, um das Symbol zu erhalten und auf dem Bildschirm zu zeichnen.
Um zu beweisen, dass LoadLibraryW tatsächlich mit der obigen Exploit-Kette zusammenhängt:
1/ Starte
x64dbg mit Administratorrechten2/ An
explorer.exeanhängen3/ Befehl
bp LoadLibraryWeingeben4/ F9 drücken, damit
explorer.exeweiterläuft5/ USB einstecken – der
Breakpointwird sofort ausgelöst!
Ich hatte das Problem, dass die Exploit-Kette völlig still blieb. Obwohl ich alles Mögliche zu prüfen und zu debuggen versuchte, konnte ich keinen Fix finden! Danach versuchte ich, PoCs von anderen zu finden und auszuprobieren, aber auch das schlug fehl!
Als ich jedoch zum Mittagessen ging und zurückkam, hatte ich meine Konzentration und Ruhe wiedergefunden. Ich begann mich zu fragen, warum der PoC von diesem Typen funktionierte, auf meinem Rechner aber nicht. Okay, ich begann, seine .lnk und .dll ein wenig zu reversen, und entdeckte dabei zwei Dinge!
1 / Meine .dll war länger als seine! Aber das macht nichts, das ist nicht das Problem!
2 / Als ich die .lnk in HxD warf, um die Strings zu lesen, entdeckte ich, dass dieser Typ keinen relativen Pfad verwendete, sondern einen absoluten!
Relativ: ../example.dll
Absolut: O:/example.dll
Okay, der Fix besteht nun darin, dass wir wissen müssen, welcher Laufwerksbuchstabe dem USB-Laufwerk automatisch zugewiesen wird, wenn es am Rechner des Opfers eingesteckt wird. Dann setzen wir den absoluten Pfad ein, und es klappt. Da bei meinem Win7 das USB-Laufwerk beim Einstecken immer als Laufwerk F: erschien, lautete meine Build-Syntax:
python Make_PoC.py FakeGoogleChrome F:\Pwned.dll
Da dieser Fehler auf einem Architektur-Designfehler (Logic/Architecture Flaw) beruht und nicht auf einem Pufferüberlauf, musste Microsoft die Behandlung der Systemsteuerung (Control Panel) komplett ändern:
.cpl- oder .dll-Dateien entweder eine gültige digitale Signatur von Microsoft besitzen oder sich in streng geschützten Systemverzeichnissen (wie System32) befinden, um den Fehler „Binary Planting“ von USB zu vermeiden.explorer.exe zu laden [cite: 1058], führen neuere Windows-Versionen Control-Panel-Applets über einen isolierten Zwischenprozess aus (wie dllhost.exe oder rundll32.exe). Wenn eine DLL abstürzt oder Schadcode enthält, stürzt nur dieser Zwischenprozess ab, und das gesamte Benutzeroberflächensystem kann nicht übernommen werden.Forschung VN
PoC
Tool zum Erstellen der verwundbaren .lnk