A cool bug that can inject a new user with controlled SSH key into a compute instance and the request doing this can be reached via a GET request with no anti-CSRF token.

The bug impacts the “SSH-In-Browser” feature of GCP that allows users to SSH into an instance using their browser. It has a feature that allows you to change your Linux username, to do so it creates whatever username you specify, and generates an SSH key for it adding it to the authorized keys using a request like the following:

https://ssh.cloud.google.com/v2/ssh/projects/{PROJECT-NAME}/zones/{INSTANCE-ZONE}/instances/{INSTANCE-NAME}?newLinuxUsername={USERNAME}

That on its own feels like a bit of a security concern, but without being able to browse the generated SSH keys an attacker couldn’t do much besides create new accounts.

Digging into this though the author found that if they had a username with a : in it, the part after the colon would be included as part of the public key for the account. So triggering the creation of a username like attacker:{public key here}\r\n. Would result in the addition of the user attacker and it would add their public key to the authorized key file.

The trailing \r\n was included as the generated public key would still be appended to their “username” so adding a new line meant the entry in authorized_keys would parse their injected key correctly. Once the attack lands they can then SSH into the instance using their injected key.