We start by looking at some queries that can be used to uncover usernames, the less important half of most authentication systems. The value of a username is often overlooked, but as we’ve already discussed, an entire multimillion-dollar security system can be shattered through skillful crafting of even the smallest, most innocuous bit of information.

Next, we will take a look at queries that are designed to uncover passwords. Some of the queries we look at reveal encrypted or encoded passwords, which will take a bit of work on the part of an attacker to use to his or her advantage. We also take a look at queries that can uncover cleartext passwords. These queries are some of the most dangerous in the hands of even the most novice attacker. What could make an attack easier than handing a username and cleartext password to an attacker?

We wrap up this chapter by discussing the very real possibility of uncovering highly sensitive data such as credit card information and information used to commit identity theft, such as Social Security numbers. Our goal here is to explore ways of protecting against this very real threat. To that end, we don’t go into details about uncovering financial information and the like. If you’re a “dark side” hacker, you’ll need to figure these things out on your own, or make the wise decision to turn to the light side of the force.

Many methods can be used to determine usernames. In Chapter 4, we explored ways of gathering usernames via database error messages. In Chapter 8, we explored Web server and application error messages that can reveal various kinds of information, including usernames. These indirect methods of locating usernames are helpful, but an attacker could target a usernames directory with a simple query like “your username is”. This phrase can locate help pages that describe the username creation process.

An attacker could use this information to postulate a username based on information gleaned from other sources, such as Google Groups posts or phone listings. The usernames could then be recycled into various other phases of the attack, such as a worm-based spam campaign or a social-engineering attempt. An attacker can gather usernames from a variety of sources.

In some cases, usernames can be gathered from Web-based statistical programs that check Web activity. The Webalizer program shows all sorts of information about a Web server’s usage. Output files for the Webalizer program can be located with a query such as +intext:webalizer +intext:“Total Usernames” +intext:“Usage Statistics for”. Among the information displayed is the username that was used to connect to the Web server. In some cases, however, the usernames displayed are not valid or current, but the “Visits” column lists the number of times a user account was used during the capture period. This enables an attacker to easily determine which accounts are more likely to be valid.

The Windows registry holds all sorts of authentication information, including usernames and passwords. Though it is unlikely (and fairly uncommon) to locate live, exported Windows registry files on the Web, at the time of this writing there are nearly 200 hits on the query filetype:reg HKEY_CURRENT_USER username, which locates Windows registry files that contain the word username and in some cases passwords.

Remember that there are several ways to search for a known filename. One way relies on locating the file in a directory listing, like intitle:index.of install.log. Another, often better, method relies on the filetype operator, as in filetype:log inurl:install.log. Directory listings are not all that common. Google will crawl a link to a file in a directory listing, meaning that the filetype method will find both directory listing entries as well as files crawled in other ways.

As any talented attacker or security person will tell you, it’s rare to get information served to you on a silver platter. Most decent finds take a bit of persistence, creativity, intelligence, and just a bit of good luck. For example, consider the Microsoft Outlook Web Access portal, which can be located with a query like inurl:root.asp?acs = anon. There are few hits for this query, even though there lots of sites run the Microsoft Web-based mail portal. Regardless of how you might locate a site running this email gateway, it’s not uncommon for the site to host a public directory (denoted “Find Names,” by default), as shown in Figure 9.1.

The public directory allows access to a search page that can be used to find users by name. In most cases, wildcard searching is not allowed, meaning that a search for * will not return a list of all users, as might be expected. Entering a search for a space is an interesting idea; since most user descriptions contain a space, but most large directories will return an error message reading “This query would return too many addresses!” Applying a bit of creativity, an attacker could begin searching for individual common letters, such as the “Wheel of Fortune letters” R, S, T, L, N, and E. Eventually one of these searches will most likely reveal a list of user information.

Once a list of user information is returned, the attacker can then recycle the search with words contained in the user list, searching for the words Voyager, Freshmen, or Campus, for example. Those results can then be recycled, eventually resulting in a nearly complete list of user information.

In most cases, passwords discovered on the Web are either encrypted or encoded in some way. In most cases, these passwords can be fed into a password cracker such as John the Ripper from www.openwall.com/john to produce plaintext passwords that can be used in an attack. Figure 9.2 shows the results of the search ext:pwd inurl:_vti_pvt inurl:(Service | authors | administrators), which combines a search for some common Microsoft FrontPage support files. While Microsoft FrontPage is no longer supported by Microsoft it can still be found in use around. Note that live, exported Windows registry files are not very common, but it’s not uncommon for an attacker to target a site simply because of one exceptionally insecure file. It’s also possible for a Google query to uncover cleartext passwords. These passwords can be used as is, without having to employ a password-cracking utility. In these extreme cases, the only challenge is determining the username as well as the host on which the password can be used. As shown in Figure 9.3, certain queries will locate all the following information: usernames, cleartext passwords, and the host that uses that authentication!

There is no magic query for locating passwords, but during an assessment, remember that the simplest queries directed at a site can have amazing results, as we discussed in Chapter 7. For example, a query like “Your password” forgot would locate pages that provide a forgotten password recovery mechanism. The information from this type of query can be used to formulate any number of attacks against a password. As always, effective social engineering is a terrific nontechnical solution to “forgotten” passwords.

Another generic search for password information, intext:(password | passcode | pass) intext:(username | userid | user), combines common words for passwords and user IDs into one query. This query returns a lot of results, but the vast majority of the top hits refer to pages that list forgotten password information, including either links or contact information.

Using Google’s translate feature, found at http://translate.google.com/translate_t, we could also create multilingual password searches. Note that the terms username and userid in most languages translate to username and userid, respectively.

What might surprise you is that it doesn’t take a rocket scientist to uncover live credit card numbers on the Internet as seen in Figure 9.4. Thanks to search engines like Google, everything from credit information to banking data or supersensitive classified government documents can be found on the Web.

This document, found using Google, lists hundreds and hundreds of credit card numbers (including expiration date and card validation numbers) as well as the owners’ names, addresses, and phone numbers. This particular document also included phone card (calling card) numbers. In most cases, pages that contain these numbers are not “leaked” from online retailers or e-commerce sites but rather are most likely the fruits of a scam known as phishing, in which users are solicited via telephone or email for personal information. Several Web sites, including MillerSmiles.co.uk, document these scams and hoaxes. Figure 9.5 shows a screenshot of a popular eBay phishing scam that encourages users to update their eBay profile information.

Once a user fills out this form, all the information is sent via email to the attacker, who can use it for just about anything. Sometimes this data is stored on a Web server used by the attacker. In some cases I’ve seen online “phishing investigators” post reports which link to the phisher’s cache of pilfered personal data. When a search engine crawls those links, all that personal data is suddenly available to even the most amateur Google hacker.

Some of this information is fairly benign – for example, MSN Messenger contact list files that can be found with a query like filetype:ctt messenger, or AOL Instant Messenger (AIM) buddy lists that can be located with a query such as filetype:blt blt +intext:screenname.

This screen shows a list of “buddies,” or acquaintances an individual has entered into his or her AIM client. An attacker often uses personal information like this in a social-engineering attack, attempting to convince the target that they are a friend or an acquaintance. This practice is akin to pilfering a Rolodex or address book from a target. For a seasoned attacker, information like this can lead to a successful compromise. However, in some cases, data found with a Google query reveals sensitive security-related information that even the most novice attacker could use to compromise a system.

For example, consider the output of the Nessus security scanner available from www.nessus.org. This excellent open-source tool conducts a series of security tests against a target, reporting on any potential vulnerability. The report generated by Nessus can then be used as a guide to help system administrators lock down any affected systems. An attacker could also use a report like this to uncover a target’s potential vulnerabilities. Using a Google query such as “This file was generated by Nessus”, an attacker could locate reports generated by the Nessus tool. This report lists the IP address of each tested machine as well as the ports opened and any vulnerabilities that were detected.

In most cases, reports found in this manner are samples, or test reports, but in a few cases, the reports are live and the tested systems are, in fact, exploitable as listed. One can only hope that the reported systems are honeypots – machines created for the sole purpose of luring and tracing the activities of hackers. In the next chapter, we’ll talk more about “document-grinding” techniques, which are also useful for digging up this type of information. This chapter focused on locating the information based on the name of the file, whereas the next chapter focuses on the actual content of a document rather than the name.

As droll as it might sound, a solid, enforced security policy is a great way to keep sensitive data from leaking to the Web. If users understand the risks associated with information leakage and understand the penalties that come with violating policy, they will be more willing to cooperate in what should be a security partnership.

In the meantime, it certainly doesn’t hurt to understand the tactics an adversary might employ in attacking a Web server. One thing that should become clear as you read this book is that any attacker has an overwhelming number of files to go after. One way to prevent dangerous Web information leakage is by denying requests for unknown file types. Whether your Web server normally serves up CFM, ASP, PHP, or HTML, it’s infinitely easier to manage what should be served by the Web server instead of focusing on what should not be served. Adjust your servers or your border protection devices to allow only specific content or file types.