Privilegierte Container

Was ist Privilegierte Container?

Ein Container ist standardmäßig keine Sicherheitsgrenze. Ein Prozess, der in einem als Root ausgeführt wird, ist Root auf dem Host-Kernel, und das Privileged-Flag sowie ein Host-Bind-Mount entfernen den Rest zwischen ihnen. Sie führen den Escape-Vorgang durch: Lesen Sie den gewährten Funktionssatz, listen Sie das Host-Dateisystem über den Mount auf, stehlen Sie seinen Root-SSH-Schlüssel und fügen Sie Ihren eigenen für die Persistenz hinzu. Der Fix erstreckt sich über zwei Dateien. Sie fügen der Docker-Datei einen Nicht-Root-BENUTZER hinzu und löschen dann das Privileged-Flag und alle Funktionen in Compose.

Was Sie lernen in Privilegierte Container

• Erklären Sie, warum es sich bei der Containerisolation um eine Reihe von Kernel-Funktionen und nicht um eine Grenze handelt, sodass der Root im Inneren der Root auf dem Host-Kernel ist
• Identifizieren Sie, was --privileged gewährt, indem Sie den eigenen Funktionssatz des Containers aus seiner Prozessstatusdatei lesen
• Verfolgen Sie einen Host-Escape durch einen Bind-Mount, von der Auflistung des Host-Dateisystems über den Diebstahl seines Root-SSH-Schlüssels bis hin zum Einschleusen Ihres eigenen
• Fügen Sie der Docker-Datei eine Nicht-Root-USER-Anweisung hinzu, damit der laufende Prozess weitaus weniger von einer Lücke in der Grenze profitieren kann
• Löschen Sie das Privileged-Flag und den Host-Mount in Compose, wenden Sie cap_drop ALL und ein schreibgeschütztes Rootfs an und versuchen Sie dann den Escape beim Staging erneut

Privilegierte Container — Trainingsschritte

1. 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.

2. 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.

3. 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.

4. 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.

5. Was den Ausbruch möglich machte

   Ein kurzer Moment zum Mechanismus, bevor der Schaden aufgerechnet wird.

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.