Cache poisoning

from Wikipedia, the free encyclopedia

DNS spoofing and cache poisoning are IT security attacks on the domain name system in order to falsify the association between a domain name and the associated IP address . The purpose is to divert data traffic to another computer unnoticed, for example to carry out a phishing or pharming attack. If the data traffic is directed to an unreachable target, a denial-of-service attack can be carried out.

The terms DNS spoofing and cache poisoning come from different attack methods, but have the same purpose. Cache Poisoning ( German  temporary storage poisoning ) describes attacks in which fake resource records are smuggled into the DNS cache of the victim. DNS spoofing refers to attacks in which fake resource records are sent using IP spoofing . A related attack is DNS hijacking , in which a DNS resolver returns incorrect answers.

Attack using additional data

One historical cache poisoning attack method is the addition of additional, spoofed DNS records to legitimate DNS responses. If the inquirer takes over resource records from the response without checking, then fake resource records for any domain name can be fed into the DNS cache.

functionality

In the public DNS individual DNS servers are only for parts of the entire DNS authoritative . If a DNS server receives a request for an area in which it is not authoritative, it can forward the request to the next DNS server. To avoid unnecessary load, DNS servers can cache the responses from other servers to queries locally in a cache. In this case, the forwarding of the above request to another server could be omitted and a response could be sent immediately. A DNS subscriber who sends a request to a name server takes the received response into its cache for a specified period of time without being checked. In addition to the actual answer, additional (legitimate) data ( glue records ) are often transmitted, which are also stored in the cache. Cache poisoning is based on hiding one or more fake resource records in this additional data .

To put it more precisely: The name to be redirected ( e.g. de.wikipedia.org ) is entered as the alleged DNS server in the Authority Section of the response packet, and the IP address (e.g. 1.2.3.4) of a server controlled by the attacker is entered in the Additional Section .

Sequence example

  1. An attacker brings the name server XX under his control. He manipulates it in such a way that every time a name from the domain example.com is asked for, the fake record de.wikipedia.org 192.0.2.1 is delivered without being asked .
  2. The public name server YY wants to resolve the name test.example.com . He sends a corresponding request to the responsible name server XX (controlled by the attacker). This manipulated name server replies with the correct IP address, but also provides the falsified record de.wikipedia.org 192.0.2.1 . This is transferred unchecked to the cache by the requesting server YY.
  3. At a later point in time, a user tries to resolve the name de.wikipedia.org and contacts the public name server YY. The name server finds the (falsified) record in its cache and sends back the IP address 192.0.2.1 to the user in good faith.
  4. The user wants to access de.wikipedia.org , but is directed to a wrong website with the IP address 192.0.2.1 - which is not recognizable to him.

Troubleshooting

The security hole in the BIND name server was fixed in June 1997 by ignoring unsolicited resource records. Only resource records from the domain actually requested are accepted ( in-bailiwick ; German  in the administrative district ). All name servers in use today carry out this check before transferring them to the cache.

Shortly after the vulnerability became known, Eugene Kashpureff carried out a large-scale cache poisoning attack against still vulnerable BIND name servers, for which he was later given a suspended sentence.

DNS spoofing

With DNS spoofing, the attacker sends fake DNS responses that supposedly come from the responsible name server using IP spoofing . For the attack to be successful, the falsified response must either reach the attacked resolver before the legitimate response, or the responsible name server is prevented from sending a response by a denial-of-service attack . In addition, the parameters of the response must match the request, including the 16-bit transaction number. If the attacker is in the local computer network, he can observe the transaction number with a sniffer in the network. Otherwise, the transaction number must be guessed, which on average requires attempts. The attacker can send multiple forged replies at the same time to increase the likelihood of success in an attack attempt, but this increases the cost of resources.

Various vulnerabilities make it easier to guess the transaction number. With BIND 8, the pseudo-random number generator was insecure, so that the transaction number could be predicted with little effort. If the attacked resolver sends an identical DNS request several times with different transaction numbers, the probability of success increases considerably due to the birthday paradox .

If the attack was unsuccessful, the correct resource record is in the cache, so that the attacker can only try again after the time to live has expired .

Kaminsky attack

In July 2008, Dan Kaminsky presented a variant of the attack that bypasses the caching of valid responses described above and thus significantly reduces the time required. By querying domain names that do not exist, a forgery attempt can be repeated any number of times if the correct transaction number was not guessed in a multitude of forged reply packets. The falsified response contains a delegation consisting of an NS resource record and a glue record, which points to a host of the attacker. In this way, it is achieved that the glue records that have been imposed on them are in-bailiwick and the entire domain is bent over to the attacker.

Internet censorship

DNS spoofing is used to censor the Internet in various countries . If DNS resolvers return falsified answers, this is also referred to as DNS hijacking . This was the intended method for the discussed access restriction law for blocking websites in Germany .

A man-in-the-middle attack by a network operator is also called DNS injection . The network operator uses deep packet inspection to read the domain names from all DNS requests and compare them against a blacklist . If the domain name is blocked, a fake DNS response is sent to the sender via DNS spoofing. Since with this method all DNS queries in the network are examined, the blocking also works if the user is not using the network operator's DNS server.

DNS injection is used in the People's Republic of China as part of the Golden Shield project . Third parties from other countries can also receive fake answers if their DNS request is routed through Chinese networks.

Protective measures

Measures to protect against DNS spoofing aim either to include more random information in the DNS message that the attacker has to guess, or to protect the message with cryptographic methods .

Random information

Since the Kaminsky attack became known, all common name servers have been using source port randomization ( djbdns and PowerDNS had already done so). In addition to the transaction number, the source port of a DNS request is randomly selected in the UDP header . Depending on the implementation, this results in an additional 11–16 bits, which the attacker also has to guess correctly. Accordingly, attempts are necessary on average when the possible ports are fully exhausted .

Another method is 0x20-bit encoding , in which letters in the requested domain name are randomly set in upper and lower case, for example dE.WiKiPedia.ORG . When resolving names, upper and lower case letters are basically equivalent, whereby according to RFC 1034 the spelling in the response should correspond to the query name. The length of the additional randomness depends on the number of letters in the domain name, in the example de.wikipedia.org it is 14 bits.

The above-mentioned procedures have in common that the message format does not have to be adapted and the procedures are therefore largely compatible with the existing DNS infrastructure. DNS spoofing can still be carried out in principle, but the increased range of parameters to be guessed reduces the probability of success for a remote attacker. None of the methods for increasing the randomness protects against an attacker who can read the DNS request ( on-path attacker ).

Cryptographic procedures

Another category of protective measures consists in expanding the DNS message format to include digital signatures or message authentication codes that are generated and checked using cryptographic procedures . An attacker can generate fake DNS responses, but without knowing the secret key, he cannot generate a suitable signature.

A well-known method is DNSSEC , in which resource records are signed with asymmetric cryptosystems . DNSSEC is used in practice to some extent, but it does not protect the majority of DNS Internet traffic.

An alternative method to DNSSEC is DNSCurve , in which it is not resource records but the communication channel between the resolver and the name server that is cryptographically protected. It uses a combination of asymmetrical and symmetrical cryptosystems. An adaptation of DNSCurve is DNSCrypt , which OpenDNS uses to secure communication between the end user and the resolver.

Similar to DNSCurve or DNSCrypt, TSIG secures communication between two DNS participants. To do this, it uses HMAC with symmetrical keys that have to be configured manually.

Web links

Individual evidence

  1. ↑ Heise.de: Massive DNS security problem endangers the Internet, July 9, 2008
  2. ↑ RUS-CERT message # 1476: [Generic / DNS] Vulnerability in the DNS protocol simplifies cache poisoning, July 8, 2008
  3. ↑ Anonymous authors: The Collateral Damage of Internet Censorship by DNS Injection . In: ACM SIGCOMM Computer Communication Review . tape 42 , no. 3 , 2012, p. 21–27 , doi : 10.1145 / 2317307.2317311 ( older draft as PDF file ).
  4. ↑ http://cr.yp.to/djbdns/forgery.html
  5. ↑ Matthäus Wander, Torben Weis: Measuring Occurrence of DNSSEC Validation . In: Passive and Active Measurement . 2013, ISBN 978-3-642-36516-4 , pp. 125-134 , doi : 10.1007 / 978-3-642-36516-4_13 ( PDF file ).