Attacking Kubernetes (Container-Umgebungen) – Teil 2

Microsoft hat im Frühling 2020 eine Liste mit verschiedenen Angriffs-Szenarien für Kubernetes Umgebungen vorgestellt. Die Liste stellt 9 verschiedene Taktiken (horizontal) mit den relevanten Techniken (vertikal) dazu dar. Im ersten Teil diese Blogserie haben wir die drei Taktiken Initial Access, Execution und Persistence angeschaut (hier geht’s zu Teil 1: www.tec-bite.ch/attacking-kubernetes-container-umgebungen-teil-1/). Der zweite Teil der Blogserie wurde den nächsten fünf Taktiken auf der Liste gewidmet: Privilege Escalation, Defense Evasion, Credential Access, Discovery und Lateral Movement (Teil 2: www.tec-bite.ch/attacking-kubernetes-container-umgebungen-teil-2/).

Heute im dritten Teil der Serie gehen wir noch auf die Impact-Taktik ein und zeigen, was man ausserdem noch beachten sollte.

Quelle: https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/, abgerufen am 29.07.20

Die Liste ist wie die ATT&CK(1) Matrix von MITRE (Link: attack.mitre.org) gestaltet und listet 9 verschiedene Taktiken (horizontal) mit den relevanten Techniken (vertikal) dazu(2).

(1) ATT&CK steht für Adversarial Tactics, Techniques, and Common Knowledge, also für Angriffstaktiken, Techniken und allgemeines Wissen.

(2) Es gibt von MITRE übrigens auch eine allgemeinere ATT&CK Matrix für die Cloud (Link: attack.mitre.org/matrices/enterprise/cloud/)


Taktiken 1-8

Die Taktiken 1-3 sind im ersten Teil der Blogserie nachzulesen: Attacking Kubernetes (Container-Umgebungen) – Teil 1

Und die Taktiken 4-8 werden im zweiten Teil der Blogserie besprochen: Attacking Kubernetes (Container-Umgebungen) – Teil 2

Abschliessend noch die letzte Staffel von Techniken, die von den ersten zwei Einträgen übrig geblieben ist:


9. Impact

Die sogenannte “Impact-Taktik” besteht aus Techniken, die von Angreifern eingesetzt werden, um das normale Verhalten der Umgebung zu stören, missbrauchen oder gar zu zerstören.


9.1 Data destruction

Angreifer können versuchen, Daten und Ressourcen im Cluster regelrecht zu zerstören. Dazu gehört das Löschen von Deployments, Konfigurationen, Speicher- und Rechenressourcen.


9.2 Resource hijacking

Angreifer können eine kompromittierte Ressource für die Ausführung von eigenen Tasks missbrauchen. Ein häufiger Missbrauch besteht darin, kompromittierte Ressourcen für das Mining digitaler Währungen zu verwenden. Angreifer, die Zugriff auf einen Container im Cluster haben oder die Berechtigung haben, neue Container zu erstellen, können diese für solche Aktivitäten nutzen.


9.3 Denial of service

Angreifer können auch versuchen, eine Denial-of-Service-Attacke (DoS) durchzuführen, wobei der Dienst für die legitimen Benutzer nicht mehr verfügbar ist. In Container-Clustern gehören dazu Versuche, die Verfügbarkeit der Container, der Custer Nodes oder des API-Servers zu beeinträchtigen.

 

Microsoft bietet hier noch mehr Informationen zu Container Security: docs.microsoft.com/en-us/azure/security-center/container-security

Analog dazu von AWS (für ECS): docs.aws.amazon.com/AmazonECS/latest/developerguide/security.html

Und von Google (GCP): cloud.google.com/container-registry/docs/container-analysis


Was haben wir vergessen?

Einiges. Das von Microsoft angepasste Mitre Att&ck Tool für Kubernetes ist ein wertvolles und interessantes Dokument. Man kann vieles daraus lernen und es zeigt klar auf, dass viele Techniken auch in Container-Umgebungen ähnlich sind, wie bei normalen Cloud- oder On-Premises-Umgebungen. Interessant wird es dann, wenn man sich überlegt, was in einem Kubernetes-Cluster eben anders läuft als in On-Premises Umgebungen. Genau diese Punkte könnten dann zusätzliche Schwachstellen darstellen.

Einerseits sollte man sich immer überlegen, ob die Plattform selber Schwachstellen aufzeigt oder aufzeigen könnte. Innerhalb einer K8s Plattform laufen viele verschiedene Services (von Monitoring über Controllers bis hin zu Service-Mesh, usw.) die selber Schwachstellen haben können und dadurch ausgenützt werden könnten. Solche sogenannte Supply-Chain Attacken sind nicht unüblich und mit dem kürzlichen Solarwinds-Hack wurde wieder klar aufgezeigt, wie gefährlich sie sein können.

Auch die gesamte CI/CD Pipeline ist ein idealer Angriffsvektor, von den CI/CD Tools selber, bis hin zu den Automatisierungstools und natürlich den Repositories. Gerade das Image-Scanning von Containern im Repository sollte eigentlich in jeder Container-Umgebung umgesetzt werden. Man sollte auch die menschliche Komponente nicht vergessen. Kubernetes Umgebungen sind ziemlich komplex und wenn man dann noch die CI/CD Pipeline dazuzählt, gibt es sehr viele Möglichkeiten, etwas falsch zu konfigurieren (vor allem, aber nicht nur, /etcd und kubelet). Deswegen gibt es auch immer mehr CSPM (Cloud Security Posture Management) Lösungen, die die Konfiguration von Container-Umgebungen (und spezifisch auch Kubernetes) auch verifizieren und gegenüber Standards vergleichen können.

Es überrascht nicht, dass oft die API’s von Container-Umgebungen als klares Angriffsziel gesehen werden. In einem Kubernetes Cluster gibt es fast keinen besseren Angriffsvektor, denn wenn man nur schon eine API Schwachstelle gefunden hat, ist es oft trivial diese auszunützen und eine Privilege Escalation durchzuführen.

Es gibt viele weitere Punkte auf die man achten sollte, die Liste ist ziemlich lange. Vieles hängt wiederum von der Container-Umgebung selber ab. Wir empfehlen eine klare Visibilität des Clusters und der CI/CD Pipeline und aller Zulieferanten von Anfang an zu erstellen und dies auch kontinuierlich up-to-date zu halten und regelmässig zu hinterfragen.


Fazit

Genügt es also, diese 9 Taktiken als Grundlage zu nehmen, um eine Kubernetes-Umgebung abzusichern? Das hängt, wie immer, wenn es um Security geht, stark von anderen Umständen ab. Wo liegt Ihre Container Umgebung (On-Prem oder in der Cloud)? Wie betreiben Sie die Container (Openshift, Kubernetes, über eine Managed Umgebung vie ECS, GKE oder AKS)? Haben Sie eine isolierte Umgebung aufgebaut oder sind Ihre Cluster Teil einer Entwicklungskette (mit eigenen Repositories und CI/CD)? usw.

Man muss sein Kubernetes Cluster nicht völlig abgeschottet im Datacenter als Black-Box betreiben, aber man sollte auch nicht einfach ECS/GKE oder AKS hochfahren und meinen, dass die Cloud Provider sich dann um die gesamte Sicherheit kümmern (Tipp: machen sie nicht).

Und zu guter Letzt noch etwas Eigenwerbung, wir helfen Ihnen gerne, Ihre Container-Umgebung sicher aufzubauen und haben in unserem Portfolio Lösungen, die speziell für Kubernetes und Container gebaut worden sind.


Links

ATT&CK(1) Matrix von MITRE: attack.mitre.org

Microsoft Blog – Threat matrix for Kubernetes: www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/

Cloud Security von AVANTEC: www.avantec.ch/themen/cloud-security/


Der Beitrag Attacking Kubernetes (Container-Umgebungen) – Teil 3 erschien zuerst auf Tec-Bite.