Exactly how is easy is Google hacking, how can you protect yourself from it and is it really that much of an issue anyway?

I tried my hand at Google hacking recently.

It was easy, and all done with, well, Google. As Google hackers know, what I did was to use Google to look for information residing in other people's Web-connected servers -- and machines connected to those servers. Stuff that I'm not supposed to see.

So how did I fare?

Well, I didn't manage to get my hands on Web sites belonging to any noteworthy organisations, companies or people. But what I did manage to uncover were a few dozen SQL server configuration files from a motley bunch of organisations. And all this in one afternoon's work.

The subject of Google hacking -- the use of Google as a hacking tool -- fuelled several prominent news headlines recently. Among them are: The perils of googling, by Scott Granneman of The Register; Robert Lemos's Google a favorite among hackers too from CNET News.com; and Dan Ilett's Hackers use Google to access photocopiers from ZDNet UK.

Want to read more related-articles? Type "Google hacking" into Google and you'll find no end of them.

These stories piqued my interest. As a novice Google hacker (trying my hand only in the name of research, obviously), I started by getting some juicy information from a Web site its owners called Johnny I Hack Stuff. There, one can find a whole stash of search phrases specially written to tease Google into spilling the beans on its subjects. As I found out, one can also easily modify these phrases for better results.

Try it. Type the phrase "access denied for user" and "using password" into Google. I did, and found 103,000 returned Webpages, some volunteering their SQL error messages. And among these were Websites that gave such harmless information as user IDs, SQL server stats and configuration details.

Google-risks?
How much harm can befall you if you are visited by Google hacks?

It will depend on what information you've carelessly exposed -- and what information was trawled. Using Google, hackers have been known to spy on photocopiers, discover passwords, monitor server activities and more.

I called on my expert security source, Gerry Chng, who manages Ernst and Young's technology and risk services.

"If I am a system administrator, how worried should I be?" I asked Gerry.

For someone who's seen far more nefarious hacking methods as a network penetration testing expert, Gerry was calm. "Google hacking is definitely one of the starting points a hacker would attempt to find information, but it is really nothing more than that," he assured me.

Furthermore, said Gerry, passwords and log files are generally only exposed under two scenarios -- both of which can be avoided with some care.

The first instance is when one links sensitive documents with URLs, or annotates documents with HTML tags. "Web spiders will only crawl to places where it sees a link," said Gerry. But watch out, however, for the not-so-obvious Web-linkages. For instance, Gerry has seen developers commenting out test code using the <! -- and -- > HTML tags. "Once a bot sees this link, it will try crawling into those areas," he warned.

The second instance where sensitive data exposure can happen is when application errors occur during a spider visit. In the case of SQL-driven web applications, one may see SQL error messages as a result. Even transient errors can mean exposure. He said: "If you visit this site later, the error message may be gone, but Google caches the results it sees."

Which means hackers interested in say, SQL injection attacks, can use Google hacking techniques to identify Web sites that are vulnerable because they had error messages cached.

In fact, network admins should probably worry more about having error messages cached by search engines than Web-linked files because the transient, auto-generated and error messages are likely to be unforeseen and can stay in Google's reach for a long time. You can however email Google to remove the links.

Search-proof?
So what can one do to foil Google hacks? Again, I turned to Gerry, who obliged with the following tips:

• Make sure your applications do not generate unhandled error messages. "Having custom error message-handling replies lowers the chance for a generic search," he said. Apply the concept of "don't be a low-hanging fruit."
• Make sure your directory listing is disabled for all folders. And avoid storing lists of URLs in a folder, where a spider can crawl to.
• Links to administrative pages should never be placed in a link on a web page. This only encourages the spider to crawl there, and subsequently cache it.

Another tip: organisations should instil proper change controls when it comes to code changing. "I have seen developers commenting out previous codes which could still link to certain directories, or containing information about the changes made," said Gerry. Scary.

So there you have it.

But unfortunately -- or fortunately, for some of us -- Google doesn't stay still. Last month, Google launched its first desktop search engine. So it may not be too long before the perils of online search engine hacking moves into intranets and internal networks.

And don't forget also that there are other search engines that offers search-features that are different -- in some cases better -- than Google.

Network admins: you've been warned.

Copyright © 1995-2009 CBS Interactive Limited. All rights reserved
ZDNET is a registered service mark of CBS Interactive Limited. ZDNET Logo is a service mark of CBS Interactive Limited.