Dear Readers,
Today I want to share a short write-up about a stored cross-site scripting (XSS) issue I found on the Google Cloud Console. I consider it a lucky find. Some of you may remember the tweet I sent to Frans Rosén after he discovered a vulnerability on Google Payments:
As it turned out, among the unsuccessful XSS payloads I saved on my Google account, there was one that actually fired. But unexpectedly. When I was originally testing my payloads, I never managed to trigger the execution until recently and inadvertently. But let’s start from the beginning.
As you may know, Google is offering a 60 day free trial with a budget of $300 and all that is required is entering (correct) payment information to prove you are not a robot. So, I did that a few weeks ago and started entering XSS payloads in every field I could find … and nothing fired, I failed. A situation I assume we’ve all been in, right? Well, after two months or so, I received an invoice from Google and a notification that my free trial what ending. Wanting to avoid the charges, I quickly logged into my account and deleted my project, which was titled “> <img src = x onerror = javascript: alert (1); … and boom, my payload got Executed!
As it turned out, Google was not filtering the error message once a project which canceled. Astute readers may question why this was not classified as a low level self XSS. This issue was escalated because the Google Cloud Platform can be used by multiple users; if a user creates a project with a malicious XSS payload, that payload could be used against the project administrator to execute malicious javascript (if they delete the project, which seems likely).
For those unfamiliar, and the knowledge hungry, here’s how the payload gets reflected in the content of the site: the first quote and angle bracket, “>” close the preceding HTML tag which allowed my injected <script> tag to be rendered in the page source. For this POC, I simply used the img src = x payload. Since x is not a valid url, this is designed to fail immediately with a 404 HTTP response, which will then invoke the onerror event to execute a javascript function. However, thanks to @Jobert from HackerOne for noting, that it’s possible this could have returned a 2xx or 3xx redirecting to a 2xx in which case my payload would not have fired. In my testing, I just added the function alert to create a popup but malicious users could have used a cookie stealer or the Browser Exploitation Framework Project (BEEF) to escalate this issue (I did not have to tell Google did though).
Here’s the video POC I sent in for the Google VRP:
That’s it 🙂
Thanks to Peter @yaworsk for editing :-)! Follow him and support him by buying his book ! For more technical writeups have a look at ERNW’s Insinuator blog, I blog there now and then about Mobile Security and IPv6.
If you have any questions please feel free to contact me at patrik.fehrenbach (at) it-securityguard.com
German 
English