How does traffic reach or leave the machine if a network level firewall is restricting access? It seems I have a fundamental misunderstanding of something.
> The firewall/router of GCP blocks broadcast packets sent by VMs, so only the metadata server (169.254.169.254) receives them. However, some phases of the DHCP protocol don't rely on broadcasts, and the packets to be sent can be easily calculated and sent in advance.
> To mount this attack, the attacker needs to craft multiple DHCP packets using a set of precalculated/suspected XIDs and flood the victim's dhclient directly (no broadcasts here). If the XID is correct, the victim machine applies the network configuration. This is a race condition, but since the flood is fast and exhaustive, the metadata server has no real chance to win.
> Google heavily relies on the Metadata server, including the distribution of ssh public keys. The connection is secured at the network/routing layer and the server is not authenticated (no TLS, clear http only). The google_guest_agent process, that is responsible for processing the responses of the Metadata server, establishes the connection via the virtual hostname metadata.google.internal which is an alias in the /etc/hosts file.
He appears to spoof the DHCP packets to get the victim to respond to his rogue metadata server, insert the IP address of his metadata server into the /etc/hosts entry for metadata.google.internal, then is able to have his ssh pubkey installed on the victim so he can ssh to the host.
if you have a network level firewall blocking DHCP traffic, you will not be able to do DHCP.
The way it works for physical hosts is that all machines in the same rack see the dhcp traffic and the TOR has a special ip helper configured where it's sending the DHCP traffic. So it's broadcast in the rack and after that point to point, but still there is zero to no security when it comes to DHCP traffic.
For VMs, I guess the hypervisor acts as the TOR with the same limitations.
