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 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) 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, 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) and floods the victim’s DHCP client, ultimately leading to the impersonation of the metadata server.
Dynamic Host Configuration Protocol (DHCP) 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.
By hitting the victim VM with a stream of DHCP packets, the idea is to leverage the “predictable” XID and make the client accept an attacker-sent packet over Google’s DHCP server packets, at which point the network stack on the victim VM can configured to use the rogue metadata server.
“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, 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 vulnerability in the OS Config tool 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 in a virtual machine by obtaining a shell on the Cloud SQL database service. The issue was addressed by Google on Feb. 16, 2021.