Google Your Site For Security Vulnerabilities

by Nitesh Dhanjani
10/07/2004

If Google stumbles across data that may expose sensitive information about your organization, Google will not hesitate to index it. The search engine does not discriminate against data it indexes. How can you tell if your secrets have gone public? You can use Google to your advantage with some specific search queries. The inspiration for the examples presented in this article come from Johnny Long. This article will also show you how to use the Google API to automate the process of searching Google for vulnerabilities.

Default Resources

Web servers often install default web pages. These default web pages do not indicate a vulnerability, but their presence can identify a default web server configuration. Attackers know that such default pages often indicate an un-hardened web server: if an administrator has not put in the effort to remove the default welcome page, it is quite probable that he hasn't blocked unused services or added any patches. The following Google query finds default Apache installations:

intitle:"Test Page for Apache"

Directory Listings

Web servers often serve directory listings when a default file such as index.html is not present in the directory. Sometimes, people store sensitive information in such directories. Consider the simple query:

intitle:"Index of" admin

The above query will return URLs that contain directory listings of /admin. Most often, administrators create directories called admin to store sensitive information. Here are more queries that take advantage of directory listings:

intitle:"Index of" .htpasswd

intitle:"Index of" stats.html

intitle:"Index of" backup

intitle:"Index of" etc

intitle:"Index of" finance.xls

Error Messages

Related Reading Google Hacks 100 Industrial-Strength Tips & Tricks By Tara Calishain, Rael Dornfest

Error messages from web servers and applications can give away a lot of details. Consider the following Google query that indicates a MySQL error.

supplied argument is not a valid MySQL result resource

Other queries that may reveal interesting information include:

"A syntax error has occurred" filetype:ihtml

"ORA-00921: unexpected end of SQL command"

Remote Services

It is possible to find VNC and Terminal Services servers via the following queries. Many administrators rely on external users not being able to find the URL to access information about such remote services.

"VNC Desktop" inurl:5800

intitle:"Terminal Services Web Connection"

Google can also find administrative applications that allow users to configure systems remotely. For example, here is how to locate phpMyAdmin installations:

"phpMyAdmin" "running on" inurl:"main.php"

Vulnerability Reports

The Nessus framework works nicely to identify network vulnerabilities. This tool can create a HTML report of found vulnerabilities. Often, such reports live under the web root directory, causing web servers to serve them to external users. A Nessus report may contain details about vulnerabilities present in an organization's network. Here is a query that will use Google to find such reports:

"This file was generated by Nessus"

"Host Vulnerability Summary Report"

google_vulns.php

The example queries presented in the previous sections are only a small subset of known queries that can find vulnerabilities using the Google search engine. The google_vulns.php script presented in this section uses the Google API to search for queries similar to those presented above. (See the source code for Google Hack #55 for a simple example on how to query the Google API using PHP.) It reads a text file, signatures.txt, that contains Google queries and their descriptions. The script accepts a domain name as a parameter to constrain searches to within an organization's domain.

The signatures.txt file contains a list of selected queries, similar to those presented in the previous sections. After every line that contains a specific query comes a line that provides a description of the query. The script iterates through the signatures.txt file, and for each query, searches Google for results using the Google API. The script appends site: domain to every query. This allows the script to target a specific given domain, a required parameter for the script. If Google returns valid results, the script displays the applicable URLs, along with the descriptions of the queries.

To run this script:

• Go to Google Web APIs and sign up for an account. They will mail you a license key.
• Download the google_vulns.php PHP script.
• Edit the script and change the value of $key to reflect your Google license key.
• Download signatures.txt and place it in the same directory as google_vulns.php.
• Download GoogleSearch.wsdl and place it in the same directory as google_vulns.php.
• Download nusoap.php from NuSOAP.

Now run google_vulns.php from the command line:

[bash]$ php ./google_vulns example.com

You may also run google_vulns.php with a less restrictive domain name, such as .edu:

[bash]$ php ./google_vulns .edu
************************************************
Search string: site:.edu intitle:"Index of" service.pwd
URL: http://[removed for this article]/
Directory listing contains service.pwd file(s)
************************************************
Search string: site:.edu intitle:"Index of" admin
URL: http://[removed for this article]/admin/
Directory listing contains administrative files or directories
************************************************
************************************************
Search string: site:.edu intitle:"Index of" .htpasswd
URL: http://[removed for this article]/
Directory listing contains .htpasswd file!
************************************************
************************************************
Search string: site:.edu intitle:"Index of" stats.html
URL: http://[removed for this article]/
Directory listing contains stats.html which may contain useful web server 
statistics
************************************************
************************************************
Search string: site:.edu intitle:"Index of" .bash_history
URL: http://[removed for this article]/
Directory listing contains bash history information
************************************************
...
...
...

The google_vulns.php script is only a proof-of-concept implementation. It is not multi-threaded, and follows Google API's policy limit of only returning ten results per query. To perform exhaustive searches, use a tool such as SiteDigger instead.

As you can see from the output, it is very easy to use Google to find vulnerabilities within a given organization. Because the script uses Google to search for the vulnerabilities, the target organization being scanned will not know of the scan until someone uses a URL from the result. This makes this type of scanning particularly stealthy.

Lessons Learned

The google_vulns.php script exposes vulnerabilities that are, in most cases, results of ignorance and negligence of the most basic best practices. Some of the example queries presented in this section rely on un-hardened web servers. The Apache web site contains links to numerous resources that can help administrators harden their web servers, including Apache httpd security tips and Apache httpd tutorials. In addition, administrators should routinely audit directories that serve as web roots to ensure the absence of sensitive content.

Web applications should also undergo hardening to not provide sensitive information to users. Many web-application vulnerabilities happen due to insecure coding practices. Here are some resources that can help developers understand how to secure their applications:

• "PHP Security" (Part 1, Part 2, and Part 3).
• "Secure Programming for Linux and Unix HOWTO"
• "Perl Security"
• "How to Remove Meta-characters From User-Supplied Data in CGI Scripts"
• "Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication"

Remote services, such as VNC and Terminal Services, should be inaccessible directly from the Internet. Require remote users to authenticate to VPN gateways that employ strong encryption in order to access remote services.

Conclusion

Given the vast amount of free online security resources available today, there is simply no excuse for not hardening critical hosts in order to prevent the exposure of private data. Although the material presented in this article does not reflect all possible vulnerabilities, hopefully the content has demonstrated the need for further diligence on the part of administrators and end users.

Nitesh Dhanjani is a well known security researcher, author, and speaker. Dhanjani has been invited to talk at various information security events such as the Black Hat Briefings, RSA, Hack in the Box, Microsoft Blue Hat, and OSCON.

---

Return to the Security DevCenter