rsmudge/cve-2020-0796-bofCobalt Strike Beacon Object File, das CVE-2020-0796 SMBGhost lokale Privilegieneskalation mit zwei Weaponisierungs-Pfaden für Token-Diebstahl und Session-Elevation implementiert.
Das ist Raphaels Bastelei mit dem SMBGhost LPE.
Ich begann mit dem Quellcode aus dem Metasploit Framework:
cve-2020-0796: SMBv3 Compression Buffer Overflow (SMBGhost) (CVE 2020-0796) https://github.com/rapid7/metasploit-framework/tree/master/external/source/exploits/CVE-2020-0796 [BSD Licensed]
Und hier ist, was ich getan habe:
Dazu musste ich mehrere Win32-APIs im Dynamic Function Resolution MODULE$Function-Format deklarieren. Positiv zu vermerken ist, dass dadurch ein Teil des Codes reduziert wurde, um Dinge in NTDLL aufzurufen, da die DFR das für uns erledigt. :)
Ich habe das ungenutzte 1000-Elemente-ptr-Array aus get_handle_addr entfernt. Dies führte dazu, dass cl.exe eine __chkstk-Funktion einfügte, da die lokalen Variablen ein 8KB-Limit überschritten. BOFs haben diese Funktion nicht zur Verfügung.
Anschließend habe ich ein paar Beacon-spezifische APIs (z.B. BeaconPrintf, BeaconInjectProcess usw.) eingebunden, um Dinge auf die Beacon-native Weise zu erledigen.
Ich musste ein paar Funktionen schreiben, um die libc-Sachen zu kompensieren, die ich nicht habe (aufgrund von... BOFs).
Verwende den Alias 'smbghost' in Beacon ohne Argumente, um diesen Exploit auszuführen und nur das Token des Beacon-Prozesses zu beeinflussen. Wenn der Exploit erfolgreich ist, erhält dein aktuelles Prozess-Token Superkräfte, die es vorher nicht hatte. Du kannst dann zum Beispiel in andere Prozesse injizieren (sogar in anderen Desktop-Sitzungen) oder einen untergeordneten Prozess unter winlogon.exe starten. Möglicherweise musst du smbghost mehrmals ausführen, da der Exploit nicht immer beim ersten Durchlauf erfolgreich ist.
Optional kannst du 'elevate smbghost' verwenden, um eine neue Beacon-Sitzung über die in Cobalts Strikes Aggressor Script verfügbare Privilege-Escalation-API zu erhalten. Das ist in Ordnung für eine schnelle Demo, es passt in die Workflows des Produkts usw., aber... es injiziert in winlogon.exe. Das Injizieren in winlogon.exe ist keine Invariante dieser speziellen Eskalation. Ich vermute, dass alle öffentlichen POCs dies tun, weil CreateRemoteThread nicht über Prozessgrenzen hinweg funktioniert und wer will schon den zusätzlichen Boilerplate-Code für Parent-Process-Spoofing schreiben? winlogon.exe ist die einfache, offensichtliche Wahl, um zu demonstrieren, dass wir erhöhte Rechte haben.
Um dies mit Visual Studio zu kompilieren:
Verwende make.bat aus der x64 Cross Tools Command Prompt.
Dies wird expoit.x64.o in das Verzeichnis dist/ ausgeben.
Ich habe Visual Studio 2013 verwendet. Andere Compiler/Versionen wurden nicht getestet. Ich habe x86 nicht versucht/getestet.
