GCP - Network Docker Escape

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Ausgangszustand

In beiden Writeups, in denen diese Technik beschrieben wird, gelang es den Angreifern, innerhalb eines von GCP verwalteten Docker-Containers mit Zugriff auf das Host-Netzwerk root-Zugriff zu erlangen (und die Fähigkeiten CAP_NET_ADMIN und CAP_NET_RAW zu besitzen).

Erklärung des Angriffs

Bei der regulären Analyse des Netzwerkverkehrs auf einer Google Compute Engine-Instanz fallen zahlreiche unverschlüsselte HTTP-Anfragen an die Metadata-Instanz unter 169.254.169.254 auf. Der Google Guest Agent, ein Open-Source-Service, stellt häufig solche Anfragen.

Dieser Agent ist dafür ausgelegt, Änderungen in den Metadaten zu überwachen. Bemerkenswert ist, dass die Metadaten ein Feld für SSH public keys 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 außerdem einen neuen Benutzer anlegen und diesen bei Bedarf zu den 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 gestaltet, dass der Metadata-Server nur dann eine Antwort liefert, wenn sich die Metadaten seit der letzten Abfrage geändert haben, identifiziert durch ein ETag (wait_for_change=true&last_etag=). Zusätzlich wird ein Timeout-Parameter (timeout_sec=) übergeben. Falls sich innerhalb des angegebenen Timeouts nichts ändert, antwortet der Server mit den unveränderten Werten.

Dieser Prozess erlaubt es dem IMDS (Instance Metadata Service), nach 60 Sekunden zu antworten, falls keine Konfigurationsänderung stattgefunden hat, wodurch ein potenzielles Fenster für das Einspeisen einer gefälschten Konfigurationsantwort an den Guest Agent entsteht.

Ein Angreifer könnte dies ausnutzen, indem er eine Man-in-the-Middle (MitM) attack durchführt, die Antwort des IMDS-Servers fälscht und einen neuen Public Key einfügt. Dadurch könnte unautorisierter SSH-Zugriff auf den Host ermöglicht werden.

Escape-Technik

Während ARP-Spoofing in Google Compute Engine-Netzwerken unwirksam ist, kann eine modifizierte Version von rshijack, entwickelt von Ezequiel, verwendet werden, um Pakete in der Kommunikation zu injizieren und den SSH-Benutzer einzuspeisen.

Diese Version von rshijack erlaubt es, die ACK- und SEQ-Nummern als Kommandozeilenargumente einzuspeisen, was das Fälschen einer Antwort vor der echten Antwort des Metadata-Servers erleichtert. Zusätzlich wird ein kleines Shell-Skript verwendet, um eine speziell gestaltete Payload zurückzugeben. Diese Payload veranlasst den Google Guest Agent dazu, den Benutzer wouter mit einem angegebenen Public Key in der Datei .authorized_keys anzulegen.

Das Skript verwendet dasselbe ETag, um zu verhindern, dass der Metadata-Server den Google Guest Agent sofort über unterschiedliche Metadatenwerte informiert, und verzögert so die Antwort.

Um das Spoofing durchzuführen, sind folgende Schritte erforderlich:

  1. Überwache Anfragen an den Metadata-Server mit tcpdump:
Überwache Metadata-Server-Anfragen mit tcpdump ```bash tcpdump -S -i eth0 'host 169.254.169.254 and port 80' & ```

Suchen Sie nach einer Zeile, die etwa so aussieht:

Beispiel tcpdump-Ausgabezeile ```