There are a variety of attack vectors in which skilled
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
By taking advantage of
By using esoteric features of DNS to transfer data into/out of your organization
The most natural
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-
Most miscreants today use various registrar and DNS-related tools in order to perform footprinting of their targets.
> whois -h whois.geektools.com 188.8.131.52 connecting to whois.geektools.com [184.108.40.206: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: 220.127.116.11 - 18.104.22.168 CIDR: 22.214.171.124/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: +1-877-453-8353 OrgAbuseEmail: email@example.com OrgTechHandle: TPL1-ARIN OrgTechName: Tech POC LVLT OrgTechPhone: +1-877-453-8353 OrgTechEmail: firstname.lastname@example.org OrgTechHandle: ARINC4-ARIN OrgTechName: ARIN Contact OrgTechPhone: +1-800-436-8489 OrgTechEmail: email@example.com Results brought to you by the GeekTools WHOIS Proxy Server results may be copyrighted and are used with permission.
> whois -h whois.geektools.com vostrom.com GeekTools Whois Proxy v5.0.4 Ready. Checking access for 126.96.36.199... 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 firstname.lastname@example.org 5025 N. Central Ave. #410 Phoenix, Arizona 85012 United States 888-569-6107 Technical Contact: Registrar, Domain email@example.com 5025 N. Central Ave. #410 Phoenix, Arizona 85012 United States 888-569-6107 Domain servers in listed order: UDNS1.ULTRADNS.NET UDNS2.ULTRADNS.NET
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
> 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 firstname.lastname@example.org 5025 N. Central Ave. #410 Phoenix, Arizona 85012 United States 888-569-6107 Technical Contact: Registrar, Domain email@example.com 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
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
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
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
Several other ideas for improving overall DNS reliability are also in the works, including what is effectively an out-of-
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.
The primary attack vectors
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.
> 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
> 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 188.8.131.52 unsecure.vostrom.com. 86400 IN NS udns2.ultradns.net. www.unsecure.vostrom.com. 300 IN A 184.108.40.206 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: 220.127.116.11#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
> 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: 18.104.22.168#53 (22.214.171.124) ; ; 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: 126.96.36.199 > server udns1.ultradns.net Default Server: udns1.ultradns.net Address: 188.8.131.52 > 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 184.108.40.206 unsecure.vostrom.com. NS server = udns2.ultradns.net www A 220.127.116.11 www A 10.10.10.4 interestingserver A 10.0.0.1 > set type=mx > unsecure.vostrom.com Server: udns1.ultradns.net Address: 18.104.22.168 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 = 22.214.171.124 udns1.ultradns.net internet address = 126.96.36.199
Another detail to note is that system administrators tend toward
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: 188.8.131.52#53 (udns1.ultradns.net) ; ; WHEN: Wed Oct 6 15:02:44 2004 ; ; MSG SIZE rcvd: 250
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
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
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
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
The worst incarnation of miscreant behavior with regard to DNS is its use in