Google Your Site For Security Vulnerabilities

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:

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:

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:

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.

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:

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.

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:

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.