You can hijack Google Cloud VMs using DHCP floods, says this guy, once the stars are aligned and...

An Ocean's 11 of exploitation involving guessable random numbers and hostname shenanigans

Google Compute Engine virtual machines can be hijacked and made to hand over root shell access via a cunning DHCP attack, according to security researcher Imre Rad.

Though the weakness remains unpatched, there are some mitigating factors that diminish the potential risk. Overall, it's a pretty neat hack if a tad impractical: it's an Ocean's Eleven of exploitation that you may find interesting from a network security point of view.

In a write-up on GitHub, Rad explains that attackers can take over GCE VMs because they rely on ISC DHCP software that uses a weak random number generator.

A successful attack involves overloading a victim's VM with DHCP traffic so that it ends up using a rogue attacker-controlled metadata server, which can be on the same network or on the other side of the internet. The DHCP flood would typically come from a neighboring attacker-controlled system hosted within Google Cloud.

When the technique is pulled off just right, the VM uses the rogue metadata server for its configuration instead of an official Google one, and ultimately the miscreant can log into the VM via SSH as the root user.

ISC's implementation of the DHCP client, according to Rad, relies on three things to generate a random identifier: the Unix time when the process is started; the PID of the dhclient process; and the sum of the last four bytes of the Ethernet addresses (MAC) of the machine's network interface cards. This random number, XID, is used by the client to track its communications with Google's DHCP servers.

So the idea is to hit the victim VM with a stream of DHCP packets, with a best guess for the XID, until the dhclient accepts them over Google's legit DHCP server packets, at which point you can configure the network stack on the victim VM to use the rogue metadata server by aliasing Google server hostnames.

Two of these XID ingredients, Rad says, are predictable. The last four bytes of the MAC address are the same as the internal IP address of the box. And the PID gets assigned by the Linux kernel in a linear way.

"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," explains Rad.

"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."

Crafting the correct XID in a flood of DHCP packets is made easier by the insufficient randomization scheme. Doing so allows the attacker to reconfigure the target's network stack at will.

Shouldn't be news to Google

According to Rad, Google relies on its metadata servers to handle the distribution of SSH keys. By impersonating a metadata server, SSH access can be granted to the attacker.

Rad's technique is based on an attack disclosed last year by security researcher Chris Moberly, but differs in that the DHCP flooding is done remotely and the XIDs are guessed.

In the three attack scenarios devised by Rad, two require the attacker to be on the same subnet as the target VM to send the flood of DHCP traffic. In one scenario, the victim VM needs to be rebooting, and in the other, it is refreshing its DHCP lease. The third allows for a remote attack over the internet but requires the firewall in front of the target VM to be fully open.

Rad concedes this third case is "probably not a common scenario" but notes that GCP Cloud console provides that option and speculates there are likely to be VMs with that configuration.

Suggested defense techniques include not referring to the metadata server using its virtual hostname (metadata.google.internal), not managing the virtual hostname via DHCP, securing metadata server communication using TLS, and blocking UDP on Ports 67/68 between VMs.

Google was said to be informed of this issue back in September 2020. After nine months of inaction, Rad published his advisory. The Chocolate Factory did not immediately respond to a request for comment. We imagine Google Cloud may have some defenses in place, such as detection of weird DHCP traffic, for one. ®

Speaking of Google, its security expert Felix Wilhelm found a guest-to-host escape bug in the Linux KVM hypervisor code for AMD Epyc processors that was present in kernel versions 5.10 to 5.11, when it was spotted and patched.