Specifically, the attack exploits a weakness in Google Compute Engine (GCE), which is Google Cloud’s Infrastructure-as-a-Service (IaaS) product.
Rad explains that attackers can take over GCE VMs by taking advantage of a weakness in the random number generator of the ISC DHCP server they use by default, together with “an unfortunate combination of additional factors".
We're looking at how our readers use VPNs with streaming sites like Netflix so we can improve our content and offer better advice. This survey won't take more than 60 seconds of your time, and you can also choose to enter the prize draw to win a $100 Amazon voucher or one of five 1-year ExpressVPN subscriptions.
- Check our list of the best cloud computing services right now
- These are the best virtual machine software
- We’ve also rounded up the best cloud databases on the market
“[The hijacking] is done by impersonating the metadata server from the targeted virtual machine's 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,” writes Rad.
Probable, but impractical?
In his writeup, Rad explains that the attack consists of two phases. The first involves overloading a victim's VM with DHCP traffic in order to get it to use a malicious attacker-controlled metadata server instead of an official Google one.
Once the victim’s VM is listening to the rogue metadata server for configuration information, the attacker can send across their SSH public key and gain root access to the VM.
Rad says his technique is inspired by an attack vector shared last by Chris Moberly, another security researcher.
Parsing Rad’s information, The Register is of the opinion that the attack is impractical, despite the fact that Rad reproduces three proof of concepts that successfully exploit the vulnerability.
Rad says he reported the vulnerability to Google in September 2020, but hasn’t heard back since. He suspects that, since Google hasn’t closed his bug report, there could be “some technical complexity” that prevents them from deploying a network-level remediation.
Google did not respond immediately to our request for clarification.
On background, Google told TechRadar Pro it has taken steps to prevent the exploitation of the vulnerability through either the internet or external VM IP traffic, although a complete mitigation has not yet been deployed.
According to Google, customers with untrusted internal traffic would be wise to ensure the incoming UDP port 68 is blocked by firewalls to head off malicious activity.
- Check our roundup of the best cloud storage services