Ein Leitfaden zu Container Privilege Escalation Schwachstellen.

Eines der vielen Versprechen von Containern ist die Isolation.

Durch den sorgfältigen Einsatz von Linux-Namespaces und cgroups schaffen Container eine Sandbox, in der Prozesse unabhängig voneinander ausgeführt werden können. Dies, kombiniert mit einer hervorragenden Entwickelnden-Erfahrung, führte dazu, dass Container sowohl bei Ingenieuren als auch bei Sicherheitsexperten an Beliebtheit gewannen. 

Aber ist das wirklich genug?

Und können Sie mit Sicherheit sagen, dass Ihre Workloads sicher sind, sollte einer davon kompromittiert werden?

Nun, in diesem Beitrag nehmen wir den Traum eines jeden Angreifers und den Albtraum eines jeden Systemadministrators unter die Lupe und erklären Ihnen, wie und warum es passiert, und wie Sie es verhindern können, bevor Sie auf der Titelseite von Hacker News landen.  Für weitere Docker Containersicherheitsschwachstellen, lesen Sie: Die Top 9 Docker Containersicherheitsschwachstellen.

Container-Isolation und ihre Sicherheitslücken

Ein oft übersehenes Detail bei Containern ist, dass sie alle denselben Host teilen. Das bedeutet, jeder Container ist nur so sicher wie der nächste. Wenn der Host oder ein einzelner Container kompromittiert wird, könnte dies eine Katastrophe für Ihre Infrastruktur bedeuten. 
Das bedeutet jedoch nicht, dass Sie Container ganz aufgeben sollten. Nein. Es geht darum, das Kleingedruckte zu verstehen.

Die Isolation beginnt zusammenzubrechen, wenn Angreifer einen Weg finden, Privilegien zu eskalieren. ​​Die Privilegieneskalation ist einer der aufregendsten und gleichzeitig anspruchsvollsten Schritte bei offensiven Sicherheitsangriffen. Sie verwandelt einen niedrig privilegierten Zugangspunkt in eine vollständige Systemkompromittierung. 

Container-Privilegieneskalationsschwachstellen machen das Umgehen von Sicherheitsgrenzen weniger anspruchsvoll und wesentlich lohnender, da ein einziger Container ausreicht, um Zugriff auf einen Host zu erhalten. 

Das ist nicht nur Theorie; die berüchtigte runC-Schwachstelle von 2019 (CVE-2019-5736) ermöglichte es Angreifern, die Host-runC-Binärdatei zu überschreiben und Root-Zugriff auf den Host zu erlangen.

Diese Angriffe sind alles andere als flüchtig, weshalb Sie möglicherweise auf Fragen wie diese stoßen werden:

In jüngster Zeit haben Schwachstellen wie CVE-2024-21626 und subtile, schichtbasierte Angriffe gezeigt, dass selbst Nicht-Root-Container gefährlich werden können, wenn Linux-Capabilities, Mounts oder das Filesystem-Layering missbräuchlich verwendet werden.

Deshalb werden wir, aufbauend auf unserem vorherigen Leitfaden zu Docker-Schwachstellen, untersuchen, wie diese Angriffe funktionieren, welche jüngsten CVEs ihre wachsenden Risiken hervorheben und wie man sie verhindert.

Jüngste Container-Privilegieneskalations-Schwachstellen 

Obwohl nicht alle Container-Schwachstellen zu einer Privilegieneskalation führen, tun dies die gefährlichsten oft. Einige Schwachstellen umgehen die Container-Isolation und erlangen erhöhte Privilegien wie keine anderen. 

Im Folgenden sind drei jüngste Container-Privilegieneskalations-Schwachstellen aufgeführt. 

CVE-2024-21626: runC Working Directory Breakout

CVE-2024-21626 ist eine hochkritische Container-Escape-Schwachstelle, die die weit verbreitete Container-Runtime runC betrifft. Die Schwachstelle entsteht durch eine unsichere Verwendung des PR_SET_NO_NEW_PRIVS prctl-Aufrufs mit execve, wodurch ein Angreifer das no_new_privs-Flag umgehen kann, wenn der Container mit übermäßig permissiven Mounts oder Capabilities gestartet wurde. 

Das no_new_privs-Flag ist eine der zentralen Mitigationen gegen Privilegieneskalation, auf die sich viele Container-Engines für das Sandboxing verlassen. 

Die Schwachstelle wurde in runC-Versionen ab v1.1.11 eingeführt und in v1.1.12 behoben.

CVE-2023-2640 und CVE-2023-32629 im Ubuntu Kernel OverlayFS Modul

OverlayFS ist einer der fundamentalen Bausteine von Containern und Kubernetes. Es schichtet zwei Verzeichnisse (lowerdir und upperdir) auf einem einzelnen Linux-Host und präsentiert sie als ein einziges Verzeichnis, was eine bessere Leistung für schichtbezogene Docker-Befehle wie docker build und docker commit bietet.

CVE-2023-2640 und CVE-2023-32629 ermöglichen es einem böswilligen Akteur, einen nicht-Root-Container mit Volume-Mount zur Privilegieneskalation zu nutzen. Dies ist möglich, da Volume-Mounts als separate Datenträger behandelt werden und zur Erstellung von OverlayFS verwendet werden können, das außerhalb der Container-Schicht existiert. Dies ermöglicht Angreifern, Standard-Container-Beschränkungen zu umgehen und erweiterte Dateiattribute auf gemounteten Volumes zu manipulieren, die dann mit intakten erhöhten Capabilities (wie CAP_SETUID oder CAP_SYS_ADMIN) in die obere Schicht kopiert werden.

CVE-2022-0492

Am 4. März 2022 deckten Sicherheitsforscher eine kritische Schwachstelle im Linux-Kernel cgroup_release_agent_write auf, die das Potenzial hatte, einen Container-Escape zu ermöglichen und die Kontrolle über den gesamten Node zu übernehmen, auf dem der Container läuft.

Cloud-Anbieter und Linux-Distributionen reagierten schnell. Patches wurden veröffentlicht, Advisories herausgegeben. Doch unter der Oberfläche blieb die Komplexität bestehen. Im Gegensatz zu anderer Software fehlt dem Linux-Kernel ein standardisiertes Versionierungsschema über alle Distributionen hinweg. 

Das bedeutete, dass das Anwenden dieser Patches und das Upgrade der Basis-Images Monate dauerte. In dieser Zeit blieben Umgebungen anfällig für potenzielle Angriffe.

Verhindern von Privilegieneskalationen in Docker und Docker Compose

Der beste Weg, um Privilegieneskalationsangriffe innerhalb eines Docker-Containers zu verhindern, besteht darin, die Anwendungen Ihres Containers so zu konfigurieren, dass sie als unprivilegierte Benutzer laufen, und dann sicherzustellen, dass die Container keinen privilegierten Zugriff haben.

In der Praxis müssen Sie, um Privilegieneskalation in Docker zu verhindern, Folgendes tun:

• Rechteausweitung sperren
• Einen geeigneten Nicht-Root-Benutzer festlegen
• Entfernen Sie Linux-Kernel-Capabilities

Sie haben zwei Optionen: entweder zur Laufzeit oder innerhalb Ihrer Docker Compose-Konfiguration. 

Zur Laufzeit verwenden Sie die folgenden Flags:

docker run \     
--read-only \     
--security-opt=no-new-privileges \     
--network your-isolated-network \      
--cap-drop ALL     
--cap-add CHOWN \      
--pids-limit 99 \     
--user=your-user \ # Ihr Nicht-Root-Benutzer.    
...                 # WEITERE OPTIONEN HIER      
your-app:v1.0.1

Mit Docker Compose sieht die Konfiguration wie folgt aus:

services:        
webapp:           
image: your-app:v1.0.1        
read_only: true        
security_opt:           
- no-new-privileges:true        
networks:           
- your-isolated-network        
cap_drop:           
- ALL        
cap_add:           
- CHOWN                
# OTHER OPTIONS GO HERE          
...

Ausführen von Containern, die Root-Benutzerzugriff erfordern

Es gibt Fälle (Ausführung von Systemdienstprogrammen, Legacy-Diensten usw.), in denen ein Container Root-Zugriff zum Ausführen benötigt. In diesen Fällen können Sie diesen Benutzer einem weniger privilegierten Benutzer auf dem Docker-Host zuordnen.

Das Neuzuordnen einer Container-UID stellt sicher, dass der Container, obwohl er glaubt, als Root zu laufen, aus Sicht des Hosts tatsächlich als unprivilegierter Benutzer agiert, was das Risiko eines Container-Breakouts und einer Host-Kompromittierung reduziert. 

Detaillierte Schritte und Best Practices finden Sie in der Docker-Dokumentation zum User Namespace Remapping.

Verhindern der Privilegienerhöhung in Kubernetes

In Kubernetes ist der beste Weg, eine Privilegienerhöhung zu verhindern, die Container-Erstellung unter Verwendung der Konfiguration spec.containers.securityContext. Dies liegt daran, dass ein Container mit übermäßig permissiven Privilegien nach seiner Erstellung zur Laufzeit nicht mehr aktualisiert werden kann und Sie ihn löschen und neu erstellen müssen. 

Der folgende securityContext schützt den App-Container vor Privilegienerhöhung, selbst bei Linux-Versionen des ungepatchten CVE-2022-0492, wie oben erwähnt. 

containers:  
- name: app    
image: myapp:bullseye-20230912    
securityContext:      
runAsUser: 1000 # Eine Nicht-Root-Benutzer-ID verwenden      
runAsGroup: 1000 # Eine Nicht-Root-Gruppen-ID verwenden      
runAsNonRoot: true # Nicht-Root-Ausführung explizit erzwingen      
allowPrivilegeEscalation: false # Verhindert, dass der Prozess weitere Privilegien erhält      
readOnlyRootFilesystem: true # Schreibzugriffe auf das Root-Dateisystem verhindern      
capabilities:        
drop:          
- ALL # Alle Capabilities entfernen, um die Angriffsfläche zu minimieren        
add:          
- NET_BIND_SERVICE # Nur die Capabilities hinzufügen, die die Anwendung benötigt      
seccompProfile:        
type: RuntimeDefault # Das Standard-Seccomp-Profil der Container-Laufzeit verwenden

Eine weitere gute Möglichkeit, die Privilegienerhöhung in Kubernetes zu verhindern, besteht darin, Pods ohne Security Context überhaupt nicht zu planen. Kubernetes Admission Controller ermöglichen es Ihnen, Anfragen an den API-Server, z. B. ein Deployment, abzufangen und zu validieren, dass bestimmte Bedingungen erfüllt sind, bevor sie verarbeitet werden. 

Für fortgeschrittenere Anwendungsfälle können Sie einen Admission Controller von Grund auf neu schreiben; Open-Source-Lösungen wie Kyverno ermöglichen es Ihnen jedoch, clusterweite Richtlinien zu erstellen, die Deployments patchen können, die keinen Security Context gesetzt haben. Dies sieht typischerweise wie folgt aus:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:  
name: add-default-securitycontext  
annotations:    
policies.kyverno.io/title: Add Default securityContext    
policies.kyverno.io/category: Sample    
policies.kyverno.io/subject: Pod    
policies.kyverno.io/minversion: 1.6.0    
policies.kyverno.io/description: >-      
Ein Pod securityContext-Eintrag definiert Felder wie den Benutzer und die Gruppe, die zum Ausführen des Pods verwendet werden sollen.
Manchmal ist die Wahl von Standardwerten für Benutzer anstatt des Blockierens eine bessere Alternative, um solche Pod-Definitionen nicht zu behindern. Diese Richtlinie wird einen Pod mutieren, um die Felder `runAsNonRoot`, `runAsUser`, `runAsGroup` und `fsGroup` innerhalb des Pod securityContext zu setzen, falls sie noch nicht festgelegt sind.
spec:  
rules:  
- name: add-default-securitycontext    
match:     
any:      
- resources:          
kinds:          
- Pod    
mutate:      
patchStrategicMerge:        
spec:          
securityContext:            
+(runAsNonRoot): true            
+(runAsUser): 1000            
+(runAsGroup): 3000            
+(fsGroup): 2000

Das obige Manifest verwendet die ClusterPolicy Custom Resource Definition (CRD), um Pods über mutate.PatchStrategicMerge und einen Sicherheitskontext mit einem Nicht-Root-Benutzer zu patchen. 

Sichere Container werden gebaut, nicht angenommen

Während Container Isolation und eine zuverlässige Möglichkeit bieten, Anwendungen zu erstellen und auszuführen, bedeutet die sich ständig ändernde Natur der Containersicherheit, dass man sich nicht ausschließlich auf präventive Maßnahmen verlassen kann. Stattdessen sollte eine Strategie verfolgt werden, die es ermöglicht, schnell auf Vorfälle zu reagieren, sobald sie auftreten. 

Diese Strategie beginnt mit proaktivem Scanning.

Mit Aikido können Sie automatisch Container-Images scannen, um anfällige Pakete, veraltete Runtimes oder riskante Dockerfile-Anweisungen aufzudecken, bevor sie die Produktion erreichen. Sein Open-Source-Dependency-Scanner erweitert diesen Schutz, indem er Ihre Bibliotheken auf ausnutzbare CVEs und sogar auf stillschweigend gepatchte Schwachstellen prüft, die Angreifer nutzen könnten, um erweiterte Berechtigungen zu erlangen.

Diese Scans werden durch IaC- und Konfigurationsprüfungen ergänzt, die unsichere Kubernetes- oder Docker-Einstellungen kennzeichnen, sowie durch CI/CD-Sicherheits-Gates, die Least-Privilege-Richtlinien auf Pipeline-Ebene durchsetzen. Und da Prävention niemals perfekt sein kann, bietet Aikido Zen Laufzeitschutz, um anomales Container-Verhalten in Echtzeit zu erkennen und darauf zu reagieren.