How I Found an XSS in Google using Acunetix

I’m an independent security researcher and make my living mostly by cashing in on bounties. I use a lot of manual tools but I also find Acunetix very useful. Recently, I found out that Acunetix can even help me find a vulnerability in Google. Here is how it happened.

The Acunetix Scan

I’m not the only independent whitehat hacker who uses Acunetix – my colleagues do, too. One of my colleagues, Link, recently sent me a result of an Acunetix scan in the form of an HTTP request dump and said that Acunetix reported an XSS issue:

GET /products/machine-learning/partners/?tab=1"%20GStL=rIOm([!%2B!])%20gBJ=" HTTP/1.1
Referer: https://cloud.google.com/
Connection: keep-alive
Cookie: cookies=1
Accept: */*
Accept-Encoding: gzip,deflate
Host: cloud.google.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.103 Safari/537.36

It seemed interesting, so I decided to analyze it further and try to replicate the issue manually.

Preliminary Analysis

First, let me explain what happens if you click the link reported by Acunetix:

https://cloud.google.com/products/machine-learning/partners/?tab=1"%20GStL=rIOm([!%2B!])%20gBJ="

• The tab parameter is used to select the tab on the web page. I did not have to dig deeper to replicate the issue, but it looked to me like this value was sent to an AngularJS tag <md-tabs> and then used by JavaScript as a selector value.
• If we attempt an XSS attack, we will stay in the context of the <md-tabs> tag (because < and > chars will be automatically converted to HTML entities). Therefore, we cannot run JavaScript code without user interaction. This makes things more difficult, but not impossible.

Attack Concept

Based on the preliminary analysis, I decided to try to use the onmouseover handler to run JavaScript. For this handler to work, the user would have to move their mouse pointer onto the target element, which is very small. To mitigate this, I decided to use CSS styles:

• position:fixed; and top:0;left:0; – move the element to the upper-left corner of the page
• width:100%; and height:100%; – made the element fill the entire page
• z-index:100000; – moved the element above all other elements on the page
• border-color:red;border-style:solid;border-width:10px; – added a thick red border for viewer experience and test purposes

Based on these assumptions, the first attempted XSS link was as follows:

https://cloud.google.com/products/machine-learning/partners/?tab=1 onmouseover=alert(document.cookie) style=border-color:red;border-style:solid;border-width:10px;position:fixed;top:0;left:0;width:100%;height:100%;z-index:100000 a=

I put the link into the browser and… nothing happened.

Bugfixing the XSS Code

To analyze, why my XSS attempt did not work, I used the webmaster console in the browser. I refreshed the link and realized that I forgot one important thing: The semicolon is considered a special character in a URL context. Therefore, we need to URL encode it. For safety, I decided to URL encode several other special characters:

https://cloud.google.com/products/machine-learning/partners/?tab=1%20onmouseover=alert(document.cookie)%20style=border-color:red%3bborder-style:solid%3bborder-width:10px%3bposition:fixed%3btop:0%3bleft:0%3bwidth:100%%3bheight:100%%3bz-index:100000%20a=

The above link worked. Even the slightest mouse movement over the page would run the JavaScript code and display the cookie.

The Bounty

The XSS was reported to Google as discovered together with my colleague, Link.

• Reported to Google: June 15, 2019
• Google replied: June 19, 2019
• Issue fixed: June 24, 2019
• Bounty received: $3133.70

THE AUTHOR

Andrey Leonov
Independent Security Researcher

Andrey Leonov (4lemon) is an independent web application security researcher and an Acunetix fan. He often works together on security research with his colleague, Link.