Cloud
Container-Privilegien gefährden AWS-Credentials
Überprivilegierte oder falsch konfigurierte Container in Amazon EKS können sensible AWS-Credentials Bedrohungen wie Packet Sniffing und API-Spoofing aussetzen. Wir zeigen anhand von Beispielen, wie das Risiko aussieht und wie der Schutz davor.
Save to Folio
Wichtigste Erkenntnisse
- Falsch konfigurierte oder zu hoch privilegierte Container in Kubernetes-Umgebungen können den unbefugten Zugriff auf sensible AWS-Credentials erleichtern und damit der Privilege Escalation und bösartigen Aktivitäten aussetzen.
- Wir haben Exploit-Szenarien mit überprivilegierten Containern gefunden, einschließlich Packet Sniffing von unverschlüsseltem HTTP-Verkehr, um auf Klartext-Credentials zuzugreifen, und API-Spoofing, um Autorisierungs-Tokens abzufangen und erhöhte Berechtigungen zu erlangen.
- Trend Vision One™ Container Security ermöglicht es Unternehmen, proaktive Sicherheitsrichtlinien durchzusetzen, die Container mit höheren Privilegienstufen erkennen und eindämmen.
Kubernetes-basierte Container-Plattformen spielen eine entscheidende Rolle in der Cloud, um containerisierte Anwendungen effizient und in großem Umfang zu orchestrieren und zu verwalten. Sie automatisieren die Bereitstellung, Skalierung sowie den Betrieb und sind damit ideal geeignet für Microservices und verschiedene Workloads. Zu den wichtigsten Vorteilen gehören die Portabilität in der Cloud, die Kosteneffizienz durch eine bessere Ressourcennutzung, die Beschleunigung der Entwicklungszyklen durch Automatisierung und Selbstheilung sowie die vereinfachte Verwaltung verteilter Systeme, die allesamt widerstandsfähige und skalierbare Anwendungen ermöglichen.
Amazon Elastic Kubernetes Service (EKS) bezeichnet einen Managed Service, der die Ausführung von Kubernetes auf Amazon Web Services (AWS) und vor Ort verschlankt. Er automatisiert die Verwaltung der Kubernetes-Kontrollebene und sorgt für hohe Verfügbarkeit und Skalierbarkeit. Er lässt sich nahtlos in andere AWS-Services für Netzwerk, Sicherheit und Speicherung integrieren.
Falsch konfigurierte oder übermäßig privilegierte Container stellen ein erhebliches Sicherheitsrisiko dar, da sie Angreifern unbefugten Zugriff und Kontrolle über sensible Daten und Systemressourcen innerhalb einer Umgebung gewähren können. Maßnahmen, wie die Sicherstellung einer ordnungsgemäßen Konfiguration und die Beschränkung von Container-Privilegien auf das Notwendige, sind für den Betrieb einer sicheren containerisierten Infrastruktur von entscheidender Bedeutung.
Wir haben Angriffsszenarien auf Basis von Packet Sniffing und API-Spoofing untersucht, die dazu verwendet werden, um übermäßig hohe Privilegien für Container auszunutzen. Dafür missbrauchen Angreifer Fehlkonfigurationen und extrahieren sensible AWS-Credentials direkt aus containerisierten Anwendungen, ein kritisches Problem in Cloud-Umgebungen.
Ausnutzung des Amazon EKS Pod Identity Service
Amazon EKS Pod Identity ist eine Funktion, die in AWS den Prozess vereinfacht, AWS-Credentials für Pods, die in einem EKS-Cluster laufen, zu vergeben. Sie bietet eine alternative und ergänzende Methode zu IAM Roles for Service Accounts (IRSA) und ermöglicht den sicheren Zugriff auf AWS-Ressourcen wie S3-Buckets oder DynamoDB-Tabellen aus Kubernetes-Anwendungen heraus.
Die Einrichtung von Pod Identity beginnt mit der Installation des Add-ons eks-pod-identity-agent auf dem Amazon EKS-Cluster. Dieser Agent stellt sicher, dass eine Instanz des Agenten auf jedem Arbeits-Node läuft. Er stellt eine einfache API bereit, die das Token des Kubernetes Service-Konto im Authorization-Header akzeptiert und eine spezifische AWS-API-Aktion aufruft. Einzelheiten bietet der Originalbeitrag.
Wenn eine Anwendung in einem Pod, der ein AWS SDK verwendet, eine Anfrage an einen AWS Service stellt, identifiziert das SDK automatisch die relevanten Umgebungsvariablen und ruft temporäre Credentials vom EKS Pod Identity Agent ab, der auf dem Knoten läuft. Der Agent interagiert dann mit der eks-auth:AssumeRoleForPodIdentity API, um die erforderlichen Credentials für die zugehörige IAM-Rolle zu erhalten.
Angriffsszenario auf Basis von Packet Sniffing
Der EKS Pod Identity Agent arbeitet auf jedem Knoten und stellt eine API auf einer lokalen IP-Adresse scheinbar über unverschlüsseltes HTTP zur Verfügung. Dies bedeutet ein Sicherheitsrisiko, da jeder Pod mit „hostNetwork: true“-Einstellungen potenziell den Netzwerkverkehr auf dem Knoten überwachen kann, was das Abfangen von Credentials ermöglicht, die vom API-Endpunkt 169.254.170.23:80 gesendet werden. Da die AWS-Umgebung diese Credentials nicht an ein bestimmtes Asset bindet, können böswillige Akteure sie verwenden, um sich innerhalb der Umgebung erhöhte Rechte zu verschaffen. Einen trivialen Proof-of-Concept (PoC) mit dem Standarddienstprogramm tcpdump finden Sie im Originalbeitrag.
Angriffsszenario auf Basis von API-Spoofing
Das Entfernen der CAP_NET_RAW-Fähigkeit aus einem hostNetwork-fähigen Container kann das Risiko nicht vollständig ausschließen, wenn andere Berechtigungen, die eine Manipulation der Netzwerkschnittstelle ermöglichen, aktiviert werden. Solange ein bösartiger Pod die Einstellungen der Netzwerkschnittstellenkarte (NIC) manipulieren kann, ist er in der Lage, den HTTP-Daemon eks-pod-identity-agent zu deaktivieren, indem er die lokale Link-IP-Adresse löscht, an die der Prozess gebunden ist. Dadurch kann ein Angreifer die Kontrolle über den HTTP-Dienst übernehmen, der auf 169.254.170.23:80 läuft, und seinen eigenen HTTP-Server einrichten. Dieser Server wäre in der Lage, eingehende HTTP-Anfragen abzufangen, die Autorisierungs-Tokens enthalten, die der Angreifer anschließend verwenden kann, um gültige AWS-Credentials zu erhalten. Einen in Python geschriebenen PoC dazu finden Sie im Originalbeitrag.
Fazit und Empfehlungen
Fehlkonfigurationen, insbesondere bei Containern mit übermäßigen Privilegien, können AWS-Credentials exponieren und erhebliche Risiken schaffen, einschließlich der Ausweitung von Privilegien und nicht autorisierter Aktionen innerhalb einer Cloud-Umgebung.
Die Vorführung von Packet-Sniffing- und API-Spoofing-Szenarien zeigt, wie überprivilegierte Container ausgenutzt werden können, um sensible Anmeldedaten abzufangen oder zu manipulieren. Diese Schwachstellen unterstreichen, wie wichtig es ist, das Prinzip der geringsten Privilegien zu befolgen, Container-Konfigurationen angemessen zu skalieren und die Möglichkeiten zur Ausnutzung durch böswillige Akteure zu minimieren.
Die beiden oben beschriebenen Techniken wurden Amazon über das Trend Zero Day Initiative ™ (ZDI) Programm gemeldet und als ZDI-CAN-26891 aufgezeichnet. Die Erklärung von AWS lautet wie folgt:
"Unser Team hat die Untersuchung abgeschlossen und festgestellt, dass das in Ihrem Bericht beschriebene Verhalten kein Sicherheitsproblem ist, sondern ein erwartetes Verhalten, das in den Vertrauensbereich des Knotens selbst fällt und auf der Kundenseite des Modells der geteilten Verantwortung liegt. Es ist die Verantwortung des Knoten- oder Cluster-Betreibers sicherzustellen, dass Anwendungen mit erhöhten Berechtigungen angemessen ausgerichtet sind. Die Fähigkeit des Knotens, Pod-Identitätsrollen zu übernehmen, wird erwartet und steht im Einklang mit dem Modell der Vertrauensgrenze, wie es in den Best Practices zur Pod-Sicherheit von EKS und in der Dokumentation zur gemeinsamen Verantwortung beschrieben ist.
Erkennung von übermäßigen Privilegien in Containern
Trend Vision One™ Container Security ermöglicht es Unternehmen, Richtlinien zu definieren und durchzusetzen, die Container erkennen (und optional blockieren), die mit höheren Privilegien als in der vorgesehenen Konfiguration betrieben werden, wie die in den beschriebenen Exploit-Szenarien
Ausführliche Informationen zur Erstellung und Verwendung von Kubernetes-Richtlinien finden Sie in der Trend Vision One-Dokumentation:
- https://docs.trendmicro.com/en-us/documentation/article/trend-vision-one-kubernetes-prot-policy
- https://docs.trendmicro.com/en-us/documentation/article/c3124722-5232-484a-a42d-3ed454227a6d-kubernetes-protection-policies
Sobald die Richtlinien festgelegt sind, werden die Verstöße erkannt.