Hacking the Giant: How I Discovered Google’s Vulnerability and Hall of Fame Recognition

8 months ago 71

BOOK THIS SPACE FOR AD

ARTICLE AD

In the world of cybersecurity, the hunt for vulnerabilities is an ongoing quest. Recently, I stumbled upon a discovery that sent shockwaves through my system: an XSS (Cross-Site Scripting) vulnerability lurking within one of Google’s sub-domains. This vulnerability not only revealed a potential entry point for malicious actors but also shed light on the critical importance of robust cybersecurity practices, even for tech giants like Google. This discovery led to my advancement in the Google’s Hall of Fame and a reward. Read on to find out how much Google rewards for this discovery.

As a cybersecurity enthusiast, I often engage in what some might call “ethical hacking” — the search for vulnerabilities within systems with the intent to improve security. While exploring various sub-domains of popular websites, I came across an unassuming sub-domain and URL linked to Google.

This URL caught my eye:
https://aihub.cloud.google.com/url?q=https://cidadesmineradoras.com.br

At first glance, I had a gut feeling that this URL might be vulnerable.

Bug Hunting Tip #1: Always trust your instincts. If a URL seems vulnerable to you, it probably is!

I attempted to input various payloads into the ‘q’ parameter to see if I could uncover anything interesting or find a vulnerability, but unfortunately, I was unsuccessful. After trying different payloads without success, I decided to focus on my favorite XSS payload. I began tweaking and refining it.

Payload to Use: “><SvG/onload=alert(document.domain) id=hncaga>

To make this work correctly, I need to ‘URL encode’ special characters such as spaces, parentheses, etc.

The complete URL will be: https://aihub.cloud.google.com/url?q=https://cidadesmineradoras.com.br%22%3E%3CSvG/onload=alert(document.domain)%20id=hncaga%3E

Of course, this also didn’t work because this payload had already been included in my previous tests on this target URL.

What I did next was ‘URL encode’ all the characters of my payload to see if it could bypass filtering.

URL with Encoded Payload: https://aihub.cloud.google.com/url?q=%68%6e%63%61%67%61%22%3e%3c%53%76%47%2f%6f%6e%6c%6f%61%64%3d%61%6c%65%72%74%28%64%6f%63%75%6d%65%6e%74%2e%64%6f%6d%61%69%6e%29%20%69%64%3d%68%6e%63%61%67%61%3e

I tried to check this encoded payload, and the result is …….. still unsuccessful :(

I almost gave up on the target URL, but something crossed my mind.

Bug Hunting Tip #2: NEVER GIVE UP!

In finding vulnerabilities and dealing with payloads, sometimes you need to encode the payload multiple times. You’ll be surprised that it works in many cases.

So what I did was I encoded the encoded payload again using ‘URL Encode.’ This means that after URL encoding the standard payload, the result of the encoding is then encoded again using ‘URL Encode’.

URL with Double Encoded Payload: https://aihub.cloud.google.com/url?q=%25%36%38%25%36%65%25%36%33%25%36%31%25%36%37%25%36%31%25%32%32%25%33%65%25%33%63%25%35%33%25%37%36%25%34%37%25%32%66%25%36%66%25%36%65%25%36%63%25%36%66%25%36%31%25%36%34%25%33%64%25%36%31%25%36%63%25%36%35%25%37%32%25%37%34%25%32%38%25%36%34%25%36%66%25%36%33%25%37%35%25%36%64%25%36%35%25%36%65%25%37%34%25%32%65%25%36%34%25%36%66%25%36%64%25%36%31%25%36%39%25%36%65%25%32%39%25%32%30%25%36%39%25%36%34%25%33%64%25%36%38%25%36%65%25%36%33%25%36%31%25%36%37%25%36%31%25%33%65

I browsed the target again using the double-encoded payload. To my surprise, an XSS popped up! I almost cried tears of joy, LOL.

To document the entire process, I recorded a video using Burpsuite to capture how the XSS popped up

After that, my next action is to create a proper report to be submitted to the Google security team.

But then, I noticed that something wasn’t right! Sometimes the XSS payload wasn’t working. I was very paranoid that this might affect my report. Nevertheless, I created and submitted the report anyway.

After waiting for hours for the Google security team’s response, they emailed me back, and my fear that something was not right became a reality. The XSS was not working on their end. They couldn’t reproduce the vulnerability that I had found.

Bug Hunting Tip #3: If a vulnerability was found, try to dig much deeper into the findings.

Now it’s time to check what’s really happening. I found out that the vulnerability triggers sometimes after 2 or 3 attempts. What I did was I created a bash script using curl that requests the vulnerable URL with the payload 5 times and sees how many responses reflect the XSS payload.

A simple curl request command that outputs the response.

Out of 5 responses from curl requests, 3 responses contain the payload. This indicates that the vulnerability triggers 3 times out of 5 requests.

Reflected payload

Here’s the Bash script that i have coded.

But wait! There’s more! I thought I was ready to send my update to the Google security team, but then I discovered there are additional instances of the XSS vulnerability that need to be addressed.

Upon further investigation, I discovered that all URLs from aihub.cloud.google.com triggers XSS vulnerability when the ‘q’ parameter is appended. By inserting “&q=” along with the double-encoded payload, the XSS exploit can still be triggered.

To verify this, I re-crawled the aihub URLs and saved them in a text file named ‘valid_aihub_urls.txt’.

I then made modifications to my bash script to iterate through every URL in ‘valid_aihub_urls.txt’, sending curl requests 5 times to each URL to check if the XSS is triggered.

Here’s the modified bash script:

To run the script, I just need to type:

./google_poc_search_another_q.sh valid_aihub_urls.txt

Guess what? Every valid URL from the text file triggers the XSS.

I even attempted to query a non-existing directory and appended the ‘q’ parameter, yet it still triggers the XSS vulnerability.

Upon discovering this vulnerability, I knew immediate action was necessary. I followed responsible disclosure practices and promptly reported my findings to Google’s security team again. The process involved detailed documentation of the vulnerability, its potential impact, and steps to reproduce it. I also included the bash scripts that I had created.

Finally! Triaged!

Google’s security team responded swiftly and professionally. They acknowledged the issue, verified its authenticity, changed the priority level from P2 to P1, changed the severity level from S4 to S1, and then gave me a “Nice Catch!” email response.

After a couple of days, Google security team rewarded me for submitting this report.

The Google security team decided to reward me a total of $4,133.70. In addition to the $3,133.70 reward, they also gave me a bonus of $1,000.

After receiving the reward

Bug Hunting Tip #4: Submit a comprehensive report whenever possible. Be creative! Invest effort in crafting Proof of Concept scripts to substantiate your findings, as this might lead to a bonus reward.

On March 15, 2024, the Google security team updated me, stating that the vulnerability had been fixed. The sub-domain was secured, and users were protected from potential exploitation. However, I informed them that the website was now returning a 502 error.

They responded that the aihub was deprecated and was migrated to Vertex AI since January, 2024.

The implications of this vulnerability were profound. As part of Google’s domain, this sub-domain was trusted by users worldwide. Any vulnerability within such a domain could have far-reaching consequences.

My encounter with this XSS vulnerability on Google’s sub-domain was a wake-up call. It highlighted the ever-present need for robust cybersecurity measures, even within the infrastructures of tech giants. The impact of such vulnerabilities extends far beyond the realm of individual users, reaching into the core of our digital infrastructure.

As users, developers, and security enthusiasts, we must remain vigilant. Whether it’s through responsible disclosure, proactive security measures, or simply staying informed, we all play a role in safeguarding the digital ecosystem. My hope is that by sharing this experience, we can raise awareness about the importance of cybersecurity and inspire a collective effort towards a safer online world.

Google Hall of Fame Rank: 507 (As of March 3, 2024)

I want to extend my gratitude to Google’s security team for their prompt and professional response to this vulnerability. Their commitment to security and swift action are commendable, ensuring that users remain protected in an ever-evolving digital landscape.

Support: If you like to support me, buy me a Beer! 🍺

Follow me: Henry N. Caga | Twitter

Read Entire Article