Privilegierte Container
A container runs as root with the host filesystem mounted, so code execution inside it becomes control of the host. Perform the escape, then fix it with a non-root user, dropped capabilities, and no privileged flag.
Was ist Privilegierte Container?
Ein Container ist standardmäßig keine Sicherheitsgrenze. Ein Prozess, der innerhalb eines Containers als root läuft, ist root im Host-Kernel, und ein privilegierter Container mit einem Host-Mount kann überall auf der Maschine schreiben, auf der er läuft. Diese Übung behandelt einen Container-Escape: Sieh zu, wie ein Angreifer Codeausführung innerhalb eines Containers in Kontrolle über den Host verwandelt, und arbeite dann die eigentliche Lösung durch – mit einem Non-Root-Benutzer, entfernten Capabilities und einem schreibgeschützten Root-Dateisystem.
Was Sie lernen in Privilegierte Container
- Container-Isolation ist eine Reihe von Kernel-Funktionen, keine Grenze. Root im Container ist root auf dem Host-Kernel, sodass jede Lücke in dieser Isolation sofort ausnutzbar ist.
- Praktisch alle Capabilities und Zugriff auf Host-Geräte, wodurch das meiste entfällt, was den Container vom Host trennt.
- Als Non-Root-Benutzer ausführen, Capabilities entziehen und --privileged sowie den Host-Mount nicht mehr übergeben.
- Ein Angreifer, der Codeausführung erreicht, kann keine Tools oder Persistenzmechanismen in den Container schreiben, wodurch der Einstiegspunkt viel schwerer auszubauen ist.
Privilegierte Container — Trainingsschritte
-
Eine Shell im Container
Bob nimmt Vosswark ins Visier, eine Logistikplattform, deren Media-Service Kunden-Uploads skaliert und transcodiert. Eine ungepatchte Bildbibliothek in diesem Dienst hat ihm Remote Code Execution verschafft, und er hat jetzt eine laufende Shell darin. Wie er hineingekommen ist, ist nicht der interessante Teil. Was der Container ihm als Nächstes erlaubt, schon.
-
Wer bin ich, und was kann ich tun
Zwei Fragen entscheiden, ob dieser Fuß in der Tür eine Sackgasse oder ein Einstieg ist: als welcher Benutzer der Prozess läuft und was der Kernel diesem Benutzer erlaubt. Eine einzige Datei beantwortet beides.
-
Was der Privileged-Modus tatsächlich einbrachte
Privilegiert bedeutet, dass die üblichen Einschränkungen nicht angewendet werden. Bob prüft das Wertvollste, was sich daraus ergeben kann: ob dem Container direkt etwas vom Host übergeben wurde.
-
Den Schlüssel des Hosts nehmen
Der Container war nur Mittel zum Zweck. Was Bob will, liegt auf der Maschine darunter, in dem einen Verzeichnis, das aus einem einzelnen kompromittierten Host einen Brückenkopf für die ganze Flotte macht.
-
Was den Ausbruch möglich machte
Ein kurzer Moment zum Mechanismus, bevor der Schaden aufgerechnet wird.
-
Eine Hintertür hinterlassen
Den Schlüssel auszulesen ist Diebstahl. Auf den Host zu schreiben ist Persistenz. Weil der Mount nicht schreibgeschützt ist, kann Bob seinen eigenen öffentlichen Schlüssel an die authorized_keys des Hosts anhängen, und ab diesem Moment braucht er den gestohlenen Schlüssel überhaupt nicht mehr. Das Anhängen gibt nichts aus, genau wie in einer echten Shell. Genau diese Stille ist der Punkt: Nichts daran sieht wie ein Angriff aus.
-
Zusammenzählen, was ein einziger Container erreicht hat
Bob besitzt jetzt den eigenen Schlüssel des Hosts und hat seinen eigenen daneben platziert. Der Media-Worker war ein Dienst mit geringem Wert, der Kunden-Uploads verarbeitete. So konfiguriert, wie er war, war er außerdem ein Weg zu jeder Maschine, die diesem Schlüssel vertraut, und eine Tür, die Bob jederzeit wieder öffnen kann.
-
Der Host meldet ein Auslesen einer Datei
Vosswark betreibt File Integrity Monitoring auf seinen Hosts. Es interessiert sich nicht dafür, welcher Container etwas getan hat; es meldet, dass das eigene Schlüsselmaterial des Hosts ausgelesen wurde.
-
Ansehen, wie er gestartet wurde
Das Dockerfile beschreibt, was in einem Image steckt. Es sagt nichts über die Flags aus, mit denen ein Container gestartet wurde, und genau in diesen Flags liegt dieser Vorfall. Nur der Host kann das beantworten.
-
Das Dockerfile öffnen
Es gibt zwei Hälften zu beheben, und sie stecken in unterschiedlichen Dateien. Das Image entscheidet, als wer der Prozess läuft; das Deployment entscheidet, was dieser Prozess anfassen darf. Beginne mit dem Image.