Unpatched Virtual Machine Takeover Bug Affects Google Compute Engine

An unpatched security vulnerability affecting Google’s Compute
Engine platform could be abused by an attacker to take over virtual
machines over the network.

“This is done by impersonating the metadata server from the
targeted virtual machine’s point of view,” security researcher Imre
Rad said in an analysis^[1]
published Friday. “By mounting this exploit, the attacker can grant
access to themselves over SSH (public key authentication) so then
they can login as the root user.”

Google Compute Engine (GCE^[2]) is an
infrastructure-as-a-service (IaaS) component of Google Cloud
Platform that enables users to create and launch virtual machines
(VMs) on demand. GCE provides a method for storing and retrieving
metadata in the form of the metadata server^[3], which offers a central
point to set metadata in the form of key-value pairs that’s then
provided to virtual machines at runtime.

According to the researcher, the issue is a consequence of weak
pseudo-random numbers used by the ISC DHCP client, resulting in a
scenario wherein an adversary crafts multiple DHCP packets using a
set of precalculated transaction identifiers (aka XIDs^[4]) and floods the victim’s
DHCP client, ultimately leading to the impersonation of the
metadata server.

Dynamic Host Configuration Protocol (DHCP^[5]) is a network management
protocol used to automate the process of configuring devices on IP
networks. A DHCP server dynamically assigns an IP address and other
network configuration parameters to each client device on a network
so that they can communicate with other networks.

“If the XID is correct, the victim machine applies the network
configuration,” Rad explained in the technical write-up. “This is a
race condition, but since the flood is fast and exhaustive, the
metadata server has no real chance to win. At this point the
attacker is in the position of reconfiguring the network stack of
the victim.”

Given that a metadata server can be used to distribute and manage SSH keys^[6], a client — now having
established a TCP connection to the rogue server — can retrieve the
attacker’s SSH public key, which can then be used by the attacker
to open a remote shell as the root user.

In a potential real-world scenario, the aforementioned attack
chain can be abused by an adversary to gain full access to a
targeted virtual machine as it’s being rebooted or over the
internet in cases when the cloud platform’s firewall is turned
off.

Google was informed about the issue on Sept. 27, 2020, which has
since acknowledged the report, describing it as a “nice catch,” but
has yet to roll out a patch, or provide a timeline for when the
correction will be made available.

“Until the fix arrives, don’t use DHCP or setup a host level
firewall rule to ensure the DHCP communication comes from the
metadata server (169.254.169.254),” Rad noted. “Block UDP/68
between VMs, so that only the metadata server could carry out
DHCP.”

This is far from the first time Rad has identified issues in the
Google Cloud Platform.

In September 2020, Google rectified a local privilege escalation^[7] vulnerability in the
OS Config tool^[8]
that could be exploited by an actor with code execution rights on
the affected GCE VMs to perform unauthorized operations.

Then earlier this January, Rad also found that it was possible
to achieve arbitrary code execution^[9] in a virtual machine by
obtaining a shell on the Cloud SQL database service. The issue was
addressed by Google on Feb. 16, 2021.