Last updated
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
In Kubernetes wird beobachtet, dass ein Standardverhalten die Herstellung von Verbindungen zwischen allen Containern, die sich auf demselben Knoten befinden, erlaubt. Dies gilt unabhängig von den Namensraumunterschieden. Diese Konnektivität erstreckt sich bis zu Layer 2 (Ethernet). Folglich könnte diese Konfiguration das System potenziell Schwachstellen aussetzen. Insbesondere eröffnet sie die Möglichkeit, dass ein bösartiger Container einen ARP-Spoofing-Angriff gegen andere Container, die sich auf demselben Knoten befinden, ausführt. Während eines solchen Angriffs kann der bösartige Container betrügerisch den Netzwerkverkehr abfangen oder ändern, der für andere Container bestimmt ist.
ARP-Spoofing-Angriffe beinhalten, dass der Angreifer gefälschte ARP (Address Resolution Protocol) Nachrichten über ein lokales Netzwerk sendet. Dies führt dazu, dass die MAC-Adresse des Angreifers mit der IP-Adresse eines legitimen Computers oder Servers im Netzwerk verknüpft wird. Nach erfolgreicher Ausführung eines solchen Angriffs kann der Angreifer Daten im Transit abfangen, ändern oder sogar stoppen. Der Angriff wird auf Layer 2 des OSI-Modells ausgeführt, weshalb die standardmäßige Konnektivität in Kubernetes auf dieser Ebene Sicherheitsbedenken aufwirft.
In dem Szenario werden 4 Maschinen erstellt:
ubuntu-pe: Privilegierte Maschine, um zum Knoten zu entkommen und Metriken zu überprüfen (nicht für den Angriff benötigt)
ubuntu-attack: Bösartiger Container im Standard-Namensraum
ubuntu-victim: Opfer Maschine im kube-system Namensraum
mysql: Opfer Maschine im Standard-Namensraum
Wenn Sie mehr Details zu den hier eingeführten Netzwerkthemen wünschen, gehen Sie zu den Referenzen.
Allgemein gesagt, ist Pod-zu-Pod-Netzwerk innerhalb des Knotens über eine Brücke verfügbar, die alle Pods verbindet. Diese Brücke wird „cbr0“ genannt. (Einige Netzwerk-Plugins installieren ihre eigene Brücke.) Die cbr0 kann auch ARP (Address Resolution Protocol) Auflösung durchführen. Wenn ein eingehendes Paket bei cbr0 ankommt, kann es die Ziel-MAC-Adresse mit ARP auflösen.
Diese Tatsache impliziert, dass standardmäßig jeder Pod, der im selben Knoten läuft, in der Lage sein wird, mit jedem anderen Pod im selben Knoten (unabhängig vom Namespace) auf Ethernet-Ebene (Schicht 2) zu kommunizieren.
Daher ist es möglich, ARP-Spoofing-Angriffe zwischen Pods im selben Knoten durchzuführen.
In Kubernetes-Umgebungen finden Sie normalerweise 1 (oder mehr) DNS-Dienste, die normalerweise im kube-system-Namespace ausgeführt werden:
In den vorherigen Informationen können Sie etwas Interessantes sehen, die IP des Dienstes ist 10.96.0.10, aber die IP des Pods, der den Dienst ausführt, ist 172.17.0.2.
Wenn Sie die DNS-Adresse innerhalb eines Pods überprüfen, werden Sie etwas wie folgt finden:
However, the pod weiß nicht, wie es zu dieser Adresse gelangt, da der Pod-Bereich in diesem Fall 172.17.0.10/26 ist.
Therefore, the pod will send the DNS requests to the address 10.96.0.10, which will be übersetzt von cbr0 zu 172.17.0.2.
This means that a DNS request of a pod is immer going to go the bridge to übersetzen die Service-IP zur Endpunkt-IP, selbst wenn der DNS-Server im selben Subnetz wie der Pod ist.
Knowing this, and knowing ARP-Angriffe sind möglich, wird ein Pod in einem Knoten in der Lage sein, den Verkehr zwischen jedem Pod im Subnetz und der Bridge zu überwachen und die DNS-Antworten vom DNS-Server (DNS Spoofing) zu modifizieren.
Moreover, if the DNS-Server im gleichen Knoten wie der Angreifer ist, kann der Angreifer alle DNS-Anfragen eines Pods im Cluster (zwischen dem DNS-Server und der Bridge) abfangen und die Antworten modifizieren.
Unser Ziel ist es, mindestens die Kommunikation vom ubuntu-victim zur mysql zu stehlen.
Wie bereits erwähnt, wenn Sie ein Pod im selben Knoten des DNS-Server-Pods kompromittieren, können Sie MitM mit ARPSpoofing die Bridge und das DNS-Pod überlisten und alle DNS-Antworten ändern.
Sie haben ein wirklich schönes Tool und Tutorial, um dies zu testen unter https://github.com/danielsagi/kube-dnsspoof/
In unserem Szenario, laden Sie das Tool im Angreifer-Pod herunter und erstellen Sie eine **Datei mit dem Namen hosts ** mit den Domains, die Sie spoofen möchten, wie:
Führen Sie den Angriff auf die ubuntu-victim-Maschine aus:
Wenn Sie versuchen, Ihr eigenes DNS-Spoofing-Skript zu erstellen, wird es nicht funktionieren, wenn Sie nur die DNS-Antwort ändern, da die Antwort eine src IP die IP-Adresse des bösartigen Pods haben wird und nicht akzeptiert wird. Sie müssen ein neues DNS-Paket mit der src IP des DNS generieren, an den der Opfer die DNS-Anfrage sendet (was etwa 172.16.0.2 entspricht, nicht 10.96.0.10, das ist die K8s DNS-Service-IP und nicht die DNS-Server-IP, mehr dazu in der Einleitung).
Das Tool Mizu ist ein einfaches, aber leistungsstarkes API Verkehrsbetrachter für Kubernetes, das es Ihnen ermöglicht, alle API-Kommunikationen zwischen Mikrodiensten zu sehen, um Ihnen beim Debuggen und Beheben von Regressionen zu helfen. Es wird Agenten in den ausgewählten Pods installieren und deren Verkehrsinfos sammeln und Ihnen auf einem Webserver anzeigen. Sie benötigen jedoch hohe K8s-Berechtigungen dafür (und es ist nicht sehr heimlich).
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
