Don't Be a Googledork
Google's inquisitive spider turns up more than just the payroll spreadsheets and sensitive documents the mainstream press likes to report on.
There's a hacker tool out there sniffing around your network. It's checked out your severs and the software they're running, compiled lists of usernames and email addresses to launch client side attacks, and may even have discovered unsecured web interfaces to your corporate routers. It's probably even found the odd root password or two. The hacker tool's name is Google
This giant search engine indexes the web very aggressively and often finds pages that no-one is meant to see. It will reveal what it finds to anyone armed with the right search terms. As far as hackers are concerned it's ideal: since Google does all the dirty work there's no direct contact between the hacker and the machines being checked out. The only fingerprints to be found belong to Google. It's a good bet that almost all concerted hacking attacks start with the hackers sniffing around doing reconnaissance via Google to find out as much as they can before they formulate their plan of attack.
How effective is Google hacking? Well, here's an example. Red hat Linux has an unattended installation option, using a file called a Kickstart configuration file containing all the answers to questions that need to be answered during installation. Once the Kickstart installation is complete, the configuration file is often left on the machine as an oversight.
Don't believe me? Try this search in Google:
Have a look at the results you get. You'll find plenty of Kickstart files, which will look like this real example. (Some of the details have been changed to protect the organization concerned)
# Kickstart file automatically generated by anaconda. nfs --server linux.xxxx.com --dir /export/linux/901/i386 install lang en_US.UTF-8 langsupport --default en_US.UTF-8 en_US.UTF-8 keyboard us mouse none skipx network --device eth0 --bootproto static --ip xxx.xxx.xxx.xxx --netmask 255.255.255.0 \ --gateway xxx.xxx.xxx.xxx --nameserver xxx.xxx.xxx.xxx --hostname linux1.xxx.com rootpw --iscrypted $1$X0GpXMcA$J56^24filetype25^/E2nIwXtYHNPw7 firewall --disabled
The last few lines are very nice. A root user's hashed password and several potentially useful IP addresses. Not bad for a couple of milliseconds' worth of work retrieving it from Google's cache!
Whoever was responsible for this server was a "googledork" – someone who let sensitive information under his control leak out onto Google, thus revealing himself to be – how to put this nicely? – less than perfect.
Want a Frontpage password? Here's a more dramatic illustration of people being Googledorks. Try popping this search into Google:
ext:pwd inurl:(service | authors | administrators | users) "# -FrontPage-"
What you'll see is page after page of entries like this:
# -FrontPage- webadmin:DnbRlEhLhcfAY billr:^38usernames39^8C4FST
User names and passwords on a plate!
Most sensible webmasters make backups of their MySQL databases, but these shouldn't be available for the world to see. But amazingly, they often are. To find them, plus usernames, passwords, and all kinds of useful information that could make a penetration attempt successful, try Googling this:
mysql dump filetype:sql
It's a good bet that the admins responsible for these dumps have no idea that they're Googledorks, and have published their MySQL dumps on the Web.
So how do you avoid being a Googledork? The answer is to realize that Google is your friend. The search engine may reveal your misconfigurations and security breaches to the world, but it will also reveal them to you. In other words, it can be used to check if there's anything a search would reveal which you wouldn't want out on the web. Remember, Google's cache is fairly persistent, so if you find you've left a Kickstart configuration file on a server then you'll need to change passwords and other sensitive information as well as removing the offending file: even if no-one has picked up on your mistake yet, the cache ensures that the Kickstart file will remain available even after you have removed it.
Aside from searching for files that have been unwittingly made available on the web, Google can be used by hackers for many other purposes. When a new SQL injection vulnerability is discovered in a particular web application or version of an application, hackers will often carry out a "powered by" search to identify hundreds of thousands of potential victims running that application. So don’t imagine you are in anyway safe because hackers won't know what software you're running.
The concept of Google hacking was brought to many people's attention by Johnny Long, also known as Johnny Hacks, a few years back, and he maintains a great security/hacking site at ihackstuff.com. In particular, check out his Google Hacking database at johnny.ihackstuff.com/ghdb.php. This is a repository or interesting searches which may reveal all kinds of information about your systems. As a basic security measure it's a good idea to run some of these searches and if necessary take the appropriate steps to rectify the situation. After all, you wouldn't want the whole world to see that your organization's network is run by a Googledork, now, would you?