Page 1 of 3 123 LastLast
Results 1 to 10 of 27

Thread: Google as a Hacking Tool

  1. #1
    Join Date
    May 2004

    Post Google as a Hacking Tool

    This tutorial is an introduction to the security risks associated with common internet search engines. In the past few years, Google has come to be the most popular search engine in the world, so much so that many consider it the only one worth using. For this reason this tutorial will focus on Google, however it can be safely assumed that most of what is said here applies to other similar engines as well.


    A system is vulnerable when an attacker is able to make it do something it's not supposed to. There are generally two types of vulnerabilities to be found on the web: software vulnerabilities and user misconfigurations.

    Although there are some sophisticated attackers who target a specific system and try to discover vulnerabilities which will allow them access, the vast majority of attackers start out with a specific software vulnerability or common user misconfiguration which they already know how to exploit, and simply try to find - or scan for - systems which have this vulnerability. Google is of limited use to the first attacker, but invaluable to the second, as will be explained in the next section.


    When an attacker knows the sort of vulnerability they want to exploit but have no specific target, they employ a scanner. This is a program which automates the process of examining a massive quantity of systems for a security flaw. The earliest computer related scanner, for example, was a wardialer; a program which would dial long lists of phone numbers and record which ones responded with a modem handshake.

    Today there are scanners which automatically query IP addresses to see what ports they have open, determine what operating system they're probably running, some even determine the geographic location of the system. One of the most popular IP scanners is NMap ( ). When using NMap, one specifies a range of hosts and the specific services on each one to scan for. The program will then return a list of the available (and presumably vulnerable) systems.


    With a little creativity, Google can be made to operate in a similar way as NMap, though they use different protocols. As an example, let's pretend that we know a great new exploit that will allow us to steal credit card information from any online store that uses the SHOP.PL scripts. We know that uses SHOP.PL, but when we try our exploit it turns out that they already patched the vulnerability. As dedicated malicious hackers, though, we don't give up. We turn to Google and enter the following search string:

    Feel free to try this - it's not illegal and shouldn't get you in to trouble. Note that the above search employs advanced operators, which are described here: ( ). What is produced is a list of all sites which have "" somewhere in their URL, essentially a list of potentially vulnerable targets. Just as with NMap, all that's left to do is try our exploit against each site on the list.

    There are countless variations on this scheme, including some rather clever ways to find particular versions of server programs. For example, if one was to enter:

    "seeing this instead" intitle:"test page for apache"

    It would return a list of sites using Apache 1.3.11 - 1.3.26, because those specific phrases are used on the default page for those versions. Once again, if an attacker had an exploit for Apache 1.3.11 - 1.3.26, it would take very little effort to compromise a large number of systems.


    It seems ridiculous, but sometimes administrators misconfigure their sites so badly, it's not even neccessary to use a "third party" exploit in order to gain access to a system. Google indexes the web very aggressively, and unless a file is put behind in a password or otherwise access-restricted area of your website, there is a good chance that it will be searchable in Google. This includes password files, credit reports, medical records, etc.

    In cases where the files are not adequately protected from Google, the search engine has basically already performed the exploit for the attacker. If, for example, a script kiddie wanted to deface a random web site, he or she would simply search for:

    intitle:"Index of" htpasswd

    Which would return a list of all poor users who allowed Google to index their .htpasswd file, probably containing the administrative username and password for their web page. All the attacker would need to do is open the file, crack the password, and deface away.


    A proxy is an intermediary system which an attacker can use to disguise his or her identity. For example, if I was to gain remote access to Bill Gates' computer and cause it to run attacks on, it would appear to the Feds that Bill Gates was hacking them. His computer would be acting as a proxy. Google can be used in a similar way, as is explained here.

    Even if Google didn't provide such an easy way to locate vulnerabilities, there are other tools which can do that particular job. A program called AccessDiver ( ) allows the user to specify a domain name, and it tries to access URLs which commonly lead to sensitive data or system access. This tool was, however, intended for use by administrators on their own networks. If anyone tried to use this tool against, the system would deny them access, log their IP, and send them to jail for attempted computer trespass.

    When using Google, there is very little danger of detection, because the attackers computer doesn't have to access every site itself and ask suspicious questions like "Do you have a page containing .htpasswd?" The search engine has already gathered this information and will give it freely without a peep to the vulnerable site. Things get even more interesting when you consider the Google cache function. If you have never used this feature, try this:

    Do a Google search for "USA Today". Click on the first result and read a few of the headlines. Now click back to return to your search. This time, click the "Cached" link to the right of the URL of the page you just visited. Notice anything weird? You're probably looking at the headlines from yesterday or the day before. Why, you ask? It's because whenever Google indexes a page, it saves a copy of the entire thing to its server. You are accessing the most recent copy Google made of

    This can be used for a lot more than reading old newspapers. Our attacker can now use Google to scan for sensitive files without alerting potential targets, and even when a target is found the attacker can access it's files from the Google cache without ever making contact with the target's server. The only server with any logs of the attack would be Google's, and it's unlikely they will realize an attack has taken place.

    An even more elaborate trick involves crafting a special URL that would not normally be indexed by Google, perhaps one involving a buffer overflow or SQL injection (common web exploits). This URL is then submitted to Google as a new web page at ( ). Google automatically accesses it, stores the resulting data in it's searchable cache, and the rest is history.


    This probably doesn't even have to be mentioned at this point, but make sure you are comfortable with sharing everything in your public web folder with the whole world, because Google will share it, whether you like it or not.
    Also, in order to prevent attackers from easily figuring out what server software you are running, change the default error messages and other identifiers. Often, when a "404 Not Found" error is detected, servers will return a page like this:

    Not Found
    The requested URL /cgi-bin/xxxxxx was not found on this server.

    Apache/1.3.27 Server at Port 80
    The only information that the legimitate user really needs is on the top line, and restricting the other information will prevent your page from turning up in an attacker's search for a specific flavour of server.

    The Google cache issue raises another interesting security concern: just because you take a document off your site doesn't mean it's inaccessible. Google periodically purges it's cache, but until then your sensitive files are still being happily offered to the public. If you realize that the search engine has cached files which you want to be unavailable, go to ( ) and follow the instructions to remove your page, or parts of your page, from their database.

    There is not really anything that an administrator can do to prevent the use of Google as a proxy, so the best thing to do is ensure that your system is not vulnerable to any HTTP attacks that could be conducted through Google. A good HTTP vulnerability scanning tool is N-Stealth ( ). Run this against your network, and it will hopefully point out any holes that you need to patch up.


    There are many, many variations on the Google hacking techniques described here. An excellent place to find out more about these exploits is ( ). ( ) Also contains a pretty good tutorial specifically focusing on how to find sensitive information using Google.

    Hope this information is useful!

  2. #2
    Senior Member
    Join Date
    Apr 2002
    The subject is pretty well known, now, but your presentation is not bad at all. That's what a tutorial must be: clear and easy to read.
    Life is boring. Play NetHack... --more--

  3. #3
    As Kiss said the information is has been well known for a while. The presentation was so-so, no offense, but I have seen much better. Thanks for the reminder though.


  4. #4
    Join Date
    May 2004
    Yeah, I was sort of surprised when I couldn't find any pre-existing tutorials about this, which is why I wrote it.
    I guess I didn't search hard enough though. Oh well, sorry if it's redundant.
    Maybe it will be of use to some of the less experienced folks here (sort of the target audience anyway).

  5. #5
    T3h Ch3F
    Join Date
    Sep 2001


    I'd have to say A for effort though. Thanks for sharing. 3rr0r.
    Get some good religion from Bad Religion.

  6. #6
    Senior Member Raion's Avatar
    Join Date
    Dec 2003
    New York, New York
    Wow gotta hand it to you there 3rr0r 7 posts and already 5 dots congrats..

  7. #7
    Senior Member
    Join Date
    Apr 2004
    Nice post 3rr0r, very well written and formatted. It reiterates some very good information that I have not seen posted here before.

  8. #8
    Senior Member
    Join Date
    May 2004
    Indeed informaitive post ...
    It may be known to seniors, and an old issue, but it really does help us ..Newbies
    Hats off!
    2 tutorials witten within first 10 posts.. Both highly impresssive.. & a collection of greenies...
    I'm envious :P
    please don\'t visit

  9. #9
    Senior Member
    Join Date
    Jun 2003
    i am probably too far fresh member but only a few post and heaps of greens would put you in upper bracket if is not a site record i do enjoy reading clear and interesting read and for as newbies very informative read. your last tutorial was great so keep a good work site need people like you its enough negative things around as you can notice in some posts.

  10. #10
    Just a Virtualized Geek MrLinus's Avatar
    Join Date
    Sep 2001
    Redondo Beach, CA
    Hrmm.. I had split out a post by a user (along with a few others) in hopes of returning the status of this thread to what the APs should be. Interestingly didn't work (I'll have mnstgrl look into that). For those that had commented and no longer see your post here please do not take offense. The post(s) in question were removed to the "Thread Graveyard". Do not take this as your post necessarily being a bad post or questionable. If you have questions, do not hesitate to contact me.
    Goodbye, Mittens (1992-2008). My pillow will be cold without your purring beside my head
    Extra! Extra! Get your FREE copy of Insight Newsletter||MsMittens' HomePage

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts