Skip to content

Latest commit

 

History

History
75 lines (48 loc) · 6.29 KB

gcp-network-docker-escape.md

File metadata and controls

75 lines (48 loc) · 6.29 KB
Raw

GCP - Network Docker Escape

Support HackTricks and get benefits!

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

When you inspect network traffic on a regular Google Compute Engine instance you will see a lot of plain HTTP requests being directed to the metadata instance on 169.254.169.254. One service that makes such requests is the open-sourced Google Guest Agent. Request example:

This agent monitors the metadata for changes. Inside the metadata there is a field with authorized SSH public keys.
Therefore, when a new public SSH key appears in the metadata, the agent will authorize it in the user’s .authorized_key file and it will create a new user if necessary and adding it to sudoers.

The way the Google Guest Agent monitors for changes is through a call to retrieve all metadata values recursively (GET /computeMetadata/v1/?recursive=true), indicating to the metadata server to only send a response when there is any change with respect to the last retrieved metadata values, identified by its Etag (wait_for_change=true&last_etag=).

This request also includes a timeout (timeout_sec=), so if a change does not occur within the specified amount of time, the metadata server responds with the unchanged values.

This makes the IMDS to respond after 60 seconds if there was no configuration change in that interval, allowing a window for injecting a fake configuration response to the guest agent from the IMDS.

Therefore, if an attacker manages to perform a MitM attack, he could spoof the response from the IMDS server inserting a new public key to allow a new user to access via SSH to the host.

Escape

ARP spoofing does not work on Google Compute Engine networks, however, Ezequiel generated this modified version of rshijack **** that can be used to inject a packet in the communication to inject the SSH user.

This modified version of rshijack allows to pass the ACK and SEQ numbers as command-line arguments, saving time and allowing us to spoof a response before the real Metadata response came.

Moreover, this small Shell script **** that would return a specially crafted payload that would trigger the Google Guest Agent to create the user wouter, with our own public key in its .authorized_keys file.

This script receives the ETag as a parameter, since by keeping the same ETag, the Metadata server wouldn’t immediately tell the Google Guest Agent that the metadata values were different on the next response, instead waiting the specified amount of seconds in timeout_sec.

To achieve the spoofing, you should watch requests to the Metadata server with tcpdump: tcpdump -S -i eth0 'host 169.254.169.254 and port 80' & waiting for a line that looked like this:

{% code overflow="wrap" %}

<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

{% endcode %}

We you see that value send the fake metadata data with the correct ETAG to 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

And this should make the agent authorize that public key that will allow you to connect via SSH with the private key.

References

Support HackTricks and get benefits!