A Security Evaluation of DNSSEC with NSEC Review

A Security Evaluation of DNSSEC with NSEC Review Network Security Instructor:Dr. Shishir Nagaraja Submitted By: Jyoti Leeka November 16, 2011 1 Introduction to the topic and the reason for the topic being interesting This paper discusses the security related aspects of Domain Name System Security Extensions, or DNSSEC, which employs Next Secure 3 or NSEC3. Next Secure 3 is used for enlisiting a set of present resource records, resource records are set of values which are stored in DNS corresponding to a set of host names. Domain Name System Security Extensions is used ensure the authenticity of the records by appending digital signatures to the resource records. The topic is interesting considering the recent disclosure of Domain Name System cache poisoning attacks. 2 Questions that the paper asks and how are those questions interesting The paper explores the security related aspects of Domain Name System Security Extensions, DNSSEC with NSEC3. The question is interesting as a wrong entry into Domain Name System redirects the traffic to a malicious site, hence security issues related to Domain Name System s Security must be given prime importance. 3 How does it answer the questions In order to answer the question the author first enlists basic information related to Domain Name System, which is given below: 1. Domain Name System is used for mapping a host name to its corresponding IP address. 2. In a Domain Name System, domain name can be treated in-dices into a table which stores its corresponding records called Resource Records. 3. Resource Records includes a domain s IPv4 addresses, IPv6 address, Mail Servers (MX), Name Servers (NS). 4. Glue Records are the IP address and nameserver record of the Child which are stored which are stored in the parent. These records are helpful in delegation. 5. The procedure of resolving a host name to its corresponding IP address is given below: (a) The users host computer which represents the Stub Resolver queries the local recursive resolver for mapping a host name to an IP address. 1

(b) The local recursive resolver then queries the Root Zone asking it for the IP address of the host name. (c) Since the Root Zone does not contain the requisite information, it redirects the recursive resolver to the authoritative TLD zone. (d) Since the TLD zone also does not contain the requisite information, it redirects the recursive resolver to the authoritative DNS server of the requested host name. (e) Upon querying the authoritative DNS server, the recursive resolver obtains the IP address of the hostname, which it returns to the stub resolver. Along with this it caches the queried data. 6. The DNS recursive resolver accepts the most recently received reply to a due query, whose Transaction ID matches the Transaction ID of the query. Thus an attacker which an forge a reply matching the queries Transaction ID can introduce false records into the recursive resolver cache. Such an attack is known as cache poisoning attack. 7. Into order to carry out a cache poisoning attack, a man-in-the-middle attacker can eavesdrop on the recursive resolver s traffic and thus gets to know the Transaction ID of the query, which the attacker uses to create false reply attacks, which in turn introduce false records into the recursive resolver s cache. 8. Kaminsky s attack is another way in which the recursive resolver s cache can be poisoned. Kaminsky s cache poisoning attack is carried out according to the following steps: (a) The attacker sends requests to recursive resolver to map fake host names. (b) The recursive resolver now sends requests to the root zone, which redirects it to the TLD zone. (c) The TLD zone replies to the recursive resolver s query by giving returning to it the address and the nameserver glue records. (d) Before the TLD zone could send the reply packet, the attacker sends the fake packet containing the address and nameserver record of the zone. (e) Thus further queries are redirected by the recursive resolver towards the attackers zone. In order to mitigate this weakness of DNS, Kaminsky proposed to randomize the source port. However, the solution proposed by Kaminsky just decreases the probability of an attack, it does not prevent such an attack. Also Kaminsky s solution still does not protect from man-in-the-middle attacks. Domain Name System Security Extension Protocol consists of the following features: 1. Domain Name Security Extension ensures authenticity of the responses by adding adding cryptographic signatures to resource records. 2. RFC-4033 states that DNSSEC does not provide for security of packets exchanged between the stub resolver and the recursive resolver. 3. In order to support the Public Key Infrastructure provided by DNSSEC, the following resource records are added to DNSSEC: (a) DNSKEY: DNSKEY contains the public key which is used for verifying the cryptographic signature. (b) RRSIG: RRSIG contains the cryptographic signature. (c) DS or Delegation Signer: In delegation it contains the digest of the key of the delegation. 4. In cases where the child or the parent does not support DNSSEC, an insecure delegation is created. 5. In order to ensure integrity DNSSEC cryptographically signs the resource records and sends it along with the reply packets. 2

6. In order to attest the existence of valid domain names and invalid domain names. A list containing the set of existing records is created, this list is named Next Secure(NSEC). This list is included into resource records which are used for verification by the recursive resolver. Another method for authentication which has been proposed is Next Secure3 (NSEC3) in which hashed values of the valid domain names are stored in the Resource Records. 7. Domain Name System Security Extensions stores absolute time values in the Time To Live(TTL) field as relative Time To Live values are vulnerable to replay attacks. 8. The packet used by Domain Name System Security Extension is the same as that of Domain Name System, but with the addition of resource records needed for security. The DNS header also contains the following security related bits: (a) Authenticated Data(AD) is used by the sending DNS server to signify that it has verified the data. (b) Checking Disabled(CD) is used to verify that the queried DNS severs should not verify the data. 9. DNSSEC is immune to Kaminsky s cache poisoning attack, as before caching the glued records are verified by the attestation chain. In order to judge the security provided by DNSSEC, the authors build a non deterministic finite automaton called Murϕ. Murϕ works by checking the security invariants. The details about Murϕ are given below: 1. Murϕ s architecture includes: DNS root servers, which are the regarded as the trusted end point. It also includes TLD zone servers and servers which are responsible for a domain, both these are represented in the system by transition rules. It represents the attacker by the information that the attacker has gathered by eavesdropping and the transitions that are caused when it varies the system parameters. 2. When a zone receives an RR Query the following steps are performed by the recursive resolver: (a) If the response record pertaining to the query exists in the the zones server, then a signed response record is given by the server to the recursive resolver. (b) If the response record pertaining to the query does not exist in the zone server, then the following two cases may arise: i. The queried data does not exist at all. Then the covering query is returned corresponding to its status as mentioned below: A. opt-out option in Next Secure 3. B. There does not exist opt-out option in Next Secure 3. (c) The queried data exists but in the child zone. Corresponding to this there are two cases: i. If it followed a secure authentication chain, then secure delegation is returned. ii. If it follows an insecure authentication chain, then the following two cases may arise: A. Glue records containing IP address and nameserver in the next secure 3 chain are returned. B. Glue records containing IP address and nameserver which are not in the valid records of the next secure 3 chain are returned. 3. The recursive resolver s depiction in Murϕ is illustrated below: (a) The time to live field and the other data pertaining to the query expires as it should in the original model. (b) The recursive resolver s model as incorporated into Murϕ has decision making abilities, which help it in deciding the corresponding response for a query. The recursive resolver incorporated into Murϕ contains the following two caches: i. Attested Cache: Whose contents have been verified up to the root zone. 3

ii. Non-Attested Cache: Whose contents are not secure up to the root zone. 4. The attacker may resort to any of the following means: (a) The attacker may eavesdrop on the communication between the recursive resolver and the DNS server. (b) The attacker may copy any of the packets transferred between the recursive resolver and the DNS server. (c) The attacker may change any of the following parts of the transmitted packets: i. Header ii. The part containing the question. iii. The attacker may delete some parts of the resource record. iv. The attacker may add some fields into the resource records. v. The attacker change the address field, the authoritative server and the nameserver. 5. The following invariants are checked by Murϕ: (a) Verifies that the recursive resolver has not stored any false resource records. (b) Only the valid keys are cached. (c) Verifies the attestation chain of the resource record. 6. The parent record cached in the recursive resolver may expire before the child record, which it attests. Some of the security invariant breaches that may be caused are: 1. There are some glue records which are not cryptographically signed, this feature was incorporated into DNSSEC in order to make it backward compatible with other DNS systems which did not employ DNSSEC. The attacker can exploit this by changing the glue records. 2. Apart from glue records as discussed in step 1, there are are false resource records which can be sent by the attacker to the recursive resolver, since the recursive resolver can not now verify the records, hence this leads to cache poisoning. 3. A security invariant breach can occur, since an attacker can successfully change the contents of the Domain Name System Security Extension s response packet. 4. It may happen that a businessman has to change the location of his company and thus release give up its IP addresses. The attacker may some how take advantage of this and can acquire a set of IP addresses which were released. Now by default the attacker also becomes the owner of businessman s resource record s digital signatures, thus capable of sending fake records to the recursive resolver. The author s modified Murϕ to include all the above mentioned weaknesses and ran the modified protocol successfully. In order to mitigate the vulnerability in DNSSEC, the author suggests that the recursive resolver must only accept responses from DNSSEC and not from DNS. Also verification of all the resource records must be performed at the recursive resolver itself. In order to perform this, the recursive resolver must maintain an attested cache, which contains the information about the authority for the recursive records as well as the attestation chain. The authors depict the weaknesses of Domain Name System Security Extensions by carrying out an experiment. In the experiment the authors create a server bank.com which redirects the recursive resolver to www.bank.com. The server also creates an opt-out Next Secure 3 option for the site attack1.bank.com and delegation to attack2.bank.com which is not secure. The authors were able to carry out the following attacks (Reference: A security evaluation of DNSSEC with Next Secure 3 by John Mitchell, et.al.): 4

1. In order for the attack to succeed the user either sends a request to recursive resolver for browsing the website or embeds and image in another site, which contains the hyper-link to the attackers site. The recursive resolver sends an honest query to the bank.com server. But before bank.com server sends a reply, the attacker sends its reply, with the transaction ID matching that of the query, but containing the IP address of the attacker. This attack is possible because of either the next secure 3 opt-out option or a not secure delegation to the attacker s site.this poisons the cache and the cache remains poisoned till the Time To Live period of the Resource Record expires. 2. The attacker carries off the users cookies by exploiting the browser s policy that cookies which are not secure may be transmitted to a sub-domain of the main domain. The following steps demonstrate the attack being carried out: (a) The user clicks on an image containing the hyperlink to the attacker s site. (b) The recursive resolver sends a query to the DNS zone server. (c) The attacker eavesdrops on the communication and hence gets to know the Transaction ID of the query. (d) Using the Transaction ID the attacker sends a false response to the recursive resolver containing a redirection to the attacker s server. (e) The recursive resolver queries the attacker s server for the IP address of the site, the attacking server responds with the attacker s site address. (f) Now the users browser sends the insecure cookies to the received IP address for starting the session. Thus the above steps illustrate how an attacker can successfully steal a user s cookies by exploiting the vulnerabilities of the browser as well as DNSSEC. 4 Methodology used to investigate the paper In order to investigate the paper the authors build a non deterministic finite automaton and carried out experiments to depict the vulnerabilities of DNSSEC. 5 What I learned from the paper I learned from the paper the vulnerabilities present in Domain Name System Security Extensions. 6 How the paper relates to previous work The paper relates to Daniel Bernstein s presentation at WOOT 09 in the following manner: 1. Daniel Brenstein s presentation just describes the weaknesses of DNSSEC, whereas the present paper along with discussing the weaknesses describes measures which when adopted will help in mitigating the weaknesses. 2. Brenstein suggests that a security breach can be caused by forging the glue records containing the IP address and the nameserver records, whereas this paper suggests that such a forging extra capabilities to the attacker. 7 Strengths of the paper I liked the fact that the authors implemented a factual attack in laboratory under the actual circumstances whereby the vulnerabilities present in DNSSEC are used to steal the actual browser cookies. 5

8 Weaknesses of the paper I found out the following weaknesses in the paper: 1. The author suggests that Next Secure 3 is used to provide security as the owner names are cryptographically hashed and not available in cleartext. However an attacker may still be able to find out the owners name as the mapping between the owner names and the cryptographic hash text is of a limited size and thus easily guessable. 2. I find that absolute time temporal specification for signatures has the limitation that absolute time requires proper synchronization of the clocks of the nameserver and the recursive resolver. 3. The author states that Resolvers must only securely answer the user s query when all of the information necessary to answer queried Resource Records with integrity guarantee is contained within the attested cache (Reference: A security evaluation of DNSSEC with NSEC3). I find the weakness that here the author wants a drastic change, i suggest that the author should also take into consideration the existent domain name systems which do not employ DNSSEC. 9 Results DNSSEC has loopholes and in order to mitigate these some of the below mentioned approaches have been suggested in the paper(reference: A security evaluation of DNSSEC with NSEC3): 1. In order to run a secure site Next Secure 3 records should not use the opt-out option. Also the people possessing the IP addresses should only give them up when their corresponding Resource Record signatures have expired. 2. In order to build a secure website no cookies should be sent over an insecure connection like http. 3. It is also required that the recursive resolver should correctly implement its security logic 4. The connection between recursive resolver and the end users stub resolver must be a secure one. 5. The browsers user interface must be designed in such a manner that it should give indications to the user about secure and not secure DNSSEC connection. 6