GCP - Network Docker Escape
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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).
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-Öffentlichkeits-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 Gast-Agenten 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.
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:
Überwachen Sie Anfragen an den Metadatenserver mit tcpdump:
Suchen Sie nach einer Zeile, die ähnlich ist wie:
Senden Sie die gefälschten Metadaten mit dem richtigen ETAG an rshijack:
Dieser Schritt autorisiert den öffentlichen Schlüssel und ermöglicht die SSH-Verbindung mit dem entsprechenden privaten Schlüssel.
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
