Privilege Escalation EKS T1098.003 Persistence

Sich selbst EKS-Cluster-Admin über einen Access Entry gewähren

Kann sich selbst als Kubernetes-Cluster-Admin auf einen EKS-Cluster abbilden und so dessen AWS-Rollen erreichen.

Ermöglicht Eskalation nur in Kombination. All diese sind zusammen erforderlich:

eks:CreateAccessEntryeks:AssociateAccessPolicy

Wichtigste Erkenntnis

eks:CreateAccessEntry kann sich selbst als Kubernetes-cluster-admin auf einen EKS-Cluster abbilden und so dessen AWS-Rollen erreichen, aber nur, wenn sie zusammen mit eks:AssociateAccessPolicy gehalten wird. Gemeinsam gehalten erreichen sie Administratorzugriff.

Wie ein Angreifer von dieser Berechtigung aus vorgeht.

In Pathbreak erkunden

Warum es gefährlich ist

Ein Principal kann eks:CreateAccessEntry aufrufen, um seinen eigenen IAM-Principal auf den Cluster abzubilden, und dann eks:AssociateAccessPolicy (AmazonEKSClusterAdminPolicy), um Kubernetes-Cluster-Admin zu werden, und zwar eines Clusters, zu dem er zuvor keinen Zugriff hatte. Ein Cluster-Admin kann einen Pod als beliebiges Service-Konto planen und erreicht damit die Node-Group-Rolle, jede IRSA-Rolle und jede Pod-Identity-Rolle, die der Cluster bereitstellt.

In MITRE ATT&CK entspricht dies T1098.003, Account Manipulation: Additional Cloud Roles, unter der Taktik Privilege Escalation. AWS protokolliert dies in CloudTrail als CreateAccessEntry, AssociateAccessPolicy. Der Aufruf erscheint in CloudTrail, geht aber in der normalen Administration unter, daher braucht es eine Regel, damit er auffällt. Er gibt einem Angreifer außerdem eine Möglichkeit, den Zugriff zu behalten, nachdem der erste Zugang geschlossen wurde, daher lohnt es sich, ihn zu beobachten, auch wenn er wie routinemäßige Administration aussieht.

Erkennung

CreateAccessEntryAssociateAccessPolicy

Voraussetzungen

eks:CreateAccessEntry + eks:AssociateAccessPolicy für einen Cluster, dessen authenticationMode API oder API_AND_CONFIG_MAP ist; Erreichbarkeit des Kubernetes-API-Endpoints.

MITRE ATT&CK

T1098.003 · Account Manipulation: Additional Cloud Roles

Taktik

Privilege Escalation

Den Pfad unterbrechen

Eine Maßnahme, die ihn beseitigen würde: eks:CreateAccessEntry / eks:AssociateAccessPolicy auf eine Break-Glass-Rolle beschränken; bei sensiblen Clustern nur CONFIG_MAP-Authentifizierung erfordern; bei neuen Access Entries alarmieren.

Ob sie angewendet werden sollte, hängt davon ab, wie die Berechtigung in Ihrer Umgebung verwendet wird, daher ist es eine geschäftliche Entscheidung und keine automatische Behebung. Dieselbe Berechtigung kann in einem Konto tragend und in einem anderen reines Risiko sein.

Pathbreak bestätigt, ob dieser Pfad in Ihrem Konto auflösbar ist, stuft ihn gegenüber den anderen danach ein, wie viel er eröffnet, und nutzt Ihr Bedrohungsmodell und Ihren Geschäftskontext, um zu zeigen, welche Pfade es wert sind, unterbrochen zu werden.

Fragen

Was erlaubt eks:CreateAccessEntry?

Kann sich selbst als Kubernetes-Cluster-Admin auf einen EKS-Cluster abbilden und so dessen AWS-Rollen erreichen.

Was ist außerdem nötig, damit eks:CreateAccessEntry gefährlich ist?

Es wird erst zur Eskalation, wenn es mit eks:AssociateAccessPolicy kombiniert wird. Für sich allein reicht es nicht aus, was die Kombination leicht übersehbar macht.

Wie wird das Selbst-Gewähren von EKS-Cluster-Admin über einen Access Entry erkannt?

Achten Sie in CloudTrail auf CreateAccessEntry, AssociateAccessPolicy. Der Aufruf erscheint in CloudTrail, geht aber in der normalen Administration unter, daher braucht es eine Regel, damit er auffällt.

Wie unterbricht man diesen Pfad?

Eine Maßnahme, die ihn beseitigen würde, ist: Beschränken Sie eks:CreateAccessEntry / eks:AssociateAccessPolicy auf eine Break-Glass-Rolle; verlangen Sie CONFIG_MAP-only-Authentifizierung bei sensiblen Clustern; alarmieren Sie bei neuen Access Entries. Ob sie angewendet werden sollte, hängt davon ab, wie die Berechtigung in Ihrem Konto verwendet wird, es ist also eine geschäftliche Entscheidung und keine automatische Behebung.

Welche MITRE ATT&CK Technik ist das?

T1098.003, Account Manipulation: Additional Cloud Roles, unter der Taktik Privilege Escalation.

Referenzen

https://attack.mitre.org/techniques/T1098/003/

Finden Sie dies in Ihrem eigenen Konto

Wir führen einen schreibgeschützten Scan eines AWS-Kontos durch und zeigen Ihnen, welche dieser Pfade existieren, nach Blast-Radius priorisiert, mit der Änderung, die jeden einzelnen unterbricht. Erste validierte Pfade innerhalb der Stunde.

Kostenlosen Scan anfragen Sehen Sie sich das 7-minütige Walkthrough an