For example, most penetration testers are provided with specific instructions about which networks and systems they will be testing. Their targets are specified for many reasons, but in all cases, their targets are clearly defined or bounded in some fashion. Hackers, on the other hand, have the luxury of selecting from a wider target base. Depending on his or her motivations and skill level, the attacker might opt to select a target based on known exploits at his or her disposal. This reverses the model used by pen testers, and as such it affects the structure we will use to explore the topic of Google hacking. The techniques we’ll explore in the next few chapters are most often employed by hackers – the “bad guys.”

Penetration testers have access to the techniques we’ll explore in these chapters, but in many cases these techniques are too cumbersome for use during a vulnerability assessment, when time is of the essence. Security professionals often use specialized tools that perform these tasks in a much more streamlined fashion, but these tools make lots of noise and often overlook the simplest form of information leakage that Google is so capable of revealing – and revealing in a way that’s nearly impossible to catch on the “radar.” The techniques we’ll examine here are used on a daily basis to locate and explore the systems and networks attached to the Internet, so it’s important that we explore how these techniques are used to better understand the level of exposure and how that exposure can be properly mitigated.

The techniques we explore in this chapter are used to locate and analyze the front-end systems on an Internet-connected network. We look at ways an attacker can profile Web servers using seemingly insignificant clues found with Google queries. Next, we’ll look at methods used to locate login portals, the literal front door of most Web sites. As we will see, some login portals provide administrators of a system an access point for performing various administrative functions. Most login portals provide clues to an attacker about what software is in use on the server, and draws the attention of attackers that are armed with an exploit for that particular type of software. We round out the chapter by showing techniques that can be used to locate all sorts of network devices – firewalls, routers, network printers, and even Web cameras.

There are many different ways to locate a server. The most common way is with a simple portscan. Using a tool such as Nmap, a simple scan of port 80 across a class C network will expose potential Web servers. Integrated tools such as Nessus, OpenVAS, Qualys, or Retina will run some type of portscan, followed by a series of security tests. These functions can be replicated with Google queries, although in most cases the results are nowhere near as effective as the results from a well-thoughtout vulnerability scanner or Web assessment tool. Remember, though, that Google queries are less obvious and provide a degree of separation between an attacker and a target. Also remember that hackers can use Google hacking techniques to find systems you may be charged with protecting. The bottom line is that it’s important to understand the capabilities of the Google hacker and realize the role Google can play in an attacker’s methodology.

Some login portals, like the one shown in Figure 8.3, captured with “microsoft outlook” “web access” version, are obviously default pages provided by the software manufacturer – in this case, Microsoft. Just as an attacker can get an idea of the potential security of a target by simply looking for default pages, a default login portal can indicate that the technical skill of the server’s administrators is generally low, revealing that the security of the site will most likely be poor as well. To make matters worse, default login portals like the one shown in Figure 8.4, indicate the software revision of the program. An attacker can use this information to search for known vulnerabilities in that software version.

By following links from the login portal, an attacker can often gain access to other information about the target. The Outlook Web Access portal is particularly renowned for this type of information leak, because it provides an anonymous public access area that can be viewed without logging in to the mail system. This public access area sometimes provides access to a public directory or to broadcast emails that can be used to gather usernames or information, as shown in Figure 8.2.

Some login portals provide more details than others. As shown in Figure 8.4, provides a great deal of information about the server, including server software version and revision, application software version and revision, software upgrade date, and server uptime. This type of information is very handy for an attacker staging an attack against the server.

Login portals provide great information for use during a vulnerability assessment. Chapter 4 provides more details on getting the most from these pages.

Default installations of NQT allow any Web user to perform Internet Protocol (IP) hostname and address lookups, Domain Name Server (DNS) queries, WHOIS queries, port testing, and traceroutes. This is a Web-based application, meaning that any user who can view the page can generally perform these functions against just about any target. This is a very handy tool for any security person, and for good reason. NQT functions appear to originate from the site hosting the NQT application. The Web server masks the real address of the user. The use of an anonymous proxy server would further mask the user’s identity.

We can use Google to locate servers hosting the NQT program with a very simple query. The NQT program is usually called nqt.php, and in its default configuration displays the title “Network Query Tool.” A simple query like inurl:nqt.php intitle:“Network Query Tool” returns many results, as shown in Figure 8.6.

After submitting this query, it’s a simple task to simply click on the results pages to locate a working NQT program. However, the NQT program accepts remote POSTS, which means it’s possible to send an NQT “command” from your Web server to the foo.com server, which would execute the NQT “command” on your behalf. If this seems pointless, consider the fact that this would allow for simple extension of NQT’s layout and capabilities. We could, for example, easily craft an NQT “rotator” that would execute NQT commands against a target, first bouncing it off an Internet NQT server. Let’s take a look at how that might work.

First, we’ll scrape the results page shown in Figure 8.5, creating a list of sites that host NQT. Consider the following Linux/Mac OS X command:

This command grabs 100 results of the Google query inurl:nqt.php intitle:“Network Query Tool”, locates the word nqt.php at the end of a line, removes any line that contains the word google, prints the second field in the list (which is the URL of the NQT site), and uniquely sorts that list. This command will not catch NQT URLs that contain parameters (since nqt.php will not be the last word in the link), but it produces clean output that might look something like this:

We could dump this output into a file by appending >> nqtfile.txt to the end of the previous sort command. Now that we have a working list of NQT servers, we’ll need a copy of the NQT code that produces the interface. This interface, with its buttons and “enter host or IP” field, will serve as the interface for our “rotator” program. Getting a copy of this interface is as easy as viewing the source of an existing nqt.php Web page (say, from the list of sites in the nqtfile.txt file), and saving the HTML content to a file we’ll call rotator.php on our own Web server. At this point, we have two files in the same directory of our Web server – an nqtfile.txt file containing a list of NQT servers, and a rotator.php file that contains the HTML source of NQT. We’ll be replacing a single line in the rotator.php file to create our “rotator” program. This line, which is the beginning of the NQT input form, reads:

This line indicates that once the “Do it” button is pressed, data will be sent to a script called nqt.php. If we were to modify this form field to <form method = “post” action = “http://foo.com/nqt.php”>, our rotator program would send the NQT command to the NQT program located at foo.com, which would execute it on our behalf. We’re going to take this one step further, inserting PHP code that will read a random site from the nqtfile.txt program, inserting it into the form line for us. This code might look something like this (lines numbered for clarity):

lines in the original NQT HTML code. Line 1 indicates that a PHP code segment is about to begin. Since the rest of the rotator.php file is HTML, this line, as well as line 7 that terminates the PHP code segment, is required. Line 2 reads our nqtsites.txt file, assigning each line in the file (a URL to an NQT site) to an array element. Line 3, included as a separate line for readability, assigns one random line from the nqtsites.txt program to the variable $site. Line 4 outputs the modified version of the original form line, modifying the action target to point to a random remote NQT site. Lines 5 and 6 simply output informative messages about the NQT site that was selected, and instructions for loading a new NQT site. The next line in the rotator.php script would be the table line that draws the main NQT table.

Our rotator program looks very similar to the standard NQT program interface, with the addition of the two initial lines of text. However, when the “check port” box is checked, www.microsoft.com is entered into the host field, and the Do It button is clicked, we are whisked away to the results page on a remote NQT server that displays the results – port 80 is, in fact, open and accepting connections, as shown in Figure 8.7.

This example is designed to suggest that Google can be used to supplement the use of many Web-based applications. All that’s required is a bit of Google know-how and a healthy dose of creativity.

A crafty attacker could use the mere existence of this device to craft his attack against the target network. For example, if this device is acting as a proxy server, the attacker might attempt to use it to gain access to machines inside a trusted network by bouncing connections off this server. Additionally, an attacker might search for any public vulnerabilities for this product in an attempt to exploit this device directly. Although many different devices can be located in this way, it’s generally easier to harvest IP and network data using the output from network statistical programs as we’ll see in the next section. To get an idea of the types of devices that can be located with this technique, consider queries like “Version Info”“BootVersion”“Internet Settings”, which locate Belkin Cable/DSL routers; intitle:“wbem” compaq login, which locates HP Insight Management Agents; intitle:“lantronix web-manager”, which locates Lantronix Web managers; inurl:tech-support inurl:show Cisco or intitle:“switch home page” “cisco systems” “Telnet - to”, which locates various Cisco products; or intitle:“axis storpoint CD” intitle:“ip address”, which can locate Axis StorPoint servers. Each of these queries reveals pages that report various bits of information about the networks on which they’re installed.

Practically any Web-based network statistics package can be located with Google. You can find several examples from the Google Hacking Database (GHDB) that show searches for various network documentation.

This type of information is a huge asset during a security audit, which can save a lot of time, but realize that any information found in this manner should be validated before using it in any type of finished report.

All types of devices can be connected to a network. These devices, ranging from switches and routers to printers and even firewalls, are considered great finds for any attacker interested in network reconnaissance, but some devices such as Webcams are interesting finds for an attacker as well.

In most cases, a network-connected Webcam is not considered a security threat but more a source of entertainment for any Web surfer. Keep a few things in mind, however. First, some companies consider it trendy and cool to provide customers a look around their workplace. Netscape was known for this back in its heyday. The Webcams located on these companies’ premises were obviously authorized by upper management. A look inside a facility can be a huge benefit if your job boils down to a physical assessment. Second, it’s not all that uncommon for a Webcam to be placed outside a facility, as shown in Figure 8.8. This type of cam is a boon for a physical assessment. Also, don’t forget that what an employee does at work doesn’t necessarily reflect what he does on his own time. If you locate an employee’s personal Web space, there’s a fair chance that these types of devices will exist.

Most network printers manufactured these days have some sort of Web-based interface installed. If these devices (or even the documentation or drivers supplied with these devices) are linked from a Web page, various Google queries can be used to locate them.

Once located, network printers can provide an attacker with a wealth of information. As shown in Figure 8.9, it is very common for a network printer to list details about the surrounding network, naming conventions, and more. Many devices located through a Google search are still running a default, insecure configuration with no username or password needed to control the device. In a worst-case scenario, attackers can view print jobs and even coerce these printers to store files or even send network commands.

Directory listings provide information about the software versions in use on a device. Server and application error messages can provide a wealth of information to an attacker and are perhaps the most underestimated of all information-gathering techniques. Default pages, programs, and documentation not only can be used to profile a target, but they serve as an indicator that the server is somewhat neglected and perhaps vulnerable to exploitation. Login portals, while serving as the “front door” of a Web server for regular users, can be used to profile a target, used to locate more information about services and procedures in use, and used as a virtual magnet for attackers armed with matching exploits. In some cases, login portals are set up by administrators to allow remote access to a server or network. This type of login portal, if compromised, can provide an entry point for an intruder as well.

Google can be used to locate or augment Web-based networking tools like NQT, which enables remote execution of various network-querying applications. Using creative queries, Google may even locate Web-enabled network devices in use by the target or output from network statistical packages. Whatever your goal during a network-based assessment, there’s a good chance Google can be used to augment your existing tools and techniques.