
Ausnutzen der Sicherheitslücke namens 'Dirty_Sock' (CVE-2019-7304) in der REST-API für den snapd-Daemon von Canonical.
Ausnutzen der Schwachstelle namens „Dirty_Sock“ (CVE-2019-7304) in der REST-API des Canonical-snapd-Daemons (einem Standarddienst in Ubuntu Linux), um Root-Zugriff zu erlangen.
Ramil Mustafayevs Anleitung: https://kryptohaker.medium.com/linux-privilege-escalation-via-snapd-using-dirty-sock-exploit-and-demonstration-of-cve-2019-7304-892716cf99ca
Diese Schwachstelle wurde in snapd-Versionen älter als 2.37 ausgenutzt, aufgrund einer falsch validierten und geparsten Remote-Socket-Adresse bei der Durchführung von Zugriffskontrollen auf dem UNIX-Socket. Dies betraf damals auch einige Unix- und Linux-Distributionen (z.B. Ubuntu 16.04). Daher benötigen wir für die Durchführung dieser Ausnutzung snapd 2.32 und Ubuntu 16.04.
Ich habe das Debian-Paket von snapd 2.32 von https://launchpad.net/ubuntu/+source/snapd bezogen.

Zuerst überprüfe ich die Ubuntu-Maschine, um zu sehen, ob sie für eine Ausnutzung anfällig ist, indem ich die Befehle cat /etc/lsb-release (welcher die Ubuntu-Version mit ihrer Beschreibung anzeigt) und uname -a (welcher die Informationen über den aktuellen Computer und das Betriebssystem prüft) verwende. Dann sind wir sicher, dass diese Maschine ausnutzbar ist.

Der nächste Schritt ist das Starten des snapd-Dienstes mit dem Befehl systemctl start snapd (In der Praxis muss der snapd-Dienst vom Administrator gestartet werden, wenn Angreifer diesen Fehler ausnutzen, sonst können sie ihn nicht erfolgreich starten). Dann können wir die Version von snapd überprüfen, um sicherzustellen, dass sie anfällig ist.

Als nächstes überprüfe ich die Benutzerrechte mit den Befehlen id (Anzeige der Benutzer- und Gruppeninformationen) und tail /etc/passwd (Die Datei /etc/passwd wird verwendet, um jeden registrierten Benutzer zu verfolgen). Die Ergebnisse unten zeigen, dass der Angreifer mit dem Benutzernamen „coby“ ein normaler Benutzer ist, der den geringsten Zugriff auf das System hat.

Um diesen Angriff zu starten, verwenden wir das dirty_sock-Skript, das zwei Versionen hat und von https://github.com/initstring/dirty_sock bezogen wird. Während Version eins eine ausgehende Internetverbindung und einen laufenden SSH-Dienst erfordert, kann Version zwei direkt ohne jegliche Anforderungen ausgeführt werden.
In der dirty_sockv2.py, die bei dieser Ausnutzung verwendet wird, sollten einige Schlüsselkomponenten beachtet werden. Die erste Schlüsselkomponente in diesem Skript ist die Variable TROJAN_SNAP, ein base64-kodierter String, der ein installierbares Snap-Paket darstellt. Dieses Paket ist ein leeres „devmode“-Snap, das ein Bash-Skript im Installations-Hook hat, welches einen neuen Benutzer erstellt („devmode“ (Entwicklermodus) ist ein spezieller Installationsmodus, der es Snaps erlaubt, die strikte Beschränkung für Entwicklungs- und Debugging-Zwecke zu umgehen).

Eine weitere beachtliche Komponente in diesem Skript ist die Funktion create_sockfile(). Diese Funktion nutzt das unsichere Parsen in der Datei „snapd's ucrednet.go“ aus, um eine zufällige Socket-Datei zu generieren und den Dirty Sock, ;uid=0;, einzuschleusen, was es uns erlaubt, die UID-Variable zu überschreiben.

Um diese Ausnutzung durchzuführen, führe ich einfach die dirty_sockv2.py im Terminal aus. Nach erfolgreichem Ausführen des dirty_sock-Exploits sehen wir, dass ein dirty_sock-Konto mit demselben Passwort automatisch vom Skript erstellt wurde.

Dann überprüfe ich die /etc/passwd, um die Liste der registrierten Benutzer zu sehen, und sehe, dass ein neuer Benutzer namens „dirty_sock“ erstellt wurde.

Mit dem Befehl su kann ich mich mit den gefundenen Anmeldeinformationen in das Konto „dirty_sock“ einloggen. Nach erfolgreichem Einloggen kann ich die Rechte dieses Benutzers überprüfen und sehe, dass er in der sudo-Gruppe ist. Das bedeutet, dass der Angreifer bereits die volle Kontrolle über das System erlangt hat und alles mit den höchsten Privilegien tun kann.

Der CVSS-Score dieser Schwachstelle beträgt 8,8 (Hoher Schweregrad), was bedeutet, dass sie bei Ausnutzung enorme Auswirkungen auf das System haben kann. Diese Schwachstelle hat einen hohen Schweregrad, da sie keine hohen Privilegien zur Ausnutzung erfordert. Wenn ein Angreifer bereits einen Fuß im System hat (z.B. ein Benutzer mit niedrigen Privilegien), kann er die Privilegien auf Root ausweiten, was diese Schwachstelle zu einer ernsthaften lokalen Sicherheitsbedrohung macht, insbesondere in Multi-User- oder Cloud-Umgebungen.