AuthZ& AuthN - Docker Access Authorization Plugin
Das Standard-Autorisierungsmodell von Docker ist alles oder nichts. Jeder Benutzer mit Berechtigung zum Zugriff auf den Docker-Daemon kann jede Docker-Client-Befehle ausführen. Das Gleiche gilt für Aufrufer, die die Docker-Engine-API verwenden, um den Daemon zu kontaktieren. Wenn Sie größere Zugriffskontrolle benötigen, können Sie Autorisierungs-Plugins erstellen und diese zu Ihrer Docker-Daemon-Konfiguration hinzufügen. Mit einem Autorisierungs-Plugin kann ein Docker-Administrator feingranulare Zugriffsrichtlinien für die Verwaltung des Zugriffs auf den Docker-Daemon konfigurieren.
Grundarchitektur
Docker Auth-Plugins sind externe Plugins, die Sie verwenden können, um Aktionen zu erlauben/zu verweigern, die an den Docker-Daemon angefordert werden, abhängig von dem Benutzer, der sie angefordert hat, und der angeforderten Aktion.
Die folgenden Informationen stammen aus den Dokumenten
Wenn eine HTTP-Anfrage an den Docker-Daemon über die CLI oder über die Engine-API gesendet wird, leitet das Authentifizierung-Subsystem die Anfrage an das installierte Authentifizierungs-Plugin(s) weiter. Die Anfrage enthält den Benutzer (Aufrufer) und den Kontext des Befehls. Das Plugin ist dafür verantwortlich zu entscheiden, ob die Anfrage erlaubt oder verweigert wird.
Die Sequenzdiagramme unten zeigen einen Erlauben- und Verweigern-Autorisierungsfluss:
Jede an das Plugin gesendete Anfrage enthält den authentifizierten Benutzer, die HTTP-Header und den Anfrage-/Antwortkörper. Nur der Benutzername und die Authentifizierungsmethode, die verwendet werden, werden an das Plugin übergeben. Am wichtigsten ist, dass keine Benutzer-Anmeldeinformationen oder Tokens übergeben werden. Schließlich werden nicht alle Anfrage-/Antwortkörper an das Autorisierungs-Plugin gesendet. Nur die Anfrage-/Antwortkörper, bei denen der Content-Type
entweder text/*
oder application/json
ist, werden gesendet.
Für Befehle, die potenziell die HTTP-Verbindung übernehmen können (HTTP Upgrade
), wie exec
, wird das Autorisierungs-Plugin nur für die anfänglichen HTTP-Anfragen aufgerufen. Sobald das Plugin den Befehl genehmigt, wird die Autorisierung nicht auf den Rest des Flusses angewendet. Insbesondere werden die Streaming-Daten nicht an die Autorisierungs-Plugins übergeben. Für Befehle, die chunked HTTP-Antworten zurückgeben, wie logs
und events
, wird nur die HTTP-Anfrage an die Autorisierungs-Plugins gesendet.
Während der Verarbeitung von Anfrage/Aantwort müssen einige Autorisierungsflüsse möglicherweise zusätzliche Abfragen an den Docker-Daemon durchführen. Um solche Flüsse abzuschließen, können Plugins die Daemon-API ähnlich wie ein regulärer Benutzer aufrufen. Um diese zusätzlichen Abfragen zu ermöglichen, muss das Plugin die Mittel bereitstellen, damit ein Administrator geeignete Authentifizierungs- und Sicherheitsrichtlinien konfigurieren kann.
Mehrere Plugins
Sie sind verantwortlich für die Registrierung Ihres Plugins als Teil des Starts des Docker-Daemons. Sie können mehrere Plugins installieren und sie miteinander verketten. Diese Kette kann geordnet sein. Jede Anfrage an den Daemon durchläuft die Kette in der Reihenfolge. Nur wenn alle Plugins den Zugriff auf die Ressource gewähren, wird der Zugriff gewährt.
Plugin-Beispiele
Twistlock AuthZ Broker
Das Plugin authz ermöglicht es Ihnen, eine einfache JSON-Datei zu erstellen, die das Plugin zum Autorisieren der Anfragen lesen wird. Daher haben Sie die Möglichkeit, sehr einfach zu steuern, welche API-Endpunkte jeden Benutzer erreichen können.
Dies ist ein Beispiel, das es Alice und Bob erlaubt, neue Container zu erstellen: {"name":"policy_3","users":["alice","bob"],"actions":["container_create"]}
Auf der Seite route_parser.go finden Sie die Beziehung zwischen der angeforderten URL und der Aktion. Auf der Seite types.go finden Sie die Beziehung zwischen dem Aktionsnamen und der Aktion.
Einfaches Plugin-Tutorial
Sie finden ein einfach zu verstehendes Plugin mit detaillierten Informationen zur Installation und Fehlersuche hier: https://github.com/carlospolop-forks/authobot
Lesen Sie die README
und den plugin.go
-Code, um zu verstehen, wie es funktioniert.
Docker Auth Plugin Umgehung
Zugriff auflisten
Die wichtigsten Punkte, die zu überprüfen sind, sind welche Endpunkte erlaubt sind und welche Werte von HostConfig erlaubt sind.
Um diese Auflistung durchzuführen, können Sie das Tool https://github.com/carlospolop/docker_auth_profiler.
nicht erlaubtes run --privileged
run --privileged
Minimale Berechtigungen
Ausführen eines Containers und dann Erhalten einer privilegierten Sitzung
In diesem Fall verbot der Sysadmin den Benutzern, Volumes zu mounten und Container mit dem --privileged
-Flag auszuführen oder dem Container zusätzliche Berechtigungen zu geben:
Jedoch kann ein Benutzer eine Shell im laufenden Container erstellen und ihr die zusätzlichen Berechtigungen geben:
Jetzt kann der Benutzer den Container mit einer der bereits besprochenen Techniken verlassen und Privilegien eskalieren innerhalb des Hosts.
Schreibbares Verzeichnis einbinden
In diesem Fall verbot der Systemadministrator den Benutzern, Container mit dem --privileged
-Flag auszuführen oder dem Container zusätzliche Berechtigungen zu geben, und er erlaubte nur das Einbinden des /tmp
-Verzeichnisses:
Beachten Sie, dass Sie möglicherweise den Ordner /tmp
nicht einhängen können, aber Sie können einen anderen beschreibbaren Ordner einhängen. Sie können beschreibbare Verzeichnisse mit folgendem Befehl finden: find / -writable -type d 2>/dev/null
Beachten Sie, dass nicht alle Verzeichnisse auf einer Linux-Maschine das suid-Bit unterstützen! Um zu überprüfen, welche Verzeichnisse das suid-Bit unterstützen, führen Sie mount | grep -v "nosuid"
aus. Zum Beispiel unterstützen normalerweise /dev/shm
, /run
, /proc
, /sys/fs/cgroup
und /var/lib/lxcfs
nicht das suid-Bit.
Beachten Sie auch, dass Sie, wenn Sie /etc oder einen anderen Ordner mit Konfigurationsdateien einhängen können, diese als Root aus dem Docker-Container ändern können, um sie auf dem Host auszunutzen und Privilegien zu eskalieren (möglicherweise durch Modifikation von /etc/shadow
).
Ungeprüfter API-Endpunkt
Die Verantwortung des Sysadmins, der dieses Plugin konfiguriert, besteht darin, zu kontrollieren, welche Aktionen und mit welchen Berechtigungen jeder Benutzer ausführen kann. Daher könnte der Admin, wenn er einen Blacklist-Ansatz mit den Endpunkten und den Attributen verfolgt, einige davon vergessen, die es einem Angreifer ermöglichen könnten, Privilegien zu eskalieren.
Sie können die Docker-API unter https://docs.docker.com/engine/api/v1.40/# überprüfen.
Ungeprüfte JSON-Struktur
Binds im Root
Es ist möglich, dass der Sysadmin beim Konfigurieren der Docker-Firewall ein wichtiges Parameter der API wie "Binds" vergessen hat. Im folgenden Beispiel ist es möglich, diese Fehlkonfiguration auszunutzen, um einen Container zu erstellen und auszuführen, der den Root (/) Ordner des Hosts einhängt:
Beachten Sie, dass wir in diesem Beispiel den Binds
-Parameter als Schlüssel auf der obersten Ebene im JSON verwenden, aber in der API erscheint er unter dem Schlüssel HostConfig
.
Binds in HostConfig
Befolgen Sie die gleichen Anweisungen wie bei Binds in root und führen Sie diese Anfrage an die Docker API aus:
Mounts in root
Befolgen Sie die gleichen Anweisungen wie bei Binds in root und führen Sie diese Anfrage an die Docker API aus:
Mounts in HostConfig
Befolgen Sie die gleichen Anweisungen wie bei Binds in root, indem Sie diese Anfrage an die Docker API senden:
Unchecked JSON Attribute
Es ist möglich, dass der Sysadmin beim Konfigurieren der Docker-Firewall ein wichtiges Attribut eines Parameters der API wie "Capabilities" innerhalb von "HostConfig" vergessen hat. Im folgenden Beispiel ist es möglich, diese Fehlkonfiguration auszunutzen, um einen Container mit der SYS_MODULE-Berechtigung zu erstellen und auszuführen:
Die HostConfig
ist der Schlüssel, der normalerweise die interessanten Befugnisse enthält, um aus dem Container zu entkommen. Beachten Sie jedoch, wie die Verwendung von Binds außerhalb davon ebenfalls funktioniert und Ihnen möglicherweise ermöglicht, Einschränkungen zu umgehen.
Deaktivieren des Plugins
Wenn der Sysadmin vergessen hat, die Möglichkeit zu verbieten, das Plugin zu deaktivieren, können Sie dies ausnutzen, um es vollständig zu deaktivieren!
Denke daran, das Plugin nach der Eskalation wieder zu aktivieren, sonst funktioniert ein Neustart des Docker-Dienstes nicht!
Auth Plugin Bypass Writeups
Last updated