Using tools such as nslookup, host, and dig, you can launch DNS requests and probes against domains and IP address blocks identified during the web search and NIC querying phases. Other tools also perform reverse DNS sweeps against IP network blocks to identify hostnames and other domains.
DNS requests and probes can be launched to retrieve parts of, or in some cases, entire DNS zone files for specified domains or network spaces. Most DNS servers around the Internet can be quizzed for useful information, including:
Authoritative DNS server information from name server (NS) records
Domain and subdomain information
Hostname information from A, PTR, and CNAME records
Public points of presence that list mail exchanger (MX) records
In some cases, poorly configured DNS servers also allow you to enumerate:
Operating-system and platform information of hosts from the host information (HINFO) record
Names and IP addresses of internal or nonpublic hosts and networks
You can very often uncover previously unknown network blocks and hosts during DNS querying. If new network blocks are found, I recommend launching a second round of WHOIS queries and web searches to get further information about each new network block.
DNS probing in this fashion is stealthy in the sense that there is no active scanning or probing of the target networks. Instead, you simply probe and query the authoritative DNS servers for those domains or network blocks that are often run by ISPs. Most name servers aren't even configured to pick up on potential sweeps of this sort, because it resembles standard DNS traffic.
Forward DNS records are required for organizations and companies to integrate and work correctly as part of the Internet. Two examples of legitimate forward queries are when an end user accesses a web site and during the receipt of email when SMTP mail exchanger information is requested about the relevant domain. Attackers issue forward DNS queries to identify mail servers and other obvious Internet-based systems.
Tools that query DNS servers directly include:
The Sam Spade Windows client (available from http://www.samspade.org)
The nslookup client found within most operating systems
The host client found within Unix environments
The dig client found within Unix environments
Using the nslookup tool in an interactive fashion (from either a Windows or Unix-based command prompt) I can identify the mail exchanger IP addresses and hostnames for the Central Intelligence Agency (CIA) domain at cia.gov, as shown in Example 3-3. Note that ucia.gov is used as the real domain name for the CIA's network space.
# nslookup Default Server: onyx Address: 192.168.0.1 > set querytype=any > cia.gov Server: onyx Address: 192.168.0.1 Non-authoritative answer: cia.gov origin = ucia.gov mail addr = root.ucia.gov serial = 21432040 refresh = 900 (15M) retry = 3600 (1H) expire = 86400 (1D) minimum ttl = 900 (15M) cia.gov nameserver = relay1.ucia.gov cia.gov nameserver = auth00.ns.uu.net cia.gov preference = 5, mail exchanger = relay2.ucia.gov Authoritative answers can be found from: cia.gov nameserver = relay1.ucia.gov cia.gov nameserver = auth00.ns.uu.net relay1.ucia.gov internet address = 18.104.22.168 auth00.ns.uu.net internet address = 22.214.171.124 relay2.ucia.gov internet address = 126.96.36.199
Mail exchanger (MX) address details are very useful to attackers because such mail servers often reside on the corporate network boundary between the Internet and internal network space. By scanning these systems, attackers can often identify other gateways and systems that aren't secure.
The Unix host command can easily identify the mail exchanger for the cia.gov domain:
# host cia.gov cia.gov mail is handled (pri=5) by relay2.ucia.gov
Other arguments can be provided to the host command to pull specific DNS information (type man host to access its manpage).
The Unix-based dig command is extremely powerful with plenty of options and functionality. Example 3-4 shows the basic accessible DNS information for the cia.gov domain.
# dig cia.gov any ; <<>> DiG 8.3 <<>> cia.gov any ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 2, ADDITIONAL: 3 ;; QUERY SECTION: ;; cia.gov, type = ANY, class = IN ;; ANSWER SECTION: cia.gov. 13m47s IN SOA ucia.gov. root.ucia.gov. ( 21432040 ; serial 15M ; refresh 1H ; retry 1D ; expiry 15M ) ; minimum cia.gov. 13m47s IN NS relay1.ucia.gov. cia.gov. 13m47s IN NS auth00.ns.uu.net. cia.gov. 13m47s IN MX 5 relay2.ucia.gov. ;; AUTHORITY SECTION: cia.gov. 13m47s IN NS relay1.ucia.gov. cia.gov. 13m47s IN NS auth00.ns.uu.net. ;; ADDITIONAL SECTION: relay1.ucia.gov. 23h58m47s IN A 188.8.131.52 auth00.ns.uu.net. 8h31m27s IN A 184.108.40.206 relay2.ucia.gov. 13m48s IN A 220.127.116.11 ;; Total query time: 10 msec ;; MSG SIZE sent: 25 rcvd: 221
In the overall scheme of things, dig has superseded the nslookup and host commands, allowing users to launch and analyze responses to almost raw DNS queries.
The initial forward DNS queries against cia.gov identify the authoritative DNS servers as relay1.ucia.gov and auth100.ns.uu.net, and the mail exchanger for the domain as relay2.ucia.gov. The IP address details of these hosts can then be queried using the WHOIS web interface at ARIN, which reveals that the CIA has reserved the 18.104.22.168-22.214.171.124 IP address network block.
Perhaps the most popular method for gathering information about all the computers within a DNS domain is to request a zone transfer. A DNS zone file contains all the naming information that the name server stores regarding a specific DNS domain, often including details of nonpublic internal networks and other useful information you can use to build an accurate map of the target infrastructure.
Most organizations, for load balancing and fault tolerance reasons, use more than one name server. The main name server is known as the primary name server and all subsequent name servers are secondary name servers. Either a primary or secondary name server can be queried for name resolution, so it is important that each name server have current DNS zone information. To ensure this is the case, when a secondary name server is started and at regular, specifiable intervals thereafter, it requests a complete listing of the computers it is responsible for from the primary name server. The process of requesting and receiving this information is a zone transfer.
Tools used to request DNS zone transfer information include:
The Sam Spade Windows client (available from http://www.samspade.org)
The nslookup client found within most operating systems
The host client found within Unix-based environments
The dig client found within Unix-based environments
When used in an interactive fashion, the nslookup command can perform a DNS zone transfer against a given domain by connecting to an authoritative name server. In some cases, nonauthoritative name servers can be queried in this fashion, so they are always worth looking for. Example 3-5 shows how nslookup can be run to identify the authoritative name servers for the ucia.gov domain.
# nslookup Default Server: onyx Address: 192.168.0.1 > set querytype=any > ucia.gov Server: onyx Address: 192.168.0.1 Non-authoritative answer: ucia.gov preference = 10, mail exchanger = puff.ucia.gov ucia.gov preference = 5, mail exchanger = relay2.ucia.gov ucia.gov origin = ucia.gov mail addr = root.ucia.gov serial = 21642034 refresh = 900 (15M) retry = 3600 (1H) expire = 86400 (1D) minimum ttl = 900 (15M) Authoritative answers can be found from: ucia.gov nameserver = RELAY1.ucia.gov ucia.gov nameserver = AUTH100.NS.UU.NET puff.ucia.gov internet address = 126.96.36.199 relay2.ucia.gov internet address = 188.8.131.52 RELAY1.ucia.gov internet address = 184.108.40.206 AUTH100.NS.UU.NET internet address = 220.127.116.11
Initial DNS records (details of mail servers for the domain and other information) and addresses of authoritative DNS servers are supplied. Example 3-6 walks through the zone transfer process against the CIA, connecting directly to auth100.ns.uu.net and issuing the ls -d ucia.gov command.
> server auth100.ns.uu.net Default Server: auth100.ns.uu.net Address: 18.104.22.168 > ls -d ucia.gov [auth100.ns.uu.net] $ORIGIN ucia.gov. @ 15M IN SOA @ root ( 21642034 ; serial 15M ; refresh 1H ; retry 1D ; expiry 15M ) ; minimum 15M IN NS relay1 15M IN NS auth00.ns.uu.net. 15M IN NS puff 15M IN NS magic.cia.gov. 15M IN MX 10 puff 15M IN MX 5 relay2 ain-relay1 15M IN CNAME relay1 loghost 15M IN CNAME localhost ain-relay2 15M IN CNAME relay2 localhost 15M IN A 127.0.0.1 * 15M IN MX 10 puff ain-relay1-ext 15M IN CNAME relay1 iron 15M IN NS relay1 15M IN NS auth00.ns.uu.net. relay4-ext 15M IN CNAME relay4 relay4-hme0 15M IN CNAME relay4 ex-rtr-191-a 15M IN A 22.214.171.124 ex-rtr-191-b 15M IN A 126.96.36.199 relay 15M IN CNAME relay1 relay2-int 15M IN CNAME ain-relay2-le1 relay2-hme0 15M IN CNAME relay2 relay1-hme0 15M IN CNAME relay1 multicast 15M IN A 188.8.131.52 foia 15M IN NS relay1 15M IN NS auth00.ns.uu.net. amino 15M IN NS relay1 15M IN NS auth00.ns.uu.net. ain-relay2-ext 15M IN CNAME relay2 relay1-ext 15M IN CNAME relay1 ain-relay4-int 15M IN CNAME ain-relay4-hme1 net 15M IN NS relay1 15M IN NS auth00.ns.uu.net. tonic 15M IN NS relay1 15M IN NS auth00.ns.uu.net. ex-rtr 15M IN CNAME ex-rtr-129 bh-ext-hub 15M IN A 184.108.40.206 wais 15M IN CNAME relay2 lemur 15M IN NS relay1 15M IN NS auth00.ns.uu.net. ain-relay4-hme0 15M IN CNAME relay4 relay2-ext 15M IN CNAME relay2 ain-relay4-hme1 15M IN A 220.127.116.11 ain-relay2-hme0 15M IN CNAME relay2 ain-relay1-int 15M IN CNAME ain-relay1-le1 ain-relay2-hme1 15M IN A 192.168.64.3 ain-relay1-hme0 15M IN CNAME relay1 ain-relay1-hme1 15M IN A 192.168.64.2 relay4-int 15M IN CNAME ain-relay4-hme1 relay1 15M IN A 18.104.22.168 relay2 15M IN A 22.214.171.124 relay4 15M IN A 126.96.36.199 iodine 15M IN NS relay1 15M IN NS auth00.ns.uu.net. ain-relay-int 15M IN CNAME ain-relay1-le1 relay-int 15M IN CNAME ain-relay1-le1 puff 15M IN A 188.8.131.52 ain-relay4-ext 15M IN CNAME relay4 ex-rtr-129 15M IN HINFO "Cisco 4000 Router" 15M IN A 184.108.40.206 loopback 15M IN CNAME localhost ain-relay2-int 15M IN CNAME ain-relay2-le1 relay1-int 15M IN CNAME ain-relay1-le1
Interesting security-related information that can be derived from the CIA's large DNS zone file includes:
The CIA relay mail and DNS servers are probably running Solaris, due to the naming convention of using hme within the hostnames (hme devices are network interfaces within Solaris).
iron.ucia.gov, foia.ucia.gov, amino.ucia.gov, net.ucia.gov, tonic.ucia.gov, and lemur.ucia.gov are all valid subdomains of ucia.gov.
The ain-relay servers seem to be dual-homed, also existing internally at 192.168.64.2 and 192.168.64.3.
An HINFO record exists for ex-rtr-129, telling us it is a Cisco 4000 series router.
The following CIA IP address blocks are identified:
172.31.253.0 (nonpublic reserved IANA address space)
192.168.64.0 (nonpublic reserved IANA address space)
The Unix host utility can be run in a noninteractive fashion from the command line to retrieve the same DNS zone file information by using the following flags:
# host -l -t any ucia.gov
dig is another tool used to retrieve DNS zone information; it's run with the following options to perform a DNS zone transfer of ucia.gov from auth100.ns.uu.net:
# dig @auth100.ns.uu.net ucia.gov axfr
After performing a DNS zone transfer, subdomains are identified. Using the host command (available under most Unix-based systems), you can transfer DNS zone information from authoritative name servers without using nslookup in an interactive fashion.
Example 3-7 uses the host command to enumerate address (A) records for the CIA's net.ucia.gov subdomain.
# host -l -t a net.ucia.gov net.ucia.gov name server auth100.ns.uu.net auth100.ns.uu.net has address 220.127.116.11 net.ucia.gov name server relay1.ucia.gov relay1.ucia.gov has address 18.104.22.168 dialbox0.net.ucia.gov has address 22.214.171.124
By recursively querying the CIA's authoritative name servers, it is possible to identify a number of Internet-based points of presence, including an apparent dial-up server (dialbox0.net.ucia.gov) on a previously unknown IP range of 126.96.36.199. In this particular case, I use the -t a argument, which displays all known address and name server records, but not host information (HINFO) records. To list all records, simply use the -t any argument.
It is often the case that large organizations, such as the CIA, return copious amounts of DNS zone information (including the names of subdomains, key servers, and development hosts). Companies that are aware of DNS security issues don't allow DNS zone transfers; for example:
# host -l ibm.com Server failed: Query refused
After building a list of IP network blocks used or reserved by the target organization, reverse DNS sweeping can gather details of hosts that may be protected or filtered but still have DNS hostnames assigned to them.
ghba is a freely available tool that performs reverse DNS sweeping of target IP network space. You can find it at http://www.attrition.org/tools/other/ghba.c.
Example 3-8 shows the ghba utility being downloaded, built, and run against a CIA network block to identify hosts.
# wget http://www.attrition.org/tools/other/ghba.c # ls ghba.c # cc -o ghba ghba.c ghba.c: In function 'main': ghba.c:105: warning: return type of 'main' is not 'int' # ls ghba ghba.c # ./ghba usage: ghba [-x] [-a] [-f <outfile>] aaa.bbb.[ccc||0].[ddd||0] # ./ghba 188.8.131.52 Scanning Class C network 198.81.129... 184.108.40.206 => www.odci.gov 220.127.116.11 => www2.cia.gov 18.104.22.168 => ain-relay4-hme1.ucia.gov 22.214.171.124 => relay1.ucia.gov 126.96.36.199 => relay2.ucia.gov 188.8.131.52 => relay4.ucia.gov 184.108.40.206 => ex-rtr-129.ucia.gov 220.127.116.11 => res.odci.gov
As well as identifying already known CIA web and mail relay servers, ghba identifies various other hosts, including res.odci.gov and www.odci.gov. Reverse DNS sweeping is a useful technique that can identify hosts and potential weaknesses within Internet-based points of presence because it reveals hosts and networks that may not be revealed during DNS zone transfer queries.
SMTP gateways and networks of mail relay servers must exist for organizations and companies to send and receive Internet email messages. Simply sending an email message to an address known not to exist at a target domain, often reveals useful internal network information. Example 3-9 shows how email sent to a user account that doesn't exist within the ucia.gov domain bounces to reveal useful internal network information.
The original message was received at Fri, 1 Mar 2002 07:42:48 -0500 from ain-relay2.net.ucia.gov [192.168.64.3] ----- The following addresses had permanent fatal errors ----- <firstname.lastname@example.org> ----- Transcript of session follows ----- ... while talking to mailhub.ucia.gov: >>> RCPT To:<email@example.com> <<< 550 5.1.1 <firstname.lastname@example.org>... User unknown 550 <email@example.com>... User unknown ----- Original message follows ----- Return-Path: <firstname.lastname@example.org> Received: from relay2.net.ucia.gov by puff.ucia.gov (8.8.8+Sun/ucia internal v1.35) with SMTP id HAA29202; Fri, 1 Mar 2002 07:42:48 -0500 (EST) Received: by relay2.net.ucia.gov; Fri, 1 Mar 2002 07:39:18 Received: from 18.104.22.168 by relay2.net.ucia.gov via smap (4.1) id xma026449; Fri, 1 Mar 02 07:38:55 -0500
In particular, the following data in this transcript is useful:
The Internet-based relay2.ucia.gov gateway has an internal IP address of 192.168.64.3 and an internal DNS name of relay2.net.ucia.gov.
relay2.ucia.gov is running TIS Gauntlet 4.1, an application firewall (smap 4.1, which is a component of TIS Gauntlet, is mentioned in the via field).
puff.ucia.gov is an internal SMTP mail relay system running Sun Sendmail 8.8.8.
mailhub.ucia.gov is another internal mail relay running Sendmail (this can be seen from analyzing the SMTP server responses to the RCPT TO: command).
In the overall scheme of things, SMTP probing should appear later in the book because it is technically an intrusive technique that involves transmitting data to the target network and analyzing responses. I mention probing here because when users post email to Internet mailing lists, SMTP routing information is often attached in the headers of the email message. It is very easy for a potential attacker to then perform an open and passive web search for mail messages originating from the target's network space to collect SMTP routing information.