The Dark Side of Google

In the past months we were talking about Google Hacking as an effective tool for attack automation, attack targeting and attack proxying. Last week, while I was investigating an attack vector, I "bumped" into another real life example of Google's darker side.
The attack vector I was investigating was an SQLi attack on a specific PHP module. The fact that the attack vector was executed on a non PHP web application indicated that I am probably looking at some kind of automated attack and that it might be worthwhile to further investigate. Looking-up the targeted resource verified that it is part of an open source PHP ecommerce project and that a past version of this resource was found vulnerable to SQLi. Nothing interesting up to that point, but I asked myself why was the attack executed on a non PHP web application? My next step was to look-up this specific attack vector in Google search. Bingo! The search results were very interesting...






I was able to distinguish between two types of search results:

   1. Results that included the attack vector as part of the link (first example)
   2. Results that included the attack vector as part of the indexed content (second example)

Let's see what all this tells us...
The search results page actually tells the whole attack story. As a first step, the attackers cause Google to index web pages embedded with links that are actually SQLi attack vectors. This can be achieved by using various methods, for example:

   1. Embedding malicious links in a controlled domain and then asking Google to crawl
   2. Embedding malicious links in forums, blogs or any other content sharing platform

These pages are the ones to be expressed as the second type of search results I mentioned above.
Next, Google crawls the pages in which the malicious links were embedded and follows them. Since the links are actually attack vectors, this action is translated into an SQLi attack executed by the Google against the target web applications. When Google receives a response to the attack it indexes the data under the target application's domain name. This is illustrated by the first example of search results where the link (in green) is obviously an SQLi attack vector and the meta description is an SQL server error response. As the final step of the attack, the attacker extracts the results of the SQLi attack by sending specially crafted search queries to Google.
What is really disturbing in this attack scenario is that attackers can both execute an attack and get the results back without issuing a single request to the target application - Google does all of this for them. A lot has already been said regarding the gap between what Google should and can do and what Google actually does to prevent such issues. A new research conducted by the ADC shows that this is only the tip of the iceberg and it is definitely not the only or the major security issue associated with Google services. In fact, expect more on this topic in one of the coming security conferences where we take this to the next level by revealing a Google service that enables even more advanced attack techniques.

- Eldad

on the other hand, the evidence where the attack came from is in the google cache.  not that it's hard to set up an anonymous blog and have that indexed I guess.