Information Gathering

Before starting your organization's assessment, there are some questions you will need to get answered . Many security firms attempt to gather as much information as possible from administrators in order to conduct vulnerability assessments. The fact of the matter is, even if the administrator in charge (or the IT manager herself) provides you with information on the organization's public exposures, you should not take them at face value and conduct the assessment on this basis. Every item provided should be validated through the use of techniques provided in this chapter. Whether an administrator "forgets" about an IP address block or knows there are vulnerable systems and attempts to hide them from you, it is your job to find all publicly available services pertaining to the organization. You should assume you will not receive all pertinent information and you must be able to go find it for yourself.

The areas we will cover in the information-gathering phase to help you find all public services and addresses are

• Public Routing Prefix Announcements What do we see available on the Internet for the organization in terms of IP address blocks, autonomous system (AS) numbers , and more?

• ISP Route Filter Policy How are the organization's IP address blocks routed (what do we see from other service providers on the Internet regarding our IP address space)?

• Address Block Registrar Configurations What information is available publicly regarding the organization's IP address blocks? How can we use this to find additional address blocks, AS numbers assigned, and so on?

• Domain Registrations What domains are registered by the organization? Are they registered properly and do they provide any additional clues or information?

• Name Service (DNS) What information is available publicly and are there any weaknesses allowing us to gather additional information from the name service (even if it is maintained by a service provider)?

Tip 

Don't limit your information gathering to these sources. Other great sources include organizations' HR- related employment postings (if they're hiring people with experience regarding Sun Microsystems products, you know they run Sun Microsystems products), press releases, SEC filings, and so on. Also, experiment with social engineeringcall up the organization and see what you can find out about it. Search newsgroups for postings by their engineers concerning help with technologies, look at the data contained in their domain registrations to ascertain their standard e-mail address naming conventions, and so on. Be creative.

Public Routing Prefix Announcements

There is a world of information publicly available about your organization. You may say, "So why is this a concern of mine when I am conducting security checks on my infrastructure? I should be worried about my firewall and web servers, not public information." This could not be further from the truth. The fact of the matter is that information gleaned from public sources can provide attackers with enough information to develop attack profiles with very high success rates. In fact, there may even be flaws in how this information is handled, which can allow an attacker to take control of your public information. Once this information is controlled by someone other than you, your organization essentially disappears from existence as far as the Internet is concerned .

The last example is a bit extreme, but don't think it is not possible. The information found publicly regarding your organization can be used against you as a means of information gathering, but also as an attack mechanism. If an attacker can trick public service providers into believing he or she works for or is responsible for the organization targeted in the attack, changes can be made to adversely affect the organization or provide the attacker with an advantage during the attack. Registrars, DNS, and Internet routing are all areas where information about your organization and its infrastructure are stored. Each of these subsequently becomes an information gathering tool, or worse , an attack vector.

You should receive an initial list of IP address blocks when conducting your vulnerability assessment planning. Use this list as a starting point for your assessment. Every good project will start with the first step, so off we go .

Our Acme representative provided us with one /24 network address block. We were told all public services reside on 2.2.0.0/24.

Note 

The 2.2.0.0 subnet mentioned is currently registered to the Internet Assigned Numbers Authority (IANA) and is considered a "bogon" network (or unallocated ). Additionally, the AS numbers and other service providers' names listed later in the chapter are not legitimate . The AS numbers are examples from private allocations . The service provider names are simulated in the same manner as the Acme name.

This means Acme has 254 usable IP addresses (if we assume they run a flat, nonsubnetted /24 network) that may have public services availableor so it would seem. Our first step will be to use a public looking glass to validate how Acme's /24 network is routed on the Internet. Below is an example of Border Gateway Protocol (BGP) information available for Acme's address block. The information was solicited from a Global Crossing router for an IP address included in the block (2.2.0.1).

Note 

There are several public "looking glass" web sites or "route-view" servers that can be found by searching Google or any other search engine. We will explain more about route-view servers later in this chapter.

  Router:  Global Crossing (AS 3549)  Command:  show ip bgp 2.2.0.1 BGP routing table entry for  2.2.0.0/20,  version 155399 Paths: (4 available, best #4)   Not advertised to any peer   67234 62550, (received & used)     67.17.77.193 from  67.17.80.232  (67.17.80.232)       Origin IGP, metric 50, localpref 200, valid, internal       Community: 3549:2102 3549:30840       Originator: 67.17.80.219, Cluster list: 0.0.0.21   67234 62550, (received & used)     67.17.77.193 from  67.17.81.167  (67.17.81.167)       Origin IGP, metric 50, localpref 200, valid, internal       Community: 3549:2401 3549:30840       Originator: 67.17.80.182, Cluster list: 0.0.0.81   67234 62550, (received & used)     67.17.77.193 from  67.17.80.221  (67.17.80.221)       Origin IGP, metric 50, localpref 200, valid, internal       Community: 3549:2102 3549:30840       Originator: 67.17.80.219, Cluster list: 0.0.0.21   67234 62550, (received & used)     67.17.77.193 from  67.17.81.117  (67.17.81.117)       Origin IGP, metric 50, localpref 200, valid, internal, best       Community: 3549:2401 3549:30840       Originator: 67.17.80.182, Cluster list: 0.0.0.81 

The important information found in the data above is the routing table data (address block information), number of paths available for use, and the AS number for Acme, as well as the AS number for its BGP peer as shown. Each available path is shown as well as the best path . There are also miscellaneous data regarding who are peers, metrics, preferences, and more. Using the information above, we see our first anomaly in the information provided by Acme. It appears they did not provide us with accurate information when identifying address blocks.

  Router:  Global Crossing (AS 3549)  Command:  show ip bgp 2.2.0.1 BGP routing table entry for  2.2.0.0/20,  version 155399 

The BGP routing table holds an entry for a CIDR /20 address block, not CIDR /24 as Acme indicated. Instead of one CIDR /24, there is actually the equivalent of sixteen CIDR /24 networks. Already we have identified additional means of attack (expanding our theatre of war) by finding additional public address space. (Of course, we'll have to verify that the rest of the /20 network being announced actually belongs to Acme and that it hasn't simply been aggregated with other adjacent networks by Acme's Internet service provider.)

Acme's AS number is 62550 (read from right to left in the AS-Path) and its upstream provider (BGP peer) is Example Internet Provider, Inc. (AS number: 67234). There are four paths available for traffic to traverse to the Acme IP address block (or to this AS number). The best path is shown as follows :

 67234 62550, (received & used)     67.17.77.193 from  67.17.81.117  (67.17.81.117)       Origin IGP, metric 50, localpref 200, valid, internal, best       Community: 3549:2401 3549:30840       Originator: 67.17.80.182, Cluster list: 0.0.0.81 

One important thing to remember as the security analyst conducting the assessment is that you may not be in control of your Internet routing architecture, but information is available in that realm that can help an attacker gather information about your network or even derive attack vectors. Know how your Internet routing works normally and in the event any anomalies are found by you, these can be reported to your upstream providers.

Circa 1996, we were the first (to the best of our knowledge) to use what is now known as a route specificity attack to knock another Internet-connected organization offline. That's not to say that this hadn't occurred beforehand, but as far as we know, this is the first time it hadn't been the accidental result of a misconfiguration. Internet routing follows specificity above all other metrics (including cost metrics). Therefore, a well-studied attacker is able to redirect every packet destined for an organization's external IP addresses by way of advertising a "more specific" route to his or her particular segment of the Internet. The existence of a "more specific" route to any portion of an organization's network block would almost immediately reroute all traffic destined for said portion toward the more specific routing advertisement before following other relevant protocol directives. For easier visualization of the nature of this attack, "normal" and "compromised" state diagrams are included below to illustrate the direction of traffic flow based on route specificity.

Today most Tier-1 routers on the Internet actively filter (reject) routes that are more specific than CIDR /24. Further, many of them maintain route filter policies (access control lists) that preclude downstream routing entities from advertising arbitrary networks. This means that in order for an attacker to ubiquitously (globally) redirect Acme's traffic, he or she would need to advertise a route for any of Acme's IP prefixes of length /25 or longer (such as /32 and so on). Alternatively, they may inject an equal-length prefix (in which case the traffic may be shared between the legitimate router and the attacker's router). Another methodology may be to only redirect some portion of the traffic by injecting this on one or more particular ISP backbones and not attempting to inject it globally. In either case, this attack would have an incredibly detrimental impact. The nature of this service disruption would be cause for immediate concern at multiple ISPs (once it was figured out and reportedmost ISPs don't monitor for this) and it is likely that service would be restored quickly once ISPs realized what was happening and communicated with the miscreant providers to squelch their inappropriate advertisement. That said, the potential for attack is possible. Therefore, it should be mentioned during the vulnerability assessment to make other Acme administrators aware of the potential issue.

ISP Route Filter Policy

There are routers available on the Internet that provide information publicly regarding what is in the routing table for a particular organization. These routers (or the service provided on them) are known as route servers. Route servers are made available publicly by providers for one general purpose. When routing deficiencies are being experienced , these route servers can be used by service providers to see what is happening across other service providers from alternative perspectives. The route server is generally not a production system but a system connected into production that contains the same routing table (obviously locked down and limited in its capabilities for security reasons). As security analysts, we can use route servers to probe the public infrastructure further to determine whether other network blocks exist besides what we were provided or have already found. In our Acme assessment, we have already identified additional address space that we must include in our theatre of war; it is entirely possible other network space exists as well.

The first step is to telnet to a public route server. Route servers do not require any authentication (as they are in place for public use). When we check routes in the route server for Acme, we will use 2.2.0.0/20 since we know that definitely exists.

Note 

Search the Internet for public route servers. Several links to route server listings are available through Google or other search engines.

 root@scanner: $# telnet route-server.gblx.net Trying 67.17.81.28... Connected to loop0.route-server.phxl.gblx.net. Escape character is '^]'. CC ############################################## #  Global Crossing International IP Network  # #             Route View Server              # #                                            # #     TELNET to route-server.eu.gblx.net     # #       for European Route View Server       # #                                            # #   All connections and keystrokes logged    # #   Contact: GBLX-IP NOC: [e-mail]    # #               800-404-7714                 # ############################################## route-server.phx1>show ip bgp 2.2.0.0 BGP routing table entry for 2.2.0.0/20, version 10400836 Paths: (4 available, best #1)   Not advertised to any peer   67234 62550, (received & used)     67.17.77.193 from 67.17.81.117 (67.17.81.117)       Origin IGP, metric 50, localpref 200, valid, internal, best       Community: 3549:2401 3549:30840       Originator: 67.17.80.182, Cluster list: 0.0.0.81   67234 62550, (received & used)     67.17.77.193 from 67.17.81.167 (67.17.81.167)       Origin IGP, metric 50, localpref 200, valid, internal       Community: 3549:2401 3549:30840       Originator: 67.17.80.182, Cluster list: 0.0.0.81   67234 62550, (received & used)     67.17.77.193 from 67.17.80.232 (67.17.80.232)       Origin IGP, metric 50, localpref 200, valid, internal       Community: 3549:2102 3549:30840       Originator: 67.17.80.219, Cluster list: 0.0.0.21   67234 62550, (received & used)     67.17.77.193 from 67.17.80.221 (67.17.80.221)       Origin IGP, metric 50, localpref 200, valid, internal       Community: 3549:2102 3549:30840       Originator: 67.17.80.219, Cluster list: 0.0.0.21 

We show the same information we found in our looking glass checks earlier, confirming the additional address space we found earlier. An additional command we can run will check if any other networks exist under the AS number for Acme:

 route-server.phx1>show ip bgp regexp _62550$ BGP table version is 10558572, local router ID is 67.17.81.28 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,               S Stale Origin codes: i - IGP, e - EGP, ? - incomplete    Network          Next Hop            Metric LocPrf Weight Path *>i2.2.0.0/20 67.17.77.193            50    200      0 67234   62550 i * i           67.17.77.193            50    200      0 67234   62550 i * i           67.17.77.193            50    200      0 67234   62550 i * i           67.17.77.193            50    200      0 67234   62550 i route-server.phx1> 

Based on our findings with the regexp query, we did not find any additional address space for Acme. If there were any other network blocks for Acme's AS number, they would show up listed as additional networks. The 2.2.0.0/20 network appears to be all address space announced for Acme; however, there are some more checks we will conduct before we are convinced we have all address space.

A relatively new and alternative method of getting up-to-date routing-related information is a service called Prefix WhoIs (developed by the authors). By using Prefix WhoIs, a savvy administrator can retrieve current routing-related information (like the data available from route-view servers) directly from their command line using a standard whois client. (See http://www.pwhois.org for further details.) An example of a Prefix WhoIs query using any standard whois client may look like this:

 > whois -h whois.pwhois.org 4.2.2.1 IP: 4.2.2.1 Origin-AS: 3356 Prefix: 4.0.0.0/8 AS-Path: 3356 Cache-Date: 1114682701 

Prefix WhoIs also supplies its own advanced whois client named WhoB that is distributed with the Layer Four Traceroute tool discussed later in this chapter. WhoB makes it easy to query Prefix WhoIs and other whois data sources for only the most important information. An example query using WhoB may look like this:

 > whob -tuo www.google.com 66.102.7.104  origin-as 15169 (66.102.7.0/24)  28-Apr-05 10:05:01 GMT  Google 

Whois/Registrar Interrogation

Checks should be done in the Whois database to look for additional potential public exposure. The SWIP (Shared WhoIs Project) is a way of consolidating data for use by the general public. Generally, ISPs participating in SWIP will update IP address space allocations as well as domain registrations so that it is all publicly available. While in theory this sounds like a good thing, there are many ISPs not participating in the SWIP. Address space allocations do not always get updated properly so there is a chance you could miss networks and address space when searching the Whois database.

Tip 

Most large service providers today do not continually update customer allocations in the public whois servers, but rather maintain their own local rwhois servers, which contain current customer allocation information. This information will show up in whois as "ReferralServer: rwhois://rwhois.gblx.net:4321" (for example). The referral can be recursively queried to get the most up-to-date information.

Note 

Because not all ISPs update network allocations properly, there is a chance entire allocations could be purposely hidden. A miscreant needing address space could find an ISP not participating in SWIP and receive address allocations. These could conceivably never be "tied" back to the miscreant (keeping him or her anonymous on the public Internet).

IP network registrars hold information about IP networks in use by organizations. All allocated networks are assigned (even if assigned to the ISP and not reassigned to the individual or organization as annotated above). Similarly, domain registrars contain information about registrations for all domains on the Internet. If a domain or IP network is publicly available, it must be registered with a registrar in some fashion. The information gathered by the registrar is solicited for a few purposes, such as:

• Collecting and subsequently providing logistic information for the IP network or domain to include billing, admin, and technical contacts' names, addresses, and phone numbers

• Advertising authoritative DNS servers for the IP network or domain

• Advertising characteristics of the network such as range, type, net handles and tech handles (both unique identifiers for the network and technicians respectively), and contact information for required RFC 2142 e-mail addresses (or at a minimum the e-mail address of an individual who is responsible for the registrations)

Each of the items listed above could include specific information that could assist us in finding additional information or public exposures. These would eventually be included in our theatre of war. For example, the following is a whois query using the Acme network number we are aware of (2.2.0.0).

Tip 

If you have a more advanced (or "new") whois client, you may often use the -H operator to hide legal disclaimers and -h to connect to a specific whois server. In some whois clients , the "@thisServer" notation is used instead of -h.

 root@scanner:$# whois -H -h whois.arin.net 2.2.0.0 OrgName:    Acme, Inc. OrgID:      ACMEEE Address:    1234 N. First St. Address:    Suite 434 City:       Phoenix StateProv:  AZ PostalCode: 55512 Country:    US NetRange:   2.2.0.0 - 2.2.15.255 CIDR:       2.2.0.0/20 NetName:    ACMEINC NetHandle:  NET-2-2-0-0-1 Parent:     NET-2-0-0-0-0 NetType:    Direct Assignment NameServer: UDNS1.ULTRADNS.NET NameServer: UDNS2.ULTRADNS.NET Comment:    Acme IP Allocation RegDate:    2003-04-08 Updated:    2004-01-23 TechHandle: VO10-ARIN TechName:   HostMaster, Acme TechPhone:  [phone] TechEmail:  [e-mail] OrgAbuseHandle: SECUR13-ARIN OrgAbuseName:   Security Operations OrgAbusePhone:  [phone] OrgAbuseEmail:  [e-mail] OrgNOCHandle: NETWO550-ARIN OrgNOCName:   Network Operations OrgNOCPhone:  [phone] OrgNOCEmail:  [e-mail] OrgTechHandle: VO10-ARIN OrgTechName:   HostMaster, Acme OrgTechPhone:  [phone] OrgTechEmail:  [e-mail] # ARIN WhoIs database, last updated 2005-01-28 19:10 # Enter ? for additional hints on searching ARIN's WhoIs database. root@scanner:$# 

Additionally, conducting the following query will provide any entries for acme in the Whois database to ensure other networks or AS numbers are not assigned to Acme:

 root@scanner:$# whois -H -h whois.arin.net acme Acme, Inc. (AS62550) ACME    62550 Acme, Inc. ACME (NET-2-2-0-0-1) 2.2.0.0 - 2.2.15.255 

Note 

Be sure to review all three registries if you are conducting an assessment on a global organization. The http://whois.arin.net registry only handles North America. For Europe, use http://whois.ripe.net; for Asia-Pacific, use http://whois.apnic.net; for Latin America (Caribbean), use http://whois.lacnic.net; and for Africa, use region http://whois.afrinic.net. Alternatively, more advanced whois clients (such as WhoB, mentioned earlier) may do a lot of this for you. Some servers will do this for you too, such as the GeekTools WhoIs Proxy. See http://www.geektools.com.

Obvious information found from the whois queries include organization name and address, but looking deeper into the information provided, you will see there is a wealth of knowledge gained about the network (and even its maintainers). As simulated attackers, we now have information about the public network range Acme uses (which we already had, so this is a confirmation) and whether or not it is provided by the ISP or assigned directly to Acme from one of the network registries. We now also have various points of contact for the organization. As you can see in the earlier illustration, Acme uses role accounts for contact information. This reduces the possibilities for compromise because a single individual is not responsible for any aspect of the IP assignment. In order for an attacker to attempt a compromise using role accounts, the request would have to slip past whoever is responsible for the role accounts (generally a group on a distribution list) as most changes require e-mail confirmation from owners . This is much more difficult than impersonating a single individual because the attacker must impersonate the role account and it must go undetected by all role account members . If a single individual is listed in any of the contact information, we would only need to convince the registrar that we were in fact that person. What's worse is if an employee leaves the organization and is the sole individual registered, it is very difficult and time consuming to regain control of the registrar records again. If the employee leaves the organization on bad terms, there are very few mechanisms to keep him or her from modifying registrar data (even after leaving your organization) in a deviant manner. The registrar still considers the individual as the trusted contact.

Some other information that may be beneficial to an attacker includes determining whether the address space is "assigned" or "direct assignment." This information can be used to help determine upstream ISPs or routing peers. This information does not guarantee the ISP because some organizations multihome and so on; however, it provides additional information that may come in handy later. Phone numbers found in registrar data can be used in social engineering attacks to further solicit information from administrators themselves . Finally, DNS servers that are authoritative for the network range are identifiable. We can use this information to spawn further information gathering and potential attacks on DNS infrastructure.

Regarding Acme's address space, so far we still have the single address space (CIDR /20) that we identified earlier. The next steps include verifying domain information and attempting to solicit further information through domain interrogation techniques.

A domain registrar contains much of the same information as the IP network registrar but this information is specific to the domains registered by your organization. As with IP address space allocations, domain information can be reviewed with the whois command as well. In the following example, you see some of the whois information available for the acmeexample.com domain. The command used in the example below uses the -h switch to specifically query geektools.com, which in turn checks where the domain is registered and queries that specific whois server.

 root@scanner: $# whois -h whois.geektools.com acmeexample.com GeekTools Whois Proxy v5.0.4 Ready. Whois Server Version 1.3    Domain Name: ACMEEXAMPLE.COM    Registrar: DOTSTER, INC.    Whois Server: whois.dotster.com    Referral URL: http://www.dotster.com    Name Server: UDNS1.ULTRADNS.NET    Name Server: UDNS2.ULTRADNS.NET    Status: ACTIVE    Updated Date: 22-mar-2000    Creation Date: 26-mar-1999    Expiration Date: 22-mar-2005 Registrant:    Domain Registrar    1234 N. First St.    Suite 434    Phoenix, AZ 55512    US    Registrar: DOTSTER    Domain Name: ACMEEXAMPLE.COM       Created on: 26-MAR-99       Expires on: 22-MAR-05       Last Updated on: 12-APR-03    Administrative Contact:       Registrar, Domain [e-mail]       Acme, Inc.       1234 N. First St. Suite 434       Phoenix, AZ 55512       US       602-555-1234    Technical Contact:       Hostmaster, Acme [e-mail]       Acme, Inc.       1234 N. First St. Suite 434       Phoenix, AZ 55512       US       602-555-1234    Domain servers in listed order:       UDNS1.ULTRADNS.NET       UDNS2.ULTRADNS.NET End of Whois Information 

Information about the domain and where it is registered is provided in the above code. The domain acmeexample.com is registered through the Dotster domain registrar and uses two UltraDNS servers as its authoritative DNS servers. Additionally, various points of contact are again provided (similar to the IP network registrar data). As with Acme's IP network assignment, role accounts are used for the various points of contact. The same risks apply to domain registrations as IP network registrations. Not using role accounts increases an organization's risk to registrar attacks and interrogations by attackers.

For users who are not familiar with or do not have access to UNIX systems, the whois command is unfortunately not available natively on Windows. The bright side is that there are several whois utilities publicly available on various Internet web sites. Additionally, the Sam Spade Windows client (http://www.samspade.org) is capable of conducting whois commands in addition to many other commands such as ping, dig, finger, and more. In the illustration below, you can see the same Registrar information found with the whois UNIX command for "acmeexample.com" using Sam Spade. Also, review the menu buttons along the left side of the window for additional commands available in the Sam Spade client.

When we solicited information from Acme administrators, the domain acmeexample.com is the only domain that was provided to us as an active domain. Unfortunately, there are no easy ways to find additional domain names. You may be able to find leads in your registrar interrogations for additional domains (such as mail domains for e-mail addresses, name server domains, and so on) but there are no guarantees these actually belong to your organization (could be hosted). You may also be able to check some other common names (such as acmeexample.net, acmeexample.org, and so on) and attempt to make a determination of whether the registration is by the same organization (same address, contacts, etc.). Unfortunately, whois queries do not exist to search for contacts, addresses, or other registrar data that could possibly be used to cross-reference in search of other domains. But, do not fear; there are still other tools we can use to continue our search for a complete public view of the organization.

Web Searching

From an information-gathering perspective, we now know information about the public address ranges in use at Acme, where domains are registered, what domains are owned (at a minimum, a partial list), some logistic/contact information for the organization, and authoritative DNS servers in use. You might ask how can we find any more out about the organization on the Internet. And just because we know the organization's name, domains, and networks, that doesn't mean we are any closer to finding vulnerabilities.

Welcome to the world of Google and other Internet search engines. Through various search operators and techniques, an attacker may be able to find all he or she will ever need to know about your organization in order to attack it. There are several operators that can be used in queries as well as an entire Google Advanced Search page, which provides very specific and very strategic searches to look for information about an organization. In just a moment, you will see information about all the search queries and operators possible within Google; however, to justify its importance, a quick example here will help show Google's power and how it can be used to solicit information about an organization. The following illustration shows an example search using the site operator to help search for passwords.

As you can see, the search keywords were "username password" and the site operator was used to limit this search query to the .com domain with a filetype of "xls" for a spreadsheet. Effectively, any web documents within the .com domain with the words "username password" pertaining to a spreadsheet file are displayed. The example above shows a mock search, but you'll find this technique useful to find lists of usernames and passwords, IP address allocations (often private/internal lists of this nature), PINs, and scripts containing service account credentials. The point is if real password files were saved inadvertently in web-enabled directories, Google would crawl and subsequently index those password files and they would be included in Internet searches and accessible to anyone . You can even use multiple operators together. Imagine using the filetype: operator to search for "xls" (spreadsheets) in conjunction with keywords such as "budget" or "password" to solicit information about an organization's financials, password files, and so on just as we found the password query above.

More on Google Advanced Search

Now that you understand the power of Google Advanced Search, let's describe it in more detail. The advanced search features of Google can provide useful information about what data are publicly available on the Internet that your organization may or may not be aware of. Any search engine could theoretically be used, but Google has the most in-depth indexes publicly available and provides specific advanced features for searching. The following illustration shows the features available in Google's Advanced Search.

As you can see, with Google Advanced Search, you have the ability to filter searches by words, language file type (including 30+ languages at the time of this writing), occurrences, and domain. Each of these can provide powerful techniques to search for information that organizations may not necessarily want to be public but are stored on misconfigured servers to be just that.

In addition to items provided in the Advanced Search page, Google provides several search operators that allow attackers methods of gathering information about your organization without reviewing page after page of information found in simple searching. You'll find a list of all operators supported by Google at http://www.google.com/help/operators.html. For convenience, the list is also included here.

Tip 

Google's keywords are case sensitivethe first character must be lowercase.

Google Search Operators	Description
cache:http://www.domain.com	Displays the cached page Google has (can also provide keywords to search for within the cached page)
link:http://www.domain.com	Displays all indexed pages containing links to http://www.domain.com
related:http://www.domain.com	Displays pages similar to http://www.domain.com (included in main search page)
info :http://www.domain.com	Displays information Google has stored about http://domain.com (same as typing into search box)
define:keyword or phrase	Displays definitions from various online sources for the keyword or phrase entered
stocks:keyword	Treats keyword as a stock ticker and displays information about the particular stock ticker (keyword) entered
site:website or domain	Search results will only contain findings within the web site or domain entered (included in Advanced Search under "Domains")
allintitle:keyword(s) or phrase	Search results will contain all findings with keyword or the phrase in the title only (included in Advanced Search under "Occurrences")
intitle:keyword and search terms	Search results will contain findings with keyword or phrase in title and search terms within the body of the site(s)
allinurl:keyword(s)	Displays pages that contain all keywords in the URL (also included in Advanced Search under "Occurrences")
inurl:keyword and search terms	Displays pages that contain the keyword in the URL and the search terms in the body of the web page(s)

These operators and advanced search features allow searching with very specific and advanced queries within Google. Just as we used in our first example, searching for .xls file formats on a specific web site/domain may turn up financial information, password lists, or a host of other information not meant to be publicized but commonly stored in Microsoft Excel spreadsheets. Many times this type of find indicates a misconfiguration on a web server. Google crawls any web-enabled directory on systems, and as long as the border security and host firewall allows access on port 80 or 443, Google will index this dataeven if it is meant to be private. Google shows no prejudice. If the data is indexed, it will be displayed if the proper search queries are implemented. Combining advanced features of Google search and various search operators, attackers can find information about your organization (if publicly available) so you must ensure you understand how Google's search works as well. Google can be a great tool for testing what is available publicly from your organization's network.

Google Groups

Google Groups can also be an invaluable information-gathering facility. By searching the target domain name in Google Groups, an attacker can find information about network services, host operating system and application versions, IP addresses, and more. This indirect type of social engineering is a great means for finding information that even port scanners and vulnerability assessment tools are unable to find, simply by searching for network analysts attempting to get help from some of his or her fellow IT professionals within newsgroups on the Web. By now you should be seeing some of the correlations to why various public information security practices should be used. If an individual's name is identified through registrar information, this provides another search perspective in locations such as Google Groups. If using role accounts, the search is more difficult (not impossible , but more difficult).

This brings up a good point about e-mail addresses and web searching. Savvy IT professionals attempting to remain anonymous and not publicize e-mail addresses during web searches (and somewhat because it is just a little cool in an IT sort of way) will display an e-mail address in an obscure format that would make sense to a human but that a web crawler would not identify as an e-mail address. The words are still indexed during the web crawl, but a search for the e-mail address will not show any results. For example: "[e-mail]" may be displayed on a web site as "user (at) acmeexample (dot) com" or "user at acmeexample dot com." A search for " user @acmeexample.com" will show no results in a search; however, searching for some basic mutations (such as "at acmeexample dot com") can help find e-mail addresses (and more importantly, information linked to the e-mail address) that may be beneficial during information gathering or subsequent attacks.

In our Acme vulnerability assessment various online searches were conducted to look for "easy" information and potential misconfigurations that are inappropriately publishing data meant for internal use. Various searches turned up hits, but none that revealed any sensitive data or apparent misconfigurations. Next, Google Groups were checked with a simple search of "acmeexample.com" and several postings came up. After searching through those postings, there was one interesting piece of information (shown in the following illustration).

As you can see, the poster was soliciting assistance with a Postfix implementation/upgrade. This posting could be used to help determine the software running for the organization's e-mail server (whether it's the internal server, external MTA, or both is unknown). It is another piece of data to add to the network topology map that is being built as information is gathered. Besides Postfix, the author also mentions using an "RPM" package that further limits the possible operating system platforms he is using, which we'll keep in mind for targeting.

Note 

Be sure to check dates on postings as older postings could mean the infrastructure has since changed. The information found in Google Groups still needs to be verified but can be used as an additional information source.

Domain Name System (DNS) Tools

Name service is critical to every organization. Without it, services relying on everyday names will not operate properly. You must use various tools to ensure your DNS security is sufficient. Chapter 3 is dedicated to DNS and its security so the points made in this chapter will be somewhat redundant; however, the importance of DNS and the ability to use DNS and find organizational data is certainly worth mentioning twice. Some key points of DNS security include

• Zone enumeration

• Geographic dispersion of name servers to protect against denial of service

• Recursive checks and protection against cache poisoning

Note 

A complete selection of checks that should be conducted regarding DNS is included in Chapter 3.

Commands such as dig, host, nslookup, and dnstracer all provide several opportunities to solicit information about an organization as well as to test whether various security flaws exist in the DNS architecture. Conducting reverse lookups or reverse DNS sweeps on all IP addresses publicly available in your organization can solicit information about specific hosts through its reversed mapped name.

One of the first checks that should be conducted are simple DNS lookups for existing domains we are aware of. For our Acme assessment, you can see the results for acmeexample.com below.

 root@scanner:$# host acmeexample.com acmeexample.com           A       5.125.5.44 

As you can see, acmeexample.com resolves to 5.125.5.44. But waitthis IP address does not belong to any address space we know about so far. At this point, we may have found a new public presence for Acme so we need to go back to our initial information-gathering techniques and conduct those tests for this IP address to determine address space, possible different AS numbers, and maybe even whole new domains to check. Be warned : it may simply be a hosting site, so we must confirm how this IP address fits into the map.

After various checks, it did not appear this IP address was part of a hosting company. Discussions were held with Acme staff and it was determined this IP address along with others is part of a network used by Acme in a data center-hosted environment where redundant systems are maintained to the corporate infrastructure. By continuing our information-gathering techniques through thorough investigation, we have discovered a piece of infrastructure at Acme that would have otherwise not been tested during our vulnerability assessment.

Back to DNS checks . The next DNS check should include zone enumeration testing. The goal is to determine whether the DNS servers authoritative for the domains in question (in this case, acmeexample.com) allow unrestricted zone transfers. This is a great method to gather information about organizational resources. Oftentimes system names are related to the actual services provided by the systems themselves (such as www, mail, dns, or ns). If zone transfers are possible, you will get a complete listing of systems within the zone (domain). You should use the authoritative DNS servers found with your domain registrar interrogations. Also, remember to check all DNS servers listed. While one server may not allow zone enumeration, another may be configured differently (with less stringent access control lists) and may allow enumeration. This often happens when an organization lists one of its internally managed DNS servers and a provider's DNS server(s) for its authoritative servers. One may allow enumeration while the other may not. Also, you should check NS records for the domain to ensure there are no other DNS servers listed as authoritative for the domain. What the registrar has published for authoritative servers does not have to match what is listed in NS records for the domain. If there are additional NS records in the domain, check those servers too!

For the domain acmeexample.com, zone enumeration was not possible; however, for the purpose of demonstration, the domain unsecure.acmeexample.com (configured for displaying this information only) was checked with the dig command as shown here:

 > dig axfr unsecure.acmeexample.com @udns1.ultradns.net ;   DiG 9.2.1   axfr unsecure.acmeexample.com @udns1.ultradns.net ;; global options: printcmd unsecure.acmeexample.com. 14400   IN      SOA     udns1.ultradns.net. hostmaster.acmeexample.com. 2004100604 7200 1200 2592000 14400 unsecure.acmeexample.com. 86400   IN      NS      udns1.ultradns.net. ihopetheydontseethis.unsecure.acmeexample.com. 14400 IN A 10.0.0.4 backupserver.unsecure.acmeexample.com. 14400 IN A 10.0.0.3 stagingenvironment.unsecure.acmeexample.com. 14400 IN A 10.0.0.2 unsecure.acmeexample.com. 14400   IN      A       5.125.5.44 unsecure.acmeexample.com. 86400   IN      NS      udns2.ultradns.net. www.unsecure.acmeexample.com. 300 IN      A       5.125.5.44 www.unsecure.acmeexample.com. 300 IN      A       2.2.0.14 unsecure.acmeexample.com. 14400   IN      MX      20 mail2.acmeexample.com. unsecure.acmeexample.com. 14400   IN      MX      10 maill.acmeexample.com. interestingserver.unsecure.acmeexample.com. 14400 IN A 10.0.0.1 unsecure.acmeexample.com. 14400   IN      SOA     udns1.ultradns.net. hostmaster.acmeexample.com. 2004100604 7200 1200 2592000 14400 ;; Query time: 61 msec ;; SERVER: 204.69.234.1#53 (udns1.ultradns.net) ;; WHEN: Wed Oct 6 12:32:36 2004 ;; XFR size: 14 records 

As you can see, any records included in the unsecure.acmeexample.com domain are enumerated when zone transfers are allowed unrestricted. If this was the domain we were conducting assessments on, we would have a wealth of information.

The dig utility can also be used to find NS, SOA, and MX records (as well as others) for a domain. For the acmeexample.com domain, this is especially useful since zone enumeration was not possible.

 > dig mx acmeexample.com ;   DiG 9.2.1   mx acmeexample.com ;; global options: printcmd ;; Got answer: ;; -   HEADER   - opcode: QUERY, status: NOERROR, id: 55520 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;acmeexample.com.                IN      MX ;; ANSWER SECTION: acmeexample.com. 14400    IN      MX 20 maill.acmeexample.com. acmeexample.com. 14400    IN      MX 10 mail2.acmeexample.com. ;; Query time: 30 msec ;; SERVER: 204.69.234.254#53 (204.69.234.254) ;; WHEN: Wed Oct 6 12:37:37 2004 ;; MSG SIZE rcvd: 110 

We now know that Acme has mx records to two different e-mail servers. These can now be added to our map that we are creating for our assessment.

Note 

The host command (host -t mx acmeexample.com) or nslookup (setting querytype = mx) can also be used to find the information above.

When conducting your vulnerability assessments, you can continue past the information-gathering stage at this point and conduct additional DNS security checks or you can wait to conduct these checks at a later time in the assessment when actually conducting attacks. The choice lies with you and how you will conduct the assessment. We prefer to get all DNS-related work done at this time as long as we are interrogating DNS systems for information already anyway. Others prefer to stick to a strict regimen of information gathering, mapping, qualifying, and then conducting all attacks. Whatever the case, the important thing to remember is that findings must be captured and documented.

Other security-related DNS testing should be conducted at some point during the assessment. To avoid complete repetition, the details on what to check for and how can be found in Chapter 3, but for convenience, the following list includes system checks that should be completed:

• Run dnstracer. This will allow you to see DNS delegation and determine if any problems exist from the root servers to the authoritative servers for each domain. (Remember to run dnstracer for each domain in your organization.)

• Check for role accounts at registrars. As explained earlier, role accounts should be used for registrar contact information.

• Use dig to check for version information, whether TCP-based queries are allowed (even if UDP is not), etc. Administrators may block UDP-based traffic with firewalls and packet filters but leave TCP open to allow zone transfers to "approved" DNS servers. Additional information may be garnished by using the appropriate options with the dig utility.

• Run various DNS security checks. These checks include DNS cache poisoning, remote shell possibilities due to weaknesses in firewall and packet filter rules, etc.

• Run recursive checks. Determine whether recursion is allowed and whether it is necessary or limited (for example, ISP DNS servers being limited to customers only, etc.).

As previously stated, details on conducting these checks are included in Chapter 3.