Exposing Weaknesses

There are a variety of attack vectors in which skilled attackers manipulate the world's most distributed directory system in order to adversely affect your infrastructure. Your systems may be compromised

• By researching and/or modifying the records you have on file at your domain or IP network registrar

• By performing a distributed denial-of-service attack on the global DNS infrastructure itself (ruining the network for everyone)

• By externally influencing your internal, recursive name servers

• By taking advantage of relaxed packet filter policies designed to make DNS easier for everyone, thereby allowing tunneling in/out of your organization

• By using esoteric features of DNS to transfer data into/out of your organization

The most natural segregation of these weaknesses is to divide them into (1) the global system that comprises DNS beginning with the DNS root servers themselves , and (2) every organization's specific implementation of DNS infrastructure to include both public- facing and internal systems. Understanding the DNS' overall architecture from the previous section should have already prompted the more considerate of us to wonder about the integrity and reliability of the overall system.

The Global DNS Root Infrastructure

The simplest form of attack using the global infrastructure (as opposed to attacking the target directly) is by misinforming the target's domain or IP registrar with regard to certain critical elements of information used to delegate DNS- related information. Some time ago, it was common practice for miscreants to modify your domain records stored at various registrars to reflect different name servers, different contact information, and so on. Today it seems funny to believe that this used to be possible without even e-mail or other confirmation. Literally, if you knew a contact name responsible for a domain, you could simply spoof an e-mail message to the registrar hostmaster (e-mail self-service software, [e-mail] as an example) from the contact in question and have a modification performed on the domain itself, effectively giving another entity control over it. Today, this has been locked down in most registrar environments, but the use of weak passwords or other simple authentication mechanisms still put an exploit in the news now and then. Another item worth mentioning is a recent policy change by the ever-evolving Internet Corporation for Assigned Names and Numbers (ICANN). This change has created a new frightening threat for many organizations, which is the requirement of all registrars to transfer domains when they receive a properly formatted request. This means that the security of your domain at the critical registrar level is only as secure as the weakest registrar accredited to provide such services. However, another safety mechanism that became available recently is an additional attribute/feature that may be applied to existing domains through your registrar that will cause the registrar to deny all registrar transfer requests (even those that are legitimately requested by the domain owner) until the attribute is removed. This is known as the "registrar-lock" attribute and we recommend organizations use it once they're comfortable with the trustworthiness of their registrar. As of this writing, however, only a few registrars support the registrar-lock feature. While on the topic of registrars, when checking to make sure your domains are in registrar-lock status, we suggest making sure your contact information on file at your registrar reflects role-based contacts as opposed to individual contact information (for example, [e-mail] as opposed to [e-mail]). Role-based accounts preserve your organization's communication capabilities with the registrar between management and personnel changesa misstep we've seen far too often.

Most miscreants today use various registrar and DNS-related tools in order to perform footprinting of their targets. Footprinting is essentially a method of profiling an Internet target by looking up various public information that reveals server locations, contacts, network addresses, and so on. Whois services provide a window onto registrar records and are usually the first form of footprinting. The most practical web-based whois client available can be found at http://www.geektools.com. We prefer the GeekTools whois software (developed by Robb Ballard and provided free of charge by CenterGate Research) because it automatically queries the appropriate domain and/or network registrar depending on the exact query you're performing. It can be used online at the GeekTools web site, as a whois lookup server within your favorite whois software utility, or downloaded and used locally. Following are some examples of the GeekTools whois proxy depicting usage from a standard whois client on a UNIX-based server.

Using GeekTools Whois Proxy to Look Up an Address/Block

 > whois -h whois.geektools.com 4.2.2.1 connecting to whois.geektools.com [206.117.161.84:43]... GeekTools Whois Proxy v5.0.4 Ready. Final results obtained from whois.arin.net. Results: OrgName:    Level 3 Communications, Inc. OrgID:      LVLT Address:    1025 Eldorado Blvd. City:       Broomfield StateProv:  CO PostalCode: 80021 Country:    US NetRange:   4.0.0.0 - 4.255.255.255 CIDR:       4.0.0.0/8 NetName:    LVLT-ORG-4-8 NetHandle:  NET-4-0-0-0-1 Parent: NetType:    Direct Allocation NameServer: NS1.LEVEL3.NET NameServer: NS2.LEVEL3.NET Comment: RegDate: Updated:    2004-06-04 OrgAbuseHandle: APL8-ARIN OrgAbuseName:   Abuse POC LVLT OrgAbusePhone: [phone] OrgAbuseEmail: [e-mail] OrgTechHandle: TPL1-ARIN OrgTechName:   Tech POC LVLT OrgTechPhone:  [phone] OrgTechEmail:  [e-mail] OrgTechHandle: ARINC4-ARIN OrgTechName:   ARIN Contact OrgTechPhone:  [phone] OrgTechEmail:  [e-mail] Results brought to you by the GeekTools WHOIS Proxy Server results may be copyrighted and are used with permission. 

Using GeekTools Whois Proxy to Look Up a Domain

 > whois -h whois.geektools.com vostrom.com GeekTools Whois Proxy v5.0.4 Ready. Checking access for 69.16.147.206... ok. Checking server [whois.crsnic.net] Checking server [whois.godaddy.com] Results: Registrant:    Domain Registrar    5025 N. Central Ave. #410    Phoenix, Arizona 85012    United States    Registered through: GoDaddy.com    Domain Name: VOSTROM.COM       Created on: 12-Nov-04       Expires on: 12-Nov-06       Last Updated on: 15-Feb-05    Administrative Contact:       Registrar, Domain [e-mail]       5025 N. Central Ave. #410       Phoenix, Arizona 85012       United States       888-569-6107    Technical Contact:       Registrar, Domain [e-mail]       5025 N. Central Ave. #410       Phoenix, Arizona 85012       United States       888-569-6107    Domain servers in listed order:       UDNS1.ULTRADNS.NET       UDNS2.ULTRADNS.NET 

Note 

Depending on your platform and whois software client, you may direct traffic to another whois server by using the command line argument "-h whoisserver.domain.tld" or by using "@whiosserver.domain.tld."

Of course, this walking of registrars can be performed manually by first querying the CRSNIC whois server to identify the appropriate registrar and then by querying the next registrar (similar to walking the DNS hierarchy described earlier). This is evidenced below:

 > whois -h whois.crsnic.net vostrom.com Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information.    Domain Name: VOSTROM.COM    Registrar: GO DADDY SOFTWARE, INC.    Whois Server: whois.godaddy.com    Referral URL: http://registrar.godaddy.com    Name Server: UDNS1.ULTRADNS.NET    Name Server: UDNS2.ULTRADNS.NET    Status: REGISTRAR-LOCK    Updated Date: 16-feb-2005    Creation Date: 12-nov-2004    Expiration Date: 12-nov-2006 > whois -h whois.godaddy.com vostrom.com Registrant:    Domain Registrar    5025 N. Central Ave. #410    Phoenix, Arizona 85012    United States    Registered through: GoDaddy.com    Domain Name: VOSTROM.COM       Created on: 12-Nov-04       Expires on: 12-Nov-06       Last Updated on: 15-Feb-05    Administrative Contact:       Registrar, Domain [e-mail]       5025 N. Central Ave. #410       Phoenix, Arizona 85012       United States       888-569-6107    Technical Contact:       Registrar, Domain [e-mail]       5025 N. Central Ave. #410       Phoenix, Arizona 85012       United States       888-569-6107    Domain servers in listed order:       UDNS1.ULTRADNS.NET       UDNS2.ULTRADNS.NET End of Whois Information 

It should be mentioned that there are several command line whois clients that embed many of the GeekTools-type features and effectively automate this process in the same way. One example is Bill Weinman's whois client located at http://whois.bw.org/.

Attack on the Root

The most extreme method of attack using the global DNS infrastructure is an attack on the root or TLD servers themselves. These servers experience heavy loads because they are customarily the starting points for DNS clients (applications) when resolving host names. A typical root DNS server answers between 5,000 and 10,000 queries per second and these figures increase linearly with the increase of registered domain names.

Despite the fact that it is the "wrong thing to do," miscreants attack the root quite regularly. The root servers are so tightly held and closely monitored that the most common form of attack on the root is a distributed denial-of-service attack against any or all of the 13 IP addresses comprising the root network {A-M}.ROOT-SERVERS.NET or on the TLD servers for each ccTLD or gTLD. Most root and TLD server operators traditionally used RFC 2870 (Root Name Server Operational Requirements) as a basis for their defense posture , but now even more sophisticated and esoteric means of defense are used to protect this critical infrastructure. Not the least esoteric of these is a little- understood mechanism called "anycast." The term anycast describes packets being sent between a single source and the nearest (in terms of network topology) of several possible destinations in a group , all having the same IP address. This is different from multicast (packets between a single source and multiple, unique destinations) and unicast (packets between a single source and a single destination). Anycast addresses are regular unicast IP addresses and are not syntactically distinguishable from any other unicast addresses. Therefore, any IP address may be an anycast address. It should be mentioned, however, that in IPv6, specific network addresses have been reserved for anycast use as described in RFC 2373 (IP version 6 Addressing Architecture). A more detailed explanation of anycast can be found later in this book, including details on how to use anycast to improve and secure your own Internet infrastructure. Anycast allows root server operators (and various other critical or performance-related IP-based service providers) to geographically distribute requests to any given IP address for redundancy, effectively distribute traffic/requests to any given IP address globally, and increase responsiveness of the overall system by using the closest (in terms of network topology) available resource to answer the request. One of the best-known implementations of this anycast technique is that of Paul Vixie and the Internet Software Consortium, who have maintained F.ROOT-SERVERS.NET since 1994. More information on their infrastructure and their specific implementation of anycast to distribute load across what are currently 26 unique servers may be found at http://www.isc.org/. Suffice it to say that through the use of anycast traffic distribution and by following other general security and operational guidelines, the root infrastructure is well defended.

However, we must consider that the nature of the DNS protocol as it exists today is connectionless and unauthenticated. Therefore, conceivably, enough traffic could be generated to the roots and to the TLD serversmerely in legitimate requeststo completely disrupt the global DNS infrastructure. Keep in mind that because the requests are currently connectionless and unauthenticated, the root servers have no way of distinguishing which requests are "real" and which are "fake" traffic generated as a DDoS.

DNSSEC (short for DNS security extensions) was designed to protect the Internet from certain types of attacks. DNSSEC (see RFC 2535, Domain Name System Security Extensions) provides for authenticity and integrity verification, but so far, it has met with industry resistance because it requires such a large-scale set of changes globally and in software everywhere. In order to benefit from DNSSEC, a long-term transition plan will undoubtedly need to be accepted by global name service authorities and much work will need to be accomplished by software vendors and telecommunications carriers worldwide. BIND 9, the predominant software involved with powering DNS servers globally, already supports DNSSEC and has since 1999. However, this support is based on support for RFC 2535 specifically , and offers no additional protection (against DNS forgery) without the above-mentioned global changes.

Several other ideas for improving overall DNS reliability are also in the works, including what is effectively an out-of- band network from major ISP to major ISP to provide for guaranteed delivery of DNS-related information even in the event of a global attack through logically or physically segmenting DNS operations. Some hybrid of these approaches will likely be implemented over the next 24 months. More information on DNSSEC may be found at http://www.dnssec.net/.

Tip 

Dan Bernstein provides what we believe is the most detailed and easily understandable explanation of the shortcomings of the global DNS infrastructure and the protocols themselves on his web site at http://cr.yp.to.

Your Organization's DNS Infrastructure

The primary attack vectors affecting an organization's DNS infrastructure are information gathering (in order to map out targets in the target network), redirecting traffic by way of DNS record or cache modification, taking advantage of relaxed packet filters for tunneling purposes, or most recently, providing a means of remote command and control to disseminate orders to preplanted Trojan programs commensurate with botnet activity.

Information gathering is covered more thoroughly later in this book, but some examples include using DNS-related tools such as ˜dnstracer (covered earlier in this chapter), ˜DIG (the domain information groper), ˜nslookup, and ˜host in order to get more information about a target network.

Finding Out the Name (DNS) Servers for a Given Target Network

The easiest way to discover the name servers for a given network is to query the common registrar server for the domain name of the organization you're researching:

 > whois -h whois.crsnic.net vostrom.com Whois Server Version 1.3 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information.    Domain Name: VOSTROM.COM    Registrar: GO DADDY SOFTWARE, INC.    Whois Server: whois.godaddy.com    Referral URL: http://registrar.godaddy.com    Name Server: UDNS1.ULTRADNS.NET    Name Server: UDNS2.ULTRADNS.NET    Status: REGISTRAR-LOCK    Updated Date: 16-feb-2005    Creation Date: 12-nov-2004    Expiration Date: 12-nov-2006 

Now that we've found that UDNS1.ULTRADNS.NET and UDNS2.ULTRADNS.NET are the authoritative name servers for the vostrom.com domain, we can interrogate those servers, asking for a listing of all records in the vostrom.com zone (a "zone transfer").

 > dig axfr unsecure.vostrom.com @udns1.ultradns.net ;   DiG 9.2.1   axfr unsecure.vostrom.com @udns1.ultradns.net ; ; global options: printcmd unsecure.vostrom.com. 14400     IN     SOA     udns1.ultradns.net. hostmaster.vostrom.com. 2004100604 7200 1200 2592000 14400 unsecure.vostrom.com. 86400     IN     NS      udns1.ultradns.net. ihopetheydontseethis.unsecure.vostrom.com. 14400 IN A 10.0.0.4 backupserver.unsecure.vostrom.com. 14400 IN A 10.0.0.3 stagingenvironment.unsecure.vostrom.com. 14400 IN A 10.0.0.2 unsecure.vostrom.com. 14400     IN     A       204.74.68.31 unsecure.vostrom.com. 86400     IN     NS      udns2.ultradns.net. www.unsecure.vostrom.com. 300   IN     A       204.74.68.31 www.unsecure.vostrom.com. 300   IN     A       10.10.10.4 unsecure.vostrom.com. 14400     IN     MX      20 inbound.postal.phx.vostrom.com. unsecure.vostrom.com. 14400     IN     MX      10 inbound.postal.lax.vostrom.com. interestingserver.unsecure.vostrom.com. 14400 IN A 10.0.0.1 unsecure.vostrom.com. 14400     IN     SOA     udns1.ultradns.net. hostmaster.vostrom.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 

Since the system administrator didn't protect this zone, his or her name servers let us transfer its entire contents, which helps us map their network and find other targets of interest. All DNS records (all types) are listed in the zone transfer, including MX records for their mail servers, NS records for their subdelegations of domains in their hierarchy, and so on. Of course, if we're only looking for mail servers within a given domain, the "DIG" or "host" tool may be used to acquire those records directly especially useful if zone transfers have been locked down:

 > dig mx unsecure.vostrom.com ;   DiG 9.2.1   mx unsecure.vostrom.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: ;unsecure.vostrom.com.                 IN     MX ; ; ANSWER SECTION: unsecure.vostrom.com. 14400    IN      MX     20 inbound.postal.phx.vostrom.com. unsecure.vostrom.com. 14400    IN      MX     10 inbound.postal.lax.vostrom.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 

Or alternatively, using the host command:

 > host -t mx vostrom.com vostrom.com mail is handled by 10 inbound.postal.lax.vostrom.com. vostrom.com mail is handled by 20 inbound.postal.phx.vostrom.com. 

And why not let Windows users join in the fun to do all of the above using the obsolescent nslookup tool:

 > nslookup Server: rudns1.ultradns.net Address: 204.69.234.254 > server udns1.ultradns.net Default Server: udns1.ultradns.net Address: 204.69.234.1 > set type=any > Is unsecure.vostrom.com [udns1.ultradns.net] unsecure.vostrom.com.             NS     server = udns1.ultradns.net ihopetheydontseethis                A      10.0.0.4 backupserver                        A      10.0.0.3 stagingenvironment                  A      10.0.0.2 unsecure.vostrom.com.             A      204.74.68.31 unsecure.vostrom.com.             NS     server = udns2.ultradns.net www                                 A      204.74.68.31 www                                 A      10.10.10.4 interestingserver                   A      10.0.0.1 > set type=mx > unsecure.vostrom.com Server: udns1.ultradns.net Address: 204.69.234.1 unsecure.vostrom.com MX preference = 20, mail exchanger = inbound.postal.phx.vostrom.com unsecure.vostrom.com MX preference = 10, mail exchanger = inbound.postal.lax.vostrom.com unsecure.vostrom.com  nameserver = udns2.ultradns.net unsecure.vostrom.com  nameserver = udns1.ultradns.net udns2.ultradns.net      internet address = 204.74.101.1 udns1.ultradns.net      internet address = 204.69.234.1 

Another detail to note is that system administrators tend toward application-layer security configuration as opposed to network-layer security configuration on a day-to-day basis with DNS. That means that when a system administrator attempts to lock down zone transfers to a specific DNS server, he may filter UDP port 53 from the outside world completely, then open up TCP port 53 to the outside world, relying on zone transfer access control lists (ACLs) in his DNS nameserver configuration to protect against unauthorized zone transfers. In this case, he may have protected his server from zone transfers with his ACL, but has opened up this server to TCP-based DNS querieswe can get any information out of a nameserver over TCP as we can over UDP by specifying the appropriate options in DIG (unless the server software in question prohibits such activity by default (see djbdns)). This allows us to get information out of what most administrators would regard as a fundamentally well-protected DNS server that doesn't even allow UDP queries from the outside and that protects their zone information from transfer using application-based filters.

In this example, DIG is used to query the version number of a host using TCP.

 > dig +tcp @udns1.ultradns.net txt chaos version.bind ;   DiG 9.2.1   +tcp @udns1.ultradns.net txt chaos version.bind ; ; global options: printcmd ; ; Got answer: ; ; -   HEADER   - opcode: QUERY, status: NOERROR, id: 14193 ; ; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 3 ; ; QUESTION SECTION: ;version.bind.                   CH     TXT ; ; ANSWER SECTION: VERSION.BIND.            0       CH     TXT "UltraDNS Version 2.7.6 uild 1173" ; ; ADDITIONAL SECTION: server.name.             0       CH     TXT "UltraDNS (tm) by UltraDNS Corporation" server.info.             0       CH     TXT "(this is not a 'bind' server)" server.home.             0       CH TXT http://www.ultradns.com/ ; ; Query time: 4 msec ; ; SERVER: 204.69.234.1#53 (udns1.ultradns.net) ; ; WHEN: Wed Oct 6 15:02:44 2004 ; ; MSG SIZE rcvd: 250 

Cache Poisoning

DNS cache poisoning has been a vulnerability in several incantations of DNS server software packages since 1993 including BIND, Microsoft's Active Directory DNS, and the original Microsoft DNS software, among others. Christoph Schuba is credited with the first disclosure of the vulnerability (for more information, go to http://ftp.cerias.purdue.edu/pub/papers/christoph-schuba/schuba-DNS-msthesis.pdf) that relates to misinforming a target DNS server by sending extra data in the context of a response to a query. Essentially, by making any given nameserver that will recursively find answers query a server we control, we could give it the answer it was looking for and also give it a few other answers it wasn't looking for. Without questioning why it received extraneous data, nameserver software would simply cache it, and use this data to answer queries until the data reached its expiration time (Time to Live, or TTL).

In 1997, a CERT advisory (http://www.cert.org/advisories/CA-1997-22.html) was issued announcing that BIND (the predominant nameserver software) was vulnerable to this attack because it did not randomize its transaction IDsit simply incremented them sequentially. Transaction IDs represent the only security in a DNS packet beyond its layer-4 source and destination ports and addresses. The transaction ID is designed to associate queries with answers since DNS UDP datagrams are connectionlesswe need to be able to send a query amongst a sea of queries and find the associated answer amongst a sea of responses. Because BIND didn't randomize its transaction IDs, attackers found a simple mechanism by which to ask it to resolve an external name (like http://www.yahoo.com). They could then beat the legitimate answer back by spoofing the authoritative nameserver's IP address in a response packet with data inside it that would misinform everyone using the target DNS server for DNS resolution until the TTL of the misinformation ran out. BIND was upgraded to implement randomized transaction IDs in order to make guessing the transaction ID more difficult. Different platforms use different pseudo-random number generators (PRNGs) with different degrees of security.

Today, cache-poisoning attacks are still being proliferated throughout the Internet, except attackers are using hundreds of queries and hundreds of spoofed responses instead of one or two in order to increase the statistical likelihood of success in poisoning the cache on a nameserver with a sophisticated PRNG. A useful implementation of an IDS sensor would be to monitor the number of queries (per second) for a given DNS record over a period of time, and if that number seems unseasonably large, you may be in the middle of a cache-poisoning attempt on your nameserver.

DNS Is Not a "Safe Service"

Another common, but significant problem with an organization's implementation of DNS is that system administrators tend to view it as a "safe service." In fact, we've seen a tremendous number of firewall implementations that allow clients (desktops) in enterprise networks to query any nameserver they want. The firewalls often keep state on the transactions to make sure the clients get their answer back through the firewall when they ask an external nameserver for a DNS record. While this seems reasonable considering the limitations of the connectionless protocol, danger looms.

Miscreants are smart enough to find the weakest link. If you have relaxed packet filters that allow users to pin up tunnels through your firewall because you're allowing all UDP traffic over port 53 to traverse your network, someone will find it. And more than likely, they'll implement some kind of remote shell here, such as Tunnelshell (http://www.geocities.com/fryxar/).

Imagine if we were able to dump a file into maximum-length DNS TXT records (after encoding it properly so all characters were properly represented), splitting it up as needed? Then we could implement client software that knew about this transfer methodology and could download files through DNS, asking for TXT records sequentially and then reassembling the file. It could be genius, having bypassed traditionally inspected file transfer mechanisms and introduced the new hip method of file-sharing networks. Or it could be a fool's errand, putting undue pressure on the whole DNS infrastructure. Call it what you will, it's been done (http://www.netrogenic.com/dnstorrent/). The bottom line is that a system administrator must exhibit a degree of control over its users, and today that means controlling where and how they get their information.

The worst incarnation of miscreant behavior with regard to DNS is its use in botnets , which are described in greater detail in Chapter 17. With the advent of modern-day Trojans and spyware, the autonomous software is seldom perfectly autonomous. In order to upload its spoils (keystroke captures, password files, and so on), to upgrade itself, or to download its next set of instructions, Trojans traditionally "phone home" to their command-and-control networks. First, this phone home process utilized Internet relay chat (IRC). Then, HTTP-based methods were used. While many Trojans still use these mechanisms, a few are now utilizing DNS TXT records, as described earlier, to share information. The real danger here is that it's, by definition, proxy-safe and difficult to detect and stop. Essentially, your local recursive/caching nameserver is helping them phone home (getting the information for them and handing it back to the infected system locally) and you can't distinguish between a normal request and their control channel.