Google hacking for penetration tester - part 30 ppt

<a href="<! #echo encoding="url" var="HTTP_REFERER" >">referring
page</a> seems to be wrong or outdated. Please inform the author of
<a href="<! #echo encoding="url" var="HTTP_REFERER" >">that page</a>
about the error.
<! #else >
If you entered the URL manually please check your
spelling and try again.
<! #endif >
<!—#include virtual=”include/bottom.html” —>
en
Notice that the sections of the error page are clearly labeled, making it easy to translate
into Google queries.The TITLE variable, shown near the top of the listing, indicates that
the text “Object not found!” will be displayed in the browser’s title bar. When this file is pro-
cessed and displayed in a Web browser, it will look like Figure 8.2. However, Google hacking
is not always this easy. A search for intitle:“Object not found!” is too generic, returning the
results shown in Figure 8.7.
Figure 8.7 Error Message Text Is Not Enough for Profiling
Tracking Down Web Servers, Login Portals, and Network Hardware • Chapter 8 291
452_Google_2e_08.qxd 10/5/07 1:03 PM Page 291
These results are not what we’re looking for.To narrow our results, we need a better
base search. Constructing our base search from the template files included with the Apache
2.0 source code not only enables us to locate all the potential error messages the server is
capable of producing, it also shows us how those messages are translated into other lan-
guages, resulting in very solid multilingual base searches.
The HTTP_NOT_FOUND.html.var file listed previously references two virtual include
lines, one near the top (include/top.html) and one near the bottom (include/bottom.html).These
lines instruct Apache to read and insert the contents of these two files (located in our case in
the /var/www/error/include directory) into the current file.The following code lists the con-
tents of the bottom.html file and show some subtleties that will help construct that perfect
base search:
</dd></dl><dl><dd>

<! #include virtual=" /contact.html.var" >
</dd></dl>
<h2>Error <! #echo encoding="none" var="REDIRECT_STATUS" ></h2>
<dl>
<dd>
<address>
<a href="/"><! #echo encoding="url" var="SERVER_NAME" ></a>
<br />
<! #config timefmt="%c" >
<small><! #echo encoding="none" var="DATE_LOCAL" ></small>
<br />
<small><! #echo encoding="none" var="SERVER_SOFTWARE" ></small>
</address>
</dd>
</dl>
</body>
</html>
First, notice line 4, which will display the word “Error” on the page.Although this might
seem very generic, it’s an important subtlety that would keep results like the ones in Figure
8.7 from displaying. Line 2 shows that another file (/var/www/error/contact.html.var) is read
and included into this file.The contents of this file, listed as follows, contain more details
that we can include into our base search:
1. Content-language: en
2. Content-type: text/html
3. Body: en
4. If you think this is a server error, please contact
292 Chapter 8 • Tracking Down Web Servers, Login Portals, and Network Hardware
452_Google_2e_08.qxd 10/5/07 1:03 PM Page 292
5. the <a href="mailto:<! #echo encoding="none" var="SERVER_ADMIN"
>">webmaster</a>

6. en
This file, like the file that started this whole “include chain,” is broken up into sections
by language.The portion of this file listed here shows yet another unique string we can use.
We’ll select a fairly unique piece of this line, “think this is a server error,” as a portion of our
base search instead of just the word error, which we used initially to remove some false posi-
tives.The other part of our base search, intitle:“Object not found!”, was originally found in the
/error/http_BAD_REQUEST.html.var file.The final base search for this file then becomes
intitle:“Object Not Found!”“think this is a server error”, which returns more accurate results, as
shown in Figure 8.8.
Figure 8.8 A Good Base Search Evolved
Now that we’ve found a good base search for one error page, we can automate the
query-hunting process to determine good base searches for the other error pages referenced
in the httpd.conf file, helping us create solid base searches for each and every default Apache
(2.0) error page.The contact.html.var file that we saw previously is included in each and every
Apache 2.0 error page via the bottom.html file.This means that “think this is a server error” will
work for all the different error pages that Apache 2.0 will produce.The other critical ele-
ment to our search was the intitle search, which we could grep for in each of the error files.
Tracking Down Web Servers, Login Portals, and Network Hardware • Chapter 8 293
452_Google_2e_08.qxd 10/5/07 1:03 PM Page 293
While we’re at it, we should also try to grab a snippet of the text that is printed in each of
the error pages, remembering that in some cases a more specific search might be needed.
Using some basic shell commands, we can isolate both the title of an error page and the text
that might appear on the error page:
grep -h -r "Content-language: en" * -A 10 | grep -A5 "TITLE" | grep -v virtual
This Linux bash shell command, when run against the Apache 2.0 source code tree, will
produce output similar to that shown in Table 8.2.This table lists the title of each English
Apache (2.0 and newer) error page as well as a portion of the text that will be located on
the page. Instead of searching for English messages only, we could search for errors in other
Apache-supported languages by simply replacing the Content-language string in the previous
grep command from en to either de, es, fr, or sv, for German, Spanish, French, or Swedish,

respectively.
Table 8.2 The Title and Partial Text of English Apache 2.0 Error Pages
Error Page Title Error Page Partial Text
Bad gateway! The proxy server received an invalid response
from an upstream server.
Bad request! Your browser (or proxy) sent a request that this
server could not understand.
Access forbidden! You don’t have permission to access the
requested directory. Either there is no index
document or the directory is read-protected.
Resource is no longer available! The requested URL is no longer available on
this server and there is no forwarding address.
Server error! The server encountered an internal error and
was unable to complete your request.
Method not allowed! A request with the method is not allowed for
the requested URL.
No acceptable object found! An appropriate representation of the
requested resource could not be found on this
server.
Object not found! The requested Uniform Resource Locator (URL)
was not found on this server.
Cannot process request! The server does not support the action
requested by the browser.
Precondition failed! The precondition on the request for the URL
failed positive evaluation.
294 Chapter 8 • Tracking Down Web Servers, Login Portals, and Network Hardware
Continued
452_Google_2e_08.qxd 10/5/07 1:03 PM Page 294
Table 8.2 continued The Title and Partial Text of English Apache 2.0 Error Pages
Error Page Title Error Page Partial Text

Request entity too large! The method does not allow the data trans-
mitted, or the data volume exceeds the
capacity limit.
Request time-out! The server closed the network connection
because the browser didn’t finish the request
within the specified time.
Submitted URI too large! The length of the requested URL exceeds the
capacity limit for this server. The request
cannot be processed.
Service unavailable! The server is temporarily unable to service your
request due to maintenance downtime or
capacity problems. Please try again later.
Authentication required! This server could not verify that you are autho-
rized to access the URL. You either supplied the
wrong credentials (such as a bad password), or
your browser doesn’t understand how to
supply the credentials required.
Unsupported media type! The server does not support the media type
transmitted in the request.
Variant also varies! A variant for the requested entity is itself a
negotiable resource. Access not possible.
To use this table, simply supply the text in the Error Page Title column as an intitle
search and a portion of the text column as an additional phrase in the search query. Since
some of the text is lengthy, you might need to select a unique portion of the text or replace
common words with an asterisk, which will reduce your search query to the 10-word limit
imposed on Google queries. For example, a good query for the first line of the table might
be “response from * upstream server.” intitle:“Bad Gateway!”. Alternately, you could also rely on
the “think this is a server error” phrase combined with a title search, such as “think this is a
server error” intitle:“Bad Gateway!”. Different versions of Apache will display slightly different
error messages, but the process of locating and creating solid base searches from software

source code is something you should get comfortable with to stay ahead of the ever-
changing software market.
This technique can be expanded to find Apache servers in other languages by reviewing
the rest of the contact.html.var file.The important strings from that file are listed in Table 8.3.
Because these sentences and phrases are included in every Apache 2.0 error message, they
should appear in the text of every error page that the Apache server produces, making them ideal
for base searches. It is possible (and fairly easy) to modify these error pages to provide a more
Tracking Down Web Servers, Login Portals, and Network Hardware • Chapter 8 295
452_Google_2e_08.qxd 10/5/07 1:03 PM Page 295
polished appearance when a user encounters an error, but remember, hackers have different
motivations. Some are simply interested in locating particular versions of a server, perhaps to
exploit. Using this criteria, there is no shortage of servers on the Internet that are using these
default error phrases, and by extension may have a default, less-secured configuration.
Table 8.3 Phrases Located on All Default Apache (2.0.28–2.0.52) Error Pages
Language Phrases
German Sofern Sie dies für eine Fehlfunktion des Servers
halten, informieren Sie bitte den hierüber.
English If you think this is a server error, please contact.
Spanish En caso de que usted crea que existe un error en el
servidor.
French Si vous pensez qu’il s’agit d’une erreur du serveur,
veuillez contacter.
Swedish Om du tror att detta beror på ett serverfel, vänligen
kontakta.
Besides Apache and IIS, other servers (and other versions of these servers) can be located
by searching for server-produced error messages, but we’re trying to keep this book just a bit
thinner than your local yellow pages, so we’ll draw the line at just these two servers.
Application Software Error Messages
The error messages we’ve looked at so far have all been generated by the Web server itself.
In many cases, applications running on the Web server can generate errors that reveal infor-

mation about the server as well.There are untold thousands of Web applications on the
Internet, each of which can generate any number of error messages. Dedicated Web assess-
ment tools such as SPI Dynamic’s WebInspect excel at performing detailed Web application
assessments, making it seem a bit pointless to troll Google for application error messages.
However, we search for error message output throughout this book simply because the data
contained in error messages should not be overlooked.
We’ve looked at various error messages in previous chapters, and we’ll see more error
messages in later chapters, but let’s take a quick look at how error messages can help profile
a Web server and its applications.Admittedly, we will hardly scratch the surface of this topic,
but we’ll make an effort to stimulate your thinking about Google’s ability to locate these
sometimes very telling error messages.
One query, “Fatal error: Call to undefined function” -reply -the –next, will locate Active
Server Page (ASP) error messages.These messages often reveal information about the
database software in use on the server as well as information about the application that
caused the error (see Figure 8.9).
296 Chapter 8 • Tracking Down Web Servers, Login Portals, and Network Hardware
452_Google_2e_08.qxd 10/5/07 1:03 PM Page 296
Figure 8.9 ASP Custom Error Messages
Although this ASP message is fairly benign, some ASP error messages are much more
revealing. Consider the query “ASP.NET_SessionId”“data source=”, which locates unique
strings found in ASP.NET application state dumps, as shown in Figure 8.10.These dumps
reveal all sorts of information about the running application and the Web server that hosts
that application. An advanced attacker could use encrypted password data and variable infor-
mation in these stack traces to subvert the security of the application and perhaps the Web
server itself.
Figure 8.10 ASP Dumps Provide Dangerous Details
Tracking Down Web Servers, Login Portals, and Network Hardware • Chapter 8 297
452_Google_2e_08.qxd 10/5/07 1:03 PM Page 297
Hypertext Preprocessor (PHP) application errors are fairly commonplace.They can
reveal all sorts of information that an attacker can use to profile a server. One very common

error can be found with a query such as intext:“Warning: Failed opening” include_path, as
shown in Figure 8.11.
Figure 8.11 Many Errors Reveal Pathnames and Filenames
CGI programs often reveal information about the Web server and its applications in the
form of environment variable dumps. A typical environmental variable output page is shown
in Figure 8.12.
Figure 8.12 CGI Environment Listings Reveal Lots of Information
This screen shows information about the Web server and the client that connected to
the page when the data was produced. Since Google’s bot crawls pages for us, one way to
298 Chapter 8 • Tracking Down Web Servers, Login Portals, and Network Hardware
452_Google_2e_08.qxd 10/5/07 1:03 PM Page 298
find these CGI environment pages is to focus on the trail left by the bot, reflected in these
pages as the “HTTP_FROM=googlebot” line. We can search for pages like this with a query
such as “HTTP_FROM=googlebot“ googlebot.com “Server_Software”. These pages are dynami-
cally generated, which means that you must look at Google’s cache to see the document as it
was crawled.
To locate good base searches for a particular application, it’s best to look at the source
code of that application. Using the techniques we’ve explored so far, it’s simple to create
these searches.
Default Pages
Another way to locate specific types of servers or Web software is to search for default Web
pages. Most Web software, including the Web server software itself, ships with one or more
default or test pages.These pages can make it easy for a site administrator to test the installa-
tion of a Web server or application. By providing a simple page to test, the administrator can
simply connect to his own Web server with a browser to validate that the Web software was
installed correctly. Some operating systems even come with Web server software already
installed. In this case, the owner of the machine might not even realize that a Web server is
running on his machine.This type of casual behavior on the part of the owner will lead an
attacker to rightly assume that the Web software is not well maintained and is, by extension,
insecure. By further extension, the attacker can also assume that the entire operating system

of the server might be vulnerable by virtue of poor maintenance.
In some cases, Google crawls a Web server while it is in its earliest stages of installation,
still displaying a set of default pages. In these cases there’s generally a short window of time
between the moment when Google crawls the site and when the intended content is actu-
ally placed on the server.This means that there could be a disparity between what the live
page is displaying and what Google’s cache displays.This makes little difference from a
Google hacker’s perspective, since even the past existence of a default page is enough for
profiling purposes. Remember, we’re essentially searching Google’s cached version of a page
when we submit a query. Regardless of the reason a server has default pages installed, there’s
an attacker somewhere who will eventually show interest in a machine displaying default
pages found with a Google search.
A classic example of a default page is the Apache Web server default page, shown in
Figure 8.13.
Tracking Down Web Servers, Login Portals, and Network Hardware • Chapter 8 299
452_Google_2e_08.qxd 10/5/07 1:03 PM Page 299
Figure 8.13 A Typical Apache Default Web Page
Notice that the administrator’s e-mail is generic as well, indicating that not a lot of
attention was paid to detail during the installation of this server.These default pages do not
list the version number of the server, which is a required piece of information for a suc-
cessful attack. It is possible, however, that an attacker could search for specific variations in
these default pages to find specific ranges of server versions. As shown in Figure 8.14, an
Apache server running versions 1.3.11 through 1.3.26 shows a slightly different page than
the Apache server version 1.3.11 through 1.3.26, as shown in Figure 8.13.
Figure 8.14 Subtle Differences in Apache Default Pages
300 Chapter 8 • Tracking Down Web Servers, Login Portals, and Network Hardware
452_Google_2e_08.qxd 10/5/07 1:03 PM Page 300