Exponierter Docker-Daemon

Was ist Exponierter Docker-Daemon?

Die Docker-API verleiht Befugnisse wie root und bietet selbst keine Authentifizierung. Lauscht ein Daemon an einem ungeschützten TCP-Port, kann jeder, der ihn erreicht, Container starten, das Host-Dateisystem einbinden und Daten vom Rechner lesen. Dafür muss keine Schwachstelle ausgenutzt werden. Sie fragen Port 2375 von außen ohne Authentifizierung ab, listen Produktionscontainer auf und binden das Root-Dateisystem des Hosts ein, um seine Umgebungsdatei zu lesen. Anschließend entfernen Sie die Bindung an tcp://0.0.0.0:2375, verlangen TLS-Client-Zertifikate und prüfen, dass dieselbe Abfrage abgewiesen wird. Die Übung behandelt außerdem das Einbinden von /var/run/docker.sock in einen Container.

Was Sie lernen in Exponierter Docker-Daemon

• Erkennen, dass die Docker-API root-Befugnisse verleiht und selbst keine Authentifizierung bietet
• Einen an tcp://0.0.0.0:2375 gebundenen Daemon als aus der Ferne und ohne Authentifizierung kontrollierbar erkennen – ohne Schwachstelle oder vorherigen Zugang
• Nachvollziehen, wie ein Angreifer das Root-Dateisystem des Hosts in einen Container einbindet und darüber die produktive Umgebungsdatei liest
• Die ungeschützte TCP-Bindung entfernen, gegenseitige Authentifizierung per TLS-Client-Zertifikat verlangen und prüfen, dass dieselbe Abfrage abgewiesen wird
• Erklären, warum ein in einen Container eingebundener /var/run/docker.sock diesem Zugriff auf dieselbe API mit root-Befugnissen gibt

Exponierter Docker-Daemon — Trainingsschritte

1. Die öffentliche Statusseite lesen

   Bob ist noch in kein System eingedrungen. Er sitzt an seinem eigenen Laptop und liest Pallistons öffentliche Statusseite. Sie soll Kunden zeigen, dass die Plattform funktioniert. Dabei nennt sie die Produktionsknoten, deren öffentliche IP-Adressen und die Docker-Version, die jeweils darauf läuft. Sehen Sie sich an, was die Seite preisgibt, bevor Bob diese Angaben nutzt.

2. Die Zeile, die zu viel verrät

   Eine einzige Zeile genügt: die öffentliche IP-Adresse eines Produktionsknotens und der Hinweis, dass darauf Docker läuft. Damit kann Bob einen denkbar einfachen Angriff versuchen.

3. Beim Daemon anklopfen

   Der Docker-Daemon kann so konfiguriert werden, dass er statt nur über den lokalen Socket auch an einem Netzwerkport lauscht. Ist TLS deaktiviert, antwortet er jedem, der den Port erreicht. Bob richtet die Docker-CLI auf seinem Laptop auf Port 2375 des Knotens und stellt eine scheinbar harmlose Frage: Welche Version läuft dort? Wenn der Daemon antwortet, hat Bob bereits Zugriff.

4. Die Produktionscontainer anzeigen

   Die Docker-API kann weit mehr als Container auflisten: Sie kann sie auch starten, stoppen und bauen. Dabei verfügt sie über root-Befugnisse. Bob sieht sich zunächst an, was auf dem Host läuft.

5. Den Host einbinden und Secrets auslesen

   Bob muss in keinen der laufenden Container eindringen. Der Daemon startet für ihn einen neuen Container und bindet ein, was Bob verlangt. Er lässt das gesamte Root-Dateisystem des Hosts unter /host einbinden und liest darüber die produktive Umgebungsdatei. Den Container hat Bob gestartet. Darin liegt nun das Dateisystem des Hosts offen. Eine weitere Schranke musste er nicht überwinden.

6. Was den Angriff ermöglicht hat

7. Ein Fremder in den Daemon-Logs

   Palliston überträgt die Logs seiner Docker-Daemons an eine zentrale Sammelstelle. Auch ohne spezielles Angriffserkennungssystem fällt darin etwas auf: API-Aufrufe an den Daemon auf ops-node-01 von einer IP-Adresse, die Palliston nicht gehört.

8. Prüfen, ob der Zugang offen ist

   Bevor Alice etwas ändert, stellt sie den Vorgang aus den Logs nach. Antwortet der Daemon auf eine nicht authentifizierte Versionsabfrage von ihrem eigenen Rechner, ist er tatsächlich so offen erreichbar, wie Priya befürchtet.

9. Die Daemon-Konfiguration öffnen

   Das Verhalten des Daemons ist in /etc/docker/daemon.json konfiguriert. Hier muss auch die Einstellung stehen, die ihn ohne TLS am Netzwerk lauschen lässt.

10. Die Einstellung finden, die den Port öffnet

    Zwei Einstellungen zusammen verursachen den offenen Zugang: Die eine stellt die API im Netzwerk bereit, die andere deaktiviert die Prüfung der Aufrufenden.