The impact of a potential attack is determined by the harm a potential attacker can cause, which is limited by what can be controlled using the hijacked WebSocket. Researching the details of the Theia IDE revealed that the editor also included a shell. While this shell is disabled in Google Cloud Shell's version of the editor, I found out that it can still be spawned and used by sending the appropriate messages to the editor's WebSocket endpoint. Consequently, a potential attacker could execute arbitrary commands on the assigned user's virtual machine and even obtain access to a Cloud Shell user's GCP resources as the virtual machine is automatically authorized to access these resources.

Successfully exploiting the described CSWSH vulnerability would require an attacker to have knowledge of a Cloud Shell virtual machine's IP address or DNS name, thus limiting a potential attack to targeting a specific Cloud Shell user while using a specific Cloud Shell virtual machine instance. In most cases, this would require potential attackers to those being on the same network as the Cloud Shell user. After obtaining the required IP address a potential attacker would then have to convince the targeted Cloud Shell user to visit a malicious website controlled by the attacker, which could perform CSWSH against the Cloud Shell virtual machine at the obtained IP address.

While trying to create a proof of concept I was confronted with two problems:

1. I was not able to perform CSWSH successfully from any other domain than a subdomain of cloudshell.dev. That implied that the malicious page would have to be served from a subdomain of cloudshell.dev.
2. In contrast to the endpoint 970-dot-$ID-dot-devshell.appspot.com, at which the Cloud Shell editor is usually accessed, a Cloud Shell user is not automatically authenticated to the endpoint https://devshell-vm-$UUID.cloudshell.dev:970/ when connecting to their Cloud Shell instance. This proofed to be a problem as the missing authentication cookie meant that no WebSocket connection would be established.

To tackle the first problem I came up with the idea that a potential attacker could repurpose their own Cloud Shell virtual machine to serve the malicious page that would perform the CSWSH. Since each Cloud Shell virtual machine is assigned a cloudshell.dev subdomain this means that the WebSocket connection would have been established from an eligible origin. While accessing endpoints such as https://devshell-vm-$UUID.cloudshell.dev:970/ usually requires authentication using a cookie, which could render serving the malicious page problematic, a potential attacker could inhibit that authentication requirement on their own virtual machine due to the ability to escape from the Docker container to the underlying virtual machine and completely control it.

Trying to understand the authentication mechanism of endpoints at devshell-vm-$UUID.cloudshell.dev, I observed that when requesting a URL such as https://devshell-vm-$UUID.cloudshell.dev:970/index.html without any authentication token I would be forwarded to Google's OAuth process. Upon completion, I would be taken to https://devshell-vm-$UUID.cloudshell.dev/_cloudshell/login where the authentication cookie would be set and eventually I would be redirected back to https://devshell-vm-$UUID.cloudshell.dev:970/index.html, the URL I had initially requested. Further experiments revealed that the URL to be used for redirection in that last step was stored when the initial request was made. However, sending a request with a spoofed host header in the initial request would result in being redirected to that spoofed host in the final step. I had discovered an open redirect vulnerability, which solved the second problem described above, as it would allow a potential attacker to send a Cloud Shell user through Google's OAuth process to have the cookie set, but eventually redirect them to another page controlled by the potential attacker.

A potential attack scenario can thus be summarized as follows:

1. The attacker, wanting to perform CSWSH on the Cloud Shell user associated with devshell-vm-$UUID2.cloudshell.dev, obtains a Cloud Shell instance of their own, devshell-vm-$UUID1.cloudshell.dev. They inhibit the authentication requirement on their own virtual machine and place a malicious page performing CSWSH at https://devshell-vm-$UUID1.cloudshell.dev:970/page.html.
2. The attacker makes a request to https://devshell-vm-$UUID2.cloudshell.dev:970/page.html with a spoofed host header of devshell-vm-$UUID1.cloudshell.dev. Not having an authentication token, they will be redirected to Google's OAuth process.
3. Instead of following the redirection in the previous step the attacker somehow persuades the other Cloud Shell user into following that redirection link. This will take the user through the OAuth process, set the required cookie and eventually forward them to the malicious page at https://devshell-vm-$UUID1.cloudshell.dev:970/page.html to perform CSWSH successfully.