There’s a vulnerability in Google’s Compute engine platform that attackers could exploit to obtain control of virtual machines over the network. The discovery comes from security researcher Imre Rad who published an analysis on GitHub. He reported about “an unpatched vulnerability affecting virtual machines in Google’s Compute Engine platform.”
What is Google Compute Engine?
Shortly said, it is a customizable compute service that allows the creation and running of virtual machines on Google’s infrastructure. It is an infrastructure-as-a-service component of the Google Cloud Platform, built on the global infrastructure that runs Google’s search engine, Gmail, YouTube. The service enables the storage of metadata in the metadata server, offering a central point to place metadata in key-value pairs for the VMs at runtime.
Unpatched Vulnerability in Google Compute Engine
The exploit is possible “due to weak random numbers used by the ISC DHCP software and an unfortunate combination of additional factors.” The attack can happen by impersonating the Metadata server from the targeted VM’s machine point of view. “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,” Rad explained.
The researcher also outlined three scenarios in which the vulnerability could be exploited successfully:
Attack #1: Targeting a VM on the same subnet (~same project), while it is rebooting. The attacker needs presence on another host.
Attack #2: Targeting a VM on the same subnet (~same project), while it is refreshing the lease (so no reboot is needed). This takes place every half an hour (1800s), making 48 windows/attempts possible a day. Since an F class VM has ~170.000 pps (packet per second), and a day of unixtime + potential pids makes ~86420 potential XIDs, this is a feasible attack vector.
Attack #3: Targeting a VM over the internet. This requires the firewall in front of the victim VM to be fully open. Probably not a common scenario, but since even the webui of GCP Cloud Console has an option for that, there must be quite some VMs with this configuration. In this case the attacker also needs to guess the internal IP address of the VM, but since the first VM seems to get 10.128.0.2 always, the attack could work, still.
It is noteworthy that this is not the first time the same researcher discovers security flaws in Google Cloud Platform. Previous vulnerabilities disclosed by Rad include a local privilege escalation bug in the OS Config tool. and an arbitrary code execution issue in the VM that could be exploited by obtaining a shell on the Cloud SQL database.