Google Hacking .IE

Considering this week the Irish government have been pushing is “Make IT Secure” (I wonder how much and how long that took to come up with), I decided to put out something on one of my interests, Google Hacking (g.H.). Google hacking is simply the construction of a search to find information that is available to the public that really should not be, or that provides information about software products running on sites that may pose a security threat to the integrity of the site. It is not limited to the use of the Google search engine as almost any major search engine can be used to find this content. It is legal to run such queries so long as you do not posses the intention to use that information in the furtherance of a crime, however it may be against the site owners terms of service to access such information. It is against all major search engine vendor terms of service to automate such searches. It is also quite stupid to leave this information available to the public.

Google hacking has always interested me from a system administration and security aspect. Over the years I have seen some very silly things done on the web by web developers & sys admins . Usually it is not because they do not know better, but because their client puts a pressure or restraint upon them that causes them to do something they would not normally do. As a result, things get missed and eventually forgotten until a search robot comes and indexes everything. In short, everyone is human and as such mistakes happen (I include myself here).

One of the biggest security risks to most sites is the humble script kiddie. A script kiddie is a person whom does not know such much about security but scours the web for scripts and tools written by someone else Recently the cDc (of BackOrifice fame) released a new product that automates the process of gH. The cDc provides, rightly or wrongly, such applications to expose security weaknesses. Like most tools, they can be used for good or bad purposes. In this case however, I can already foresee Google noticing an increase in searches since the tool was release and many site admins scratching their head this coming Monday as they realize that their databases have been droped or their home page replaced.

Given my interest in gH, I regularly perform such queries against my own sites or those of my clients to ensure nothing has been put where it should not have been. Knowing the cDc had plans in this direction, I began to expand my searches to include sites in the .ie domain (only taking the first page of results) to begin to formulate a picture of the most common issues. Over the course of 6 months I have begun to compile a list of the sites discovered and the issues. The top ten issues that keep coming up within the .ie zone are;

1. Storing SQL dumps within the web root
2. Unprotected PHPMyAdmin installs
3. Password lists in excel files within the web root
4. Configuration files for applications or includes with site admin or db user and password information
5. Publishing software you are licenced for at a “secret” location such as tmp…
6. Web stats with username information and url information
7. Old software installs know to have security issues
8. Way too descriptive error messages on production sites
9. Confidential or Private documents published to the web root
10. Insecure and default installs of server software

Now, thats great, but who would do such things? I hear you ask. Well every sector of Irish industry is affected here. I am not naming names (actually I may purge my DB after I publish this), but they do include government bodies, financial institutions, broadcast organisations, hosting companies, web development firms, colleges, private companies, charities and private individuals. The good news is they are quite quick to remove such content, the bad news is, that there is still some dire lapses when it comes to personal data or security issues being made quite available to the public at large, generally from what I can see, to make someones life a little easier when they are working remote.

There are a number of things we can all do however to prevent this.

1. Customers should listen to their developers and/or their sys admin/security teams when an application is being built for them
2. Security should be the first consideration, not the last or not at all.
3. Password protect temporary directories or workarounds at the very minimum.
4. Subscribe to the vendors mail list for your product and update when security fixes are announced.
5. Don’t let Mary or Jim take care of the company website without proper training in both its use and data privacy practice
6. Marketing jocks, stop publishing our private data to send to the printers etc without proper security
7. Developers, suppress error messages that are too descriptive on public production sites and stop putting your current work to test for the customer on a public site with no security (Source files are very common)
8. Use a firewall or Iptables at the very least
9. Hosters, consider up selling your customers training on security practices, it does no one any good to have data leaked or sites defaced
10. Be aware as mush as possible, search your own sites or hire a security company to audit on a regular basis.

The above is not exhaustive or indeed prioritized, but it should give you an indication of where to start.

The is one other thing we all can do however. There is no commercial value to this data being retained within an index by the major search engines. In fact it may cost them in the long run, just dealing with the remove requests. Therefore, seeing as you already filter some of these queries, why not consider removing such data from your indexes? Sure they are not responsible for what is out there, but I do think it is a positive proactive measure they can make that is a quick win for all involved. This still does not negate the fact, that all of us as site owners are still responsible for what is available to the public.