Harden Your Server against Google Hackers

By Corey Nachreiner, Network Security Analyst, WatchGuard Technologies

Sometimes the most innocuous looking tools present the most serious dangers. Take a hammer, for instance. Ever since the days of the caveman, if something needed banging, we'd grab the closest hammer -- the perfect tool for the job.

Yet, beneath that useful and seemingly-innocent exterior lies a killer in waiting. CSI viewers know that murderers often use hammers as weapons of opportunity. Almost every detective show on TV has used a hammer not for its intended constructive use, but for its unintended destructive potential -- "blunt trauma" to the head.

After reading Google Hacking for Penetration Testers, by Johnny Long, I've realized that Google's search engine is the Internet's hammer. Google provides one of the most useful tools on the Internet. Furthermore, at first glance Google's search engine offers little threat, with its rainbow-colored logo and child-simple interface. Yet behind its unassuming exterior lies great power. You can use it for good or for blunt trauma.

Using examples directly from Long's book, this article describes a few Google hacking techniques attackers can exploit to harvest sensitive information from your Web site. More importantly, the article details how you, the administrator, can protect yourself from such techniques by configuring your Web site securely. In short, you'll learn how to put a hard hat on your Web server so that the Google hackers can't hammer it senseless.

What is "Google hacking"?

Google hacking is the art of crafting creative Google search strings to uncover sensitive information publicly available on the Internet. For example, if some Web administrator unknowingly leaves his Apache Web server password file (htpasswd) in an open directory on his Web server, a Google hacker can derive a Google search to find it.

Based on the term "Google hacking," some assume that the fine folks at Google bear responsibility for this misuse of their search engine. But all fault for Google Hacking falls squarely into the laps of Googledorks. Johnny's Web page defines a Googledork as, "An inept or foolish person as revealed by Google." More specifically, it's a person (usually a Web administrator) who mistakenly leaves or posts sensitive information on a Web site for Google's site scrubbing robots to find, and thereby, discloses private data to the Google hackers of the world. If you leave private data lying around in public, you shouldn't be surprised when someone finds it and reads it.

The good news is: by exploring a few of the most common Google hacks that prey on badly configured Web sites, you can avoid turning into a Googledork.

Open Web directories mean open house for Google hackers

In its most basic sense, your Web site consists of shared files full of HTML and HTML-related documents. When a Web client visits this shared file system, it interprets the HTML documents that it recognizes and displays them as Web pages. On the other hand, if a Web client encounters a non-HTML document on your Web site, it allows the visitor to download that file instead.

Sometimes Web administrators mistakenly allow clients to access directories on their Web sites that do not contain a default Web page (an HTML file typically called index.html or default.htm). Such directories are known as open directories. When a Web client reaches an open directory, it displays an output of all the files in the directory for anyone to view, and in many cases, download. HTML was purposely set up this way, so that if a URL does not specify a file, the person clicking on the URL can select which file he or she wants to view or download.

Novice Web administrators commonly expose such open directories to the public. Worse yet, some even leave sensitive information such as password files, source code, or even customer information (Social Security and credit card numbers) in open directories. This mistake allows Google hackers to locate and download these sensitive files to their heart's content, because Google's content-searching robots index everything they find in open directories.

Avoid this mistake by "closing" any open directories on your Web server. You can accomplish this in two easy ways.

First, make sure to place a default HTML file in every public directory on your Web server. Even if the particular directory doesn't have a Web page associated with it, add a placeholder default HTML file just to make sure Web clients can't view the contents of that directory.

Second, some Web servers, such as Apache, allow you to disable open directories to make sure Web clients can't reach them (see Reference section). Unless you have a truly compelling reason to use open directories, disable them so that Google's site scouring robots won't cache their contents.

Default Web content divulges default vulnerabilities

Most Web servers, by default, install a lot of Web content on your computer to get you started developing your own Web pages. These default files include sample HTML pages, Help pages, and sometimes even example code for Web apps. Unfortunately, this default content, if left installed, can also help a Google hacker to ID and attack your Web server.

If a Google hacker downloads some new, zero-day exploit code for an IIS 5.0 server, he'll want to find a bunch of targets to try his new attack against. Johnny's book provides Google hackers many techniques for finding specific Web servers. Many of these techniques hinge on locating some of the default Web content these servers install. If you have a default file on your server that only comes with Apache 2.0, a Google hacker will find it and know exactly what kind of Web server you run. You've just helped him focus his attack more efficiently.

Furthermore, sometimes these default Web files contain vulnerabilities themselves. For instance, some of the HTML help files that shipped with past IIS servers contained Cross-Site Scripting (XSS) flaws that allowed attackers to trick users into executing malicious scripts under the guise of your site.

Whether used to identify your Web server, or located to exploit directly, these default Web files have no place on any public Web server. Remove them before serving your site to the public.

Keep private business private

Hopefully, you consider this next tip simple common sense. Nonetheless, Johnny's Google hacking results have proven that not all Web administrators apply common sense, so I'll go ahead and say it: Don't put any files on your Web server that you wouldn't want an absolute stranger seeing.

In fact, this tip applies to more than just your Web server's public folders. Some older Web servers suffer from directory traversal vulnerabilities that allow attackers to escape your Web server's public directory and download files from other, non-Web directories as well. Unless you use some sort of authentication and encryption on your Web server, don't place any sensitive files on your Web server at all. If they are there, Google hackers will come.

Of hammers and hardhats

It seems as though every day we hear of companies leaking tons of sensitive customer data to attackers on the Internet. Although most of them never explain how the leaks occurred, I'd guess at least some involved basic Google Hacking.

In fact, I recently attended a local computer security gathering that presented a Google Hacking competition to show system administrators the dangerous outcome of Google hacking. The results of the competition staggered most in the room. In less than an hour, the competitors found millions of pieces of sensitive information, including lists of credit card numbers and their corresponding Credit Card Verification (CCV) numbers.

Results like this should convince even the most lax Web administrators to tighten up their Web servers. If you haven't already placed a hardhat on your Web server, apply the tips above to be sure that Google hackers can't hammer it senseless. And if the topic piques your interest, I recommend reading Johnny's book.