Protecting exposed servers from Google hacks (and Google 'dorks')

Suppose a hacker wanted to harvest bank account data from customers of the hypothetical ACME Bank. A phishing email consists of an HTTP link preceded with text that goes something like this:

We would like to inform you that we are currently carrying out scheduled maintenance. In order to guarantee the high level of security to our business customers, we require you to complete ACME Bank's Commercial Online Form.

(Obviously the step that many phishers overlook is a quick copy edit to correct the grammar and spelling of the message, so the above message was sent as written).

Before sending the message, a phisher needs to build an "ACME Bank Commercial Online Form" and a database, hosted somewhere on the Internet, that can process and store the form input. False or misleading email header information, including the use of a deceptive subject line, has been illegal in the U.S. since 2003, thanks to the CAN-SPAM Act. Therefore, attackers don't want to host a phishing database on their own server or indeed any server that can be traced back to them.

Enter the "Google dork," a term originally coined to describe a person foolish enough to leave a server exposed in ways that are easily discoverable through a search engine. The term has evolved and is now shorthand for any number of search strings that find vulnerable hosts, such as: "Welcome to phpMyAdmin" AND "Create new database".

These queries find servers on which the commands needed to create a new database with phpMyAdmin -- a tool written in PHP to handle the administration of MySQL over the Web -- may not be adequately protected. In other words, potential hosts for a phishing database. After all, if the server is so loosely configured as to allow a database to be created on it, there's a good chance that the server can be used for a phishing campaign without being detected.

After setting up a database, all that remains is to send out the message in a large email blast and hope that some of the recipients bank at ACME Bank and fall for the ploy. Customers may enter confidential information into the database and the hacker can then retrieve it from the server, ready to sell the data or leverage it for his or her own ends.

There are hundreds of Google dorks, and they are actively traded on underground sites. So how can an enterprise defend against them? For starters, don't run or allow users to run MySQL on Web-facing servers without proper training. Search the Google Dork cited earlier, and you will find a handful of sites that actually warn the user:

"Your configuration file contains settings (root with no password) that correspond to the default MySQL privileged account. Your MySQL server is running with this default, is open to intrusion, and you really should fix this security hole." (Obviously this warning is itself a Google dork.)

Second, review the configuration of the organization's Web-accessible databases to make sure that they are password-protected and stored in restricted access directories. Third, shield sensitive context from search engine crawlers by using robots.txt, an exclusion standard that prevents Web robots from accessing parts of a website that would otherwise be viewable by the public. For example:

https://myserver.com/robots.txt:
User-agent: *
Disallow: /

Bear in mind that if HTTP and HTTPS share the same root directory, a script will be needed to serve up the proper robots.txt file, depending on whether HTTP or HTTPS is used. It's also possible to conditionally add the robots meta tag into pages served by the HTTPS server:

But bear in mind that malicious crawlers need not respect this tag.

Fourthly, but probably not finally, be aware that help is on the way. In fact, Google is now reacting to some Google Dork searches with this message:

See larger image

Have more security questions? Send them to any of our five infosec experts.

Listen to Michael Cobb's Google hack advice on your PC or MP3 player.