3.3 DNS Querying | Network Security Assessment: Know Your Network

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.

3.3.1 Forward DNS Querying

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

3.3.1.1 Forward DNS querying through nslookup

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.

Example 3-3. Using nslookup to enumerate basic domain details

# 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 = 198.81.129.193 auth00.ns.uu.net        internet address = 198.6.1.65 relay2.ucia.gov internet address = 198.81.129.194

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.

3.3.1.2 Forward DNS querying through host

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).

3.3.1.3 Forward DNS querying through dig

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.

Example 3-4. Using dig to enumerate basic domain details

# 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  198.81.129.193 auth00.ns.uu.net.       8h31m27s IN A   198.6.1.65 relay2.ucia.gov.        13m48s IN A     198.81.129.194 ;; 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.

3.3.1.4 Information retrieved through forward DNS querying

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 198.81.129.0-198.81.129.255 IP address network block.

3.3.2 DNS Zone Transfer Techniques

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

3.3.2.1 Performing DNS zone transfers with nslookup

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.

Example 3-5. Using nslookup to glean authoritative DNS server details

# 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 = 198.81.128.66 relay2.ucia.gov internet address = 198.81.129.194 RELAY1.ucia.gov internet address = 198.81.129.193 AUTH100.NS.UU.NET       internet address = 198.6.1.202

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.

Example 3-6. Interactively using nslookup to perform a zone transfer

> server auth100.ns.uu.net Default Server:  auth100.ns.uu.net Address:  198.6.1.202 > 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        192.103.66.58 ex-rtr-191-b            15M IN A        192.103.66.62 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        224.0.0.1 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        198.81.129.195 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        198.81.129.163 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        198.81.129.193 relay2                  15M IN A        198.81.129.194 relay4                  15M IN A        198.81.129.195 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        198.81.128.66 ain-relay4-ext          15M IN CNAME    relay4 ex-rtr-129              15M IN HINFO    "Cisco 4000 Router"                         15M IN A        198.81.129.222 loopback                15M IN CNAME    localhost ain-relay2-int          15M IN CNAME    ain-relay2-le1 relay1-int              15M IN CNAME    ain-relay1-le1

3.3.2.2 Information retrieved through DNS zone transfer

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:
198.81.128.0 (Internet-based)
198.81.129.0 (Internet-based)
172.31.253.0 (nonpublic reserved IANA address space)
192.168.64.0 (nonpublic reserved IANA address space)

3.3.2.3 Performing DNS zone transfers using host and dig

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

3.3.2.4 Further querying

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.

3.3.2.5 Mapping subdomains with host

Example 3-7 uses the host command to enumerate address (A) records for the CIA's net.ucia.gov subdomain.

Example 3-7. Using host to identify addresses under net.ucia.gov

# host -l -t a net.ucia.gov net.ucia.gov name server auth100.ns.uu.net auth100.ns.uu.net has address 198.6.1.202 net.ucia.gov name server relay1.ucia.gov relay1.ucia.gov has address 198.81.129.193 dialbox0.net.ucia.gov has address 198.81.189.3

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 198.81.189.0. 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.

3.3.2.6 Example of a DNS zone transfer refusal

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

3.3.3 Reverse DNS Sweeping

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.

Example 3-8. Using ghba to perform a reverse DNS sweep

# 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 198.81.129.0 Scanning Class C network 198.81.129... 198.81.129.100 => www.odci.gov 198.81.129.101 => www2.cia.gov 198.81.129.163 => ain-relay4-hme1.ucia.gov 198.81.129.193 => relay1.ucia.gov 198.81.129.194 => relay2.ucia.gov 198.81.129.195 => relay4.ucia.gov 198.81.129.222 => ex-rtr-129.ucia.gov 198.81.129.230 => 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.

3.3.4 SMTP Probing

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.

Example 3-9. A nondeliverable mail transcript from the CIA

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 ----- <blahblah@ucia.gov>    ----- Transcript of session follows ----- ... while talking to mailhub.ucia.gov: >>> RCPT To:<blahblah@ucia.gov> <<< 550 5.1.1 <blahblah@ucia.gov>... User unknown 550 <blahblah@ucia.gov>... User unknown    ----- Original message follows ----- Return-Path: <hacker@hotmail.com> 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 212.84.12.106 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.