GCP - Network Docker Escape

Support HackTricks

Initial State

In beiden Berichten, in denen diese Technik spezifiziert ist, gelang es den Angreifern, root-Zugriff innerhalb eines Docker-Containers zu erhalten, der von GCP verwaltet wird, mit Zugriff auf das Host-Netzwerk (und den Berechtigungen CAP_NET_ADMIN und CAP_NET_RAW).

Attack Explanation

Auf einer Google Compute Engine-Instanz zeigt die regelmäßige Überprüfung des Netzwerkverkehrs zahlreiche unverschlüsselte HTTP-Anfragen an die Metadata-Instanz unter 169.254.169.254. Der Google Guest Agent, ein Open-Source-Dienst, stellt häufig solche Anfragen.

Dieser Agent ist darauf ausgelegt, Änderungen in den Metadaten zu überwachen. Besonders hervorzuheben ist, dass die Metadaten ein Feld für SSH-öffentliche Schlüssel enthalten. Wenn ein neuer öffentlicher SSH-Schlüssel zu den Metadaten hinzugefügt wird, autorisiert der Agent ihn automatisch in der Datei .authorized_key. Er kann auch einen neuen Benutzer erstellen und ihn bei Bedarf zu sudoers hinzufügen.

Der Agent überwacht Änderungen, indem er eine Anfrage sendet, um alle Metadatenwerte rekursiv abzurufen (GET /computeMetadata/v1/?recursive=true). Diese Anfrage ist so konzipiert, dass der Metadatenserver nur dann eine Antwort sendet, wenn es seit dem letzten Abruf eine Änderung in den Metadaten gegeben hat, identifiziert durch ein Etag (wait_for_change=true&last_etag=). Zusätzlich wird ein Timeout-Parameter (timeout_sec=) einbezogen. Wenn innerhalb des angegebenen Timeouts keine Änderung erfolgt, antwortet der Server mit den unveränderten Werten.

Dieser Prozess ermöglicht es dem IMDS (Instance Metadata Service), nach 60 Sekunden zu antworten, wenn keine Konfigurationsänderung stattgefunden hat, was ein potenzielles Fenster für das Injizieren einer gefälschten Konfigurationsantwort an den Gastagenten schafft.

Ein Angreifer könnte dies ausnutzen, indem er einen Man-in-the-Middle (MitM)-Angriff durchführt, die Antwort des IMDS-Servers fälscht und einen neuen öffentlichen Schlüssel einfügt. Dies könnte unbefugten SSH-Zugriff auf das Host-System ermöglichen.

Escape Technique

Während ARP-Spoofing in Google Compute Engine-Netzwerken ineffektiv ist, kann eine modifizierte Version von rshijack, die von Ezequiel entwickelt wurde, für die Paket-Injektion in der Kommunikation verwendet werden, um den SSH-Benutzer einzufügen.

Diese Version von rshijack ermöglicht die Eingabe der ACK- und SEQ-Nummern als Befehlszeilenargumente, was das Spoofing einer Antwort vor der echten Antwort des Metadatenservers erleichtert. Zusätzlich wird ein kleines Shell-Skript verwendet, um eine speziell gestaltete Payload zurückzugeben. Diese Payload löst den Google Guest Agent aus, um einen Benutzer wouter mit einem angegebenen öffentlichen Schlüssel in der Datei .authorized_keys zu erstellen.

Das Skript verwendet dasselbe ETag, um zu verhindern, dass der Metadatenserver den Google Guest Agent sofort über unterschiedliche Metadatenwerte informiert, wodurch die Antwort verzögert wird.

Um das Spoofing durchzuführen, sind die folgenden Schritte erforderlich:

  1. Überwachen Sie Anfragen an den Metadatenserver mit tcpdump:

tcpdump -S -i eth0 'host 169.254.169.254 and port 80' &

Suchen Sie nach einer Zeile, die ähnlich ist wie:

<TIME> IP <LOCAL_IP>.<PORT> > 169.254.169.254.80: Flags [P.], seq <NUM>:<TARGET_ACK>, ack <TARGET_SEQ>, win <NUM>, length <NUM>: HTTP: GET /computeMetadata/v1/?timeout_sec=<SECONDS>&last_etag=<ETAG>&alt=json&recursive=True&wait_for_change=True HTTP/1.1
  1. Senden Sie die gefälschten Metadaten mit dem richtigen ETAG an rshijack:

fakeData.sh <ETAG> | rshijack -q eth0 169.254.169.254:80 <LOCAL_IP>:<PORT> <TARGET_SEQ> <TARGET_ACK>; ssh -i id_rsa -o StrictHostKeyChecking=no wouter@localhost

Dieser Schritt autorisiert den öffentlichen Schlüssel und ermöglicht die SSH-Verbindung mit dem entsprechenden privaten Schlüssel.

Referenzen

Unterstütze HackTricks

Last updated