GCP - Network Docker Escape
Initial State
In both writeups where this technique is specified, the attackers managed to get root access inside a Docker container managed by GCP with access to the host network (and the capabilities CAP_NET_ADMIN and CAP_NET_RAW).
Attack Explanation
On a Google Compute Engine instance, regular inspection of network traffic reveals numerous plain HTTP requests to the metadata instance at 169.254.169.254. The Google Guest Agent, an open-source service, frequently makes such requests.
This agent is designed to monitor changes in the metadata. Notably, the metadata includes a field for SSH public keys. When a new public SSH key is added to the metadata, the agent automatically authorizes it in the .authorized_key file. It may also create a new user and add them to sudoers if needed.
The agent monitors changes by sending a request to retrieve all metadata values recursively (GET /computeMetadata/v1/?recursive=true). This request is designed to prompt the metadata server to send a response only if there's any change in the metadata since the last retrieval, identified by an Etag (wait_for_change=true&last_etag=). Additionally, a timeout parameter (timeout_sec=) is included. If no change occurs within the specified timeout, the server responds with the unchanged values.
This process allows the IMDS (Instance Metadata Service) to respond after 60 seconds if no configuration change has occurred, creating a potential window for injecting a fake configuration response to the guest agent.
An attacker could exploit this by performing a Man-in-the-Middle (MitM) attack, spoofing the response from the IMDS server and inserting a new public key. This could enable unauthorized SSH access to the host.
Escape Technique
While ARP spoofing is ineffective on Google Compute Engine networks, a modified version of rshijack developed by Ezequiel can be used for packet injection in the communication to inject the SSH user.
This version of rshijack allows inputting the ACK and SEQ numbers as command-line arguments, facilitating the spoofing of a response before the real Metadata server response. Additionally, a small Shell script is used to return a specially crafted payload. This payload triggers the Google Guest Agent to create a user wouter with a specified public key in the .authorized_keys file.
The script uses the same ETag to prevent the Metadata server from immediately notifying the Google Guest Agent of different metadata values, thereby delaying the response.
To execute the spoofing, the following steps are necessary:
Monitor requests to the Metadata server using tcpdump:
Look for a line similar to:
Send the fake metadata data with the correct ETAG to rshijack:
This step authorizes the public key, enabling SSH connection with the corresponding private key.
References
Last updated