An unpatched security issue in Google’s Compute Engine (GCE) could allow an attacker to take over a virtual machine without requiring the user to enter any credentials.
“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 is a component of the Google Cloud Platform that simplifies the creation and deployment of virtual machines (VMs).
The issue pertains to the weak pseudo-random numbers used in the ISC DHCP client. It can lead to the exploitation of the metadata server by creating multiple DHCP packets using a set of XIDs, or precalculated transaction identifiers, to flood the victim’s DHCP client.
The Dynamic Host Configuration Protocol (DHCP) is a network management protocol that enables network administrators to manage the configuration of devices on IP networks.
The idea is to hit the victim’s VM with a stream of DHCP requests and use the “predictable” XID, which will cause it to accept an attacker-sent packet and not the Google’s DHCP server packets. The attacker can configure the network stack on the victim VM 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.”
A metadata server can distribute and manage SSH keys. After the hack, it can also retrieve the attacker’s SSH public key and allow the exploitation by opening a remote shell as the root user.
An attacker can execute this attack chain to access a targeted virtual machine when the cloud platform’s firewall settings are turned off, the researcher noted.
Google was informed about the issue in September 2020, but the company has not yet released a patch or a timeline for when the issue will be fixed.
“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.”
