
Eine verbesserte Version von RottenPotatoNG, mit etwas Extra, d.h. ein weiteres Tool zur lokalen Privilegienerweiterung, von Windows-Dienstkonten zu NT AUTHORITY\SYSTEM.
Eine gezuckerte Version von RottenPotatoNG, mit etwas Saft, d.h. ein weiteres Tool zur lokalen Privilegienausweitung, von Windows-Dienstkonten zu NT AUTHORITY\SYSTEM
RottenPotatoNG und seine Varianten nutzen die Privilegienausweitungskette basierend auf dem BITS-Dienst, der den MiTM-Listener auf 127.0.0.1:6666 hat und wenn Sie SeImpersonate- oder SeAssignPrimaryToken-Berechtigungen besitzen. Während einer Windows-Build-Überprüfung fanden wir ein Setup, bei dem BITS absichtlich deaktiviert und Port 6666 belegt war.
Wir entschieden uns, RottenPotatoNG zu bewaffnen: Sagen Sie Hallo zu Juicy Potato.
Für die Theorie siehe Rotten Potato - Privilege Escalation from Service Accounts to SYSTEM und folgen Sie der Kette von Links und Referenzen.
Wir haben herausgefunden, dass es neben BITS mehrere COM-Server gibt, die wir missbrauchen können. Sie müssen lediglich:
IMarshal-Schnittstelle implementierenNach einigen Tests haben wir eine umfangreiche Liste interessanter CLSIDs auf mehreren Windows-Versionen erhalten und getestet.
JuicyPotato ermöglicht Ihnen:
Ziel-CLSID
wählen Sie eine beliebige CLSID aus. Hier finden Sie die nach Betriebssystem organisierte Liste.
COM-Listening-Port
definieren Sie den bevorzugten COM-Listening-Port (anstelle des gemarshallten fest codierten 6666)
COM-Listening-IP-Adresse
binden Sie den Server an jede IP
Prozesserstellungsmodus
abhängig von den Berechtigungen des imitierten Benutzers können Sie wählen zwischen:
CreateProcessWithToken (benötigt SeImpersonate)CreateProcessAsUser (benötigt SeAssignPrimaryToken)bothZu startender Prozess
starten Sie eine ausführbare Datei oder ein Skript, wenn die Ausbeutung erfolgreich ist
Prozessargument
passen Sie die Argumente des gestarteten Prozesses an
RPC-Serveradresse
für einen verdeckten Ansatz können Sie sich bei einem externen RPC-Server authentifizieren
RPC-Serverport
nützlich, wenn Sie sich bei einem externen Server authentifizieren möchten und die Firewall Port 135 blockiert...
TEST-Modus
T:\>JuicyPotato.exe
JuicyPotato v0.1
Mandatory args:
-t createprocess call: <t> CreateProcessWithTokenW, <u> CreateProcessAsUser, <*> try both
-p <program>: program to launch
-l <port>: COM server listen port
Optional args:
-m <ip>: COM server listen address (default 127.0.0.1)
-a <argument>: command line argument to pass to program (default NULL)
-k <ip>: RPC server ip address (default 127.0.0.1)
-n <port>: RPC server listen port (default 135)
-c <{clsid}>: CLSID (default BITS:{4991d34b-80a1-4291-83b6-3328366b9097})
-z only test CLSID and print token's user

Wenn der Benutzer über SeImpersonate- oder SeAssignPrimaryToken-Berechtigungen verfügt, dann sind Sie SYSTEM.
Es ist nahezu unmöglich, den Missbrauch all dieser COM-Server zu verhindern. Sie könnten darüber nachdenken, die Berechtigungen dieser Objekte über DCOMCNFG zu ändern, aber viel Glück, das wird eine Herausforderung.
Die eigentliche Lösung besteht darin, sensible Konten und Anwendungen zu schützen, die unter den * SERVICE-Konten ausgeführt werden.
Das Stoppen von DCOM würde diesen Exploit sicherlich behindern, könnte aber schwerwiegende Auswirkungen auf das zugrunde liegende Betriebssystem haben.
Ein automatischer Build ist verfügbar. Binärdateien können aus dem Abschnitt "Artifacts" hier heruntergeladen werden.
Auch verfügbar in BlackArch.