Digging Up Dirt in the DNS Hierarchy, Part II
And, we get this in response:
; <<>> DiG 9.4.1-P1 <<>> @ns1.example.net www.example.com ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49319 ;; flags: qr rd ra aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.example.net. IN A ;; ANSWER SECTION: www.example.com. 5 IN A 10.10.0.5 www.example.com. 5 IN A 10.10.0.6 ;; Query time: 61 msec ;; SERVER: 220.127.116.11#53(18.104.22.168) ...
There are a couple of things to note in this response. First, the aa flag is set, which is what we would expect. If this flag is not set, this would be what is called a lame-server (a server defined in the parent as authoritative for a domain but that does not return the aa flag to a query for information in that domain). The master (primary) and slave (secondary) name servers for a domain must return the aa flag. There is no externally visible difference between master and slave server responses. This means you can use two or more slave servers to provide authoritative service and keep your master completely hidden. The second point to note is that the ra flag is set, thus offering a recursion service. Let's test it:
dig @dns1.example.net some.obscure.domain
And bingo, we get a response—this server is also open. The reason for using some.obscure.domain is to make sure the data is not already cached, in which case, depending on its configuration, the name server could return the desired results and still be closed as noted previously. Using an obscure name minimizes the possibility of a false positive. The corollary is also true. If we fire a request for a popular domain name, such as google.com, to an apparently closed DNS and get a valid result, we know this server is providing recursive services for some set of clients—unless of course it is the authoritative server for google.com! This knowledge gives us some, very modest, poisoning possibilities by looking at the TTL time of the response.
In passing, we also should note that the site sensibly has provided two IP addresses, albeit both on the same IP address block. This means that browsers automatically will fail over (in 2–3 minutes). If the first server fails, it uses a five-second TTL, which, apart from being of great assistance to potential cache poisoners, is entirely useless as Microsoft's browser will attempt to refresh its browser-cached IP addresses only every 30 minutes (one minute for Firefox).
So, ns1.example.net is using old, buggy software and is open. Can it get worse? Well, yes it can, and indeed, in this case, it does get worse.
So far, we have been emulating what a browser does and simply looking for ARRs; dig can be used to find any type of RR. In this case, the absence of an AUTHORITY SECTION is a tad suspicious, so let's experiment and try this command:
dig @ns1.example.net www.example.com ns
And, we get this response:
; <<>> DiG 9.4.1-P1 <<>> @ns1.example.net www.example.com ns ... ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49319 ;; flags: qr rd ra aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.example.com. IN NS ;; ANSWER SECTION: www.example.com. 3000 IN NS ns3.example.com. www.example.com. 3000 IN NS ns4.example.com. ;; ADDITIONAL SECTION: ns3.example.com. 3000 IN A 10.10.0.8 ns3.example.com. 3000 IN A 10.10.0.9 ;; Query time: 61 msec ;; SERVER: 22.214.171.124#53(126.96.36.199) ...
This result means that the user is trying to delegate www.example.com to an alternate set of DNS servers, ns3 and ns4.example.com, but the delegation is invalid, so the defined DNS servers are not visible. The zone file probably has this construct:
$ORIGIN example.com. ... ; these A RRs should not be present in the example.com ; zone file but should be present in a www.example.com zone file www 5 IN A 10.10.0.5 www 5 IN A 10.10.0.5 ; valid delegation for www.example.com www 3000 IN NS ns3.example.com. www 3000 IN NS ns4.example.com. ... ; required glue RRs for the delegation ns3.example.com. 3000 IN A 10.10.0.8 ns3.example.com. 3000 IN A 10.10.0.9
BIND 9 (used by ns2.example.com) correctly will interpret this as a delegation and generate a referral to ns3 and ns4.example.com. BIND 4 (ns1.example.net) will not, and thus, approximately 50% of the traffic will never even see the delegated servers, which if we perform our checks using the above techniques, we would see are solidly configured and using the latest versions of BIND (similarly with the name servers for online.example.com).
In summary, this user configured and maintained his or her internal name servers with great care and in a thoroughly professional manner but had entirely overlooked the route by which users arrived at the site. To put it another way, the castle was impregnable, the moat wide and deep, the walls thick, the defenses manned, but the front door wide open.
This problem may look pretty far-fetched, but it was real, took less than ten minutes to find and—in case you were wondering—is now fixed!
When performing this kind of analysis, you will develop your own methods and variations, but here are some things to look for that seem to make organizations especially vulnerable:
Multiple domain names, for instance, example.com, secure-example.com and online-example.com, tend to make managing and monitoring more complex for the operator and, hence, are more likely to have DNS configuration errors.
Backroom domains—many organizations elect to use unique domain names, for instance, support-example.com, to perform infrastructure functions, such as running their internal DNS systems, that are not visible to end users. For some strange reason, many of these organizations think end-user invisibility also applies to the DNS system.
Many DNS servers—the more DNS servers, the more likely it is that at least one of them is running either badly configured or unpatched software.
BIND 8 and open is a very common ISP configuration. BIND 8 is pretty buggy, represents approximately 20% of all DNS servers and is now officially deprecated. Whoopee for the bad guys.
Always follow the transitive trust routes. The more there are, the more likely you are to find a problem.
Outsourced DNS—there are highly professional DNS organizations to whom many large users subcontract a provision of DNS service and whose DNS configurations are invariably in very good shape. Many organizations use the outsourced DNS to delegate to internal DNS systems. These users can exhibit the exact opposite characteristics of the example case—the internal name servers are a disaster. Further, in a surprising number of cases, even when outsourced, there is one internal name server or that of a local service provider on the primary authoritative list—almost invariably this additional name server has a problem.
The techniques used here are not aggressive; for example, they do not test for AXFR (zone transfer) vulnerability, because this not a friendly action and is likely to generate nasty responses, quite rightly, from DNS administrators. Treading lightly is the best technique.
We used a very small subset of dig's capability here. Read the man pages for more information. If you do find something suspicious or wrong, double-check, then either fix it immediately or, if it affects a third party, act responsibly and inform the relevant organization (though it is sometimes extremely difficult to get through to the right person). Theoretically, the SOA RR of the domain in question should contain the valid e-mail address of the right person in the organization.
I encourage you to experiment and modify the techniques for diagnosing and auditing your DNS systems—it will pay dividends time and time again—it's best that you get there before the bad guys. And, it can provide endless hours of fun as you sleuth around.