The BIND implementation of the Domain Name System (DNS) is a critical part of the infrastructure of the Internet. For example, almost all of the 13 root name servers use BIND. On July 28 a vulnerability was published in BIND that could be anonymously exploited by an attacker. To crash the server, all an attacker would have to send malicious TKEY records. A CVE number was assigned (CVE-2015-5477) and BIND’s developers, the Internet System Consortium (ISC) released an advisory notifying users that a proof-of-concept (PoC) exploit has been released.
Vulnerability Mechanism
The vulnerability occurs when the BIND server is processing TKEY queries. When BIND is processing the TKEY query to find a TKEY Record that matches the query, an especially formed malicious request can cause a crash. The crash happens because BIND is not assigning a correct value to the name parameter when calling the functiondns_message_findname() inside the method dns_tkey_processquery() in lib/dns/tkey.c.
Crash Point
Figure 1 shows the BIND call stack at the crashing point. The function dns_message_findname() crash validating the name parameter is highlighted in Figure 2.
Figure 1. BIND Call Stack Crash
Figure 2. REQUIRE macro
The name parameter is not correctly initialized and the REQUIRE macro shuts down the named process (i.e., the DNS server).
Crashing Conditions
The DNS protocol format is defined via several RFCs. Here is a very simplified description of the message format related to CVE. The DNS client (resolver) sends a Query to DNS server to ask for specific information. The Figure 3 shows a generalized DNS query format with only one record on the Query.
Figure 3. DNS Query Format
The DNS Query Record tells the server what information it is being asked for: Two important parameters are specified: The Name and Type. The Name will refer to an object in the DNS; this is generally a domain. The Typespecifies what kind of information is being requested, for example if we are asking for the IP for a domain a record type A is used.
In some cases, the QUERY record by itself is not enough to declare all the required information. Other sections of the DNS Query Format are then used. Figure 4 shows an example of a TKEY query type. Extra information is required to be sent to the server and the Additional RRs section is used for this.
Figure 4. DNS TKEY Query Format
Because the Query and the Additional RR comes in different sections, DNS must find the Additional record corresponding to the DNS Query record. To implement this, the server will iterate over all Additional records matching the ones containing the same TYPE and Name.
The DNS TKEY specification is defined in RFC 2930. BIND implements the matching of TKEY records between QUERY and Additional sections in the method dns_tkey_processquery(), which is implemented in lib/dns/tkey.c. The Figure 5 shows the code section where the matching is carried out.
Figure 5. dns_tkey_processquery function
If BIND is not able to find the Query Record in the Additional section, it will try the Answer section. This is done explicitly because Windows 2000 puts the data that is being searched for. The actual crash happens here; this is because the variable name was initialized when the Additional section check was done, but at the same time, it was not successful. What conditions can cause this seemingly contradictory state? For that, a quick look at the dns_message_findname() function is needed.
Figure 6. dns_message_findname() function
BIND will find all Additional records matching the name in the TKEY Query record. All found records are stored in foundname. If at least one matching name is found, then the name variable is initialized. (That is our first condition.)
BIND will then check the TYPE of all the foundname records. If foundname contains one TKEY record, thendns_message_findname() will return successful and the Answer section will not be checked.
So the conditions to trigger the vulnerability are:
- The QUERY Records section must contain at least one record where:
- Type: TKEY
- Name: any selected name.
- The Additional records section must contains at least one record of any type (Except TKEY) with the same name of the QUERY Record.
- If one or more TKEY records exist in the Additional records section, it must use a different name.
Let us check how the publicly available proof of concept (PoC) code works:
Attack Delivery
The attack can be implemented by sending malicious TKEY queries to the DNS server running the BIND service. No authentication is required to successfully exploit the vulnerability. Both recursive and authoritative servers are at risk. In addition, exposure is not prevented by either ACLs or configuration options limiting or denying service because the exploitable code occurs early in the packet handling, before checks enforcing those boundaries.
Some public PoCs are available, and it is has been reported that servers are being exploited in the wild. Here is described traffic generated from two public POCs to illustrate what was discussed before.
One of the publicly available PoCs sends the following DNS traffic:
Figure 7. PoC Example #1
We can see how the Additional section contains the malicious A record with the same name as the TKEY Query name. Note that this attack contains the Answer section; that section it is not required to successfully exploit BIND.
The other one public PoC is sends the following traffic:.
Figure 8. POC Example #2
In this example, the Additional section contains a TXT record.
Conclusions
This vulnerability is considered critical because it can be exploited by just sending one malicious request anonymously. At same time, the affected software is part of a critical internet infrastructure and of many internal network deployment. Within an enterprise, the loss of a DNS server can effectively render an entire network offline.
By nature of DNS protocol, this attack can have many variants, for example, multiple Records in the Query Section and in the Additional Section. A clever attacker can create an exploit to bypass existing protections.
It is therefore crucial that administrators install the latest version of BIND. One form of mitigation would be the existence of redundant DNSs in the network. Network infrastructures should have multiple DNS servers, because with that configuration, the infrastructure is more resilient to attacks because even if one DNS is down, the other ones can still be working. But if all the DNS server have the same DNS implementation, they all can be vulnerable to a specific zero-day at the same time. Instead, if multiple servers are running with different software (BIND, Microsoft DNS, NSD, etc. ) then the DNS infrastructure is more resilient to DOS attacks in the case of zero-days like this one
Vulnerability protection in Trend Micro Deep Security protects user systems from threats that may leverage this vulnerability with the following DPI rules:
- 1006924 – ISC BIND TKEY Query Handling Denial Of Service Vulnerability (CVE-2015-5477)
- 1006925 – ISC BIND TKEY Query Handling Denial Of Service Vulnerability (CVE-2015-5477) – 1