 |  |
http://www.bugtraq.ru/library/security/dns.html |
|
|||
|
|
|
||
| http://www.bugtraq.ru/library/security/dns.html |
||||
| ||||
Первая публикация - 1997, русский вариант вошел в книги "Атака через Internet", "Атака на Internet", "Атака из Internet"
Internet host addressing relies on 32-bit IP addresses. These addresses uniquely identify each computer in this global network. However, IP addresses are not very convenient for users.
Therefore, when the Internet was created, a decision was made to give each computer in the network a name. Such names help the user to better navigate in the Internet cyberspace - it is much easier to remember, for example, www.dsec.ru than an IP address consisting of four numbers. The decision to use mnemonic names in the Internet resulted in a problem of converting these names to the IP addresses. Such conversion is necessary as packet addressing on the network level is performed using IP addresses, not names, so the names are not suitable for direct message addressing in the Internet. During the first stages of the Internet evolution, when this network still linked a small number of computers, in order to solve the problem of name conversion, the NIC (Network Information Center) created a special file ('hosts' file) with the list of names and correspondent IP addresses of all network hosts. This file was regularly updated and spread across the whole network. As the Internet evolved, the number of the hosts in the network increased, and this scheme gradually became less and less efficient. So, a new system of name conversion was created. This system provides an opportunity to get information about the correspondence between the name and the IP address from the nearest information search server (DNS-server), if this information is not available on the user's computer. This system is called the Domain Name System (DNS).
To implement the DNS system, a special network protocol called the DNS protocol was designed . This protocol functions efficiently if the network contains special information search servers (DNS servers). The principal task of the DNS system is as follows. Normally at the moment when the host addresses a remote server in the modern Internet, it only knows the server name and does not know its IP address (which is required for the actual addressing). So the host is faced with a standard remote search task: it should find the IP address of the host by its name. The DNS system and the DNS protocol are intended to solve this problem.
Let us examine a DNS algorithm for a remote search of the IP address by the name:
A serious flaw of the remote search system and the DNS protocol in terms of security is their vulnerability to the "Fake DSC Object" standard-type remote attack. In the course of practical investigation and critical analysis of the DNS system security, three possible types of remote attacks on this system were identified.
This remote attack method is based on the standard-type attack based on a DNS search request. Before we start to examine the attack algorithm, let us outline some of the basic features of this system.
First, although the DNS system can function on any of the two protocols, TCP or UDP, it waits by default for the DNS response via the same protocol that was used for transmitting the DNS request. By default, it is the UDP protocol. It is only when a special response with the TC bit is received, which means that the size of the response from the DNS server exceeds the maximum size of a UDP datagram (RFC 1035), that a networking OS sends a DNS request using the TCP protocol.
Second, in operating systems like Windows 95 and in the old versions of Linux, the value of the "source port" field of a UDP packet usually starts with some value greater or equal to 1023 and is incremented with each DNS request.
Third, the ID value of the DNS request is filled in the following way. When the DNS request is sent from the host, the ID value depends on the actual networking application that generated this DNS request. The experiments show that when a request is sent from the command interpreter (shell) of a Linux or Windows '95 operating system (for example, ftp nic.funet.fi) this value is always set to one. When a request is sent from the Netscape Navigator, the browser increments the ID by one in each new request. When a request is sent by the DNS server itself, the server increments the ID by one in each request. These features can be important for an attack without intercepting the DNS request.
In order to perform an attack, the attacker has to intercept the DNS request, extract the UDP port number of its sender, a two-byte request ID and the name that should be searched for, and then send a fake DNS response to the UDP port extracted from the DNS request. In this response, it should specify the real IP address of the fake DNS server instead of the resulting IP address. This makes it possible to intercept the whole traffic between the attacked host and the server and manipulate it according to the "Fake DCS Object " scheme.
Let us examine the functional arrangement of a fake DNS server (fig. 1.):
Fig. 1. Functional Arrangement of Fake DNS Server.
The prerequisite for this DNS attack variety is the interception of a DNS request. This is only possible when the attacker is located either on some major traffic route or in the same segment as the real DNS server. These restrictions make it rather hard to use this kind of attack in practice (most probably, the attacker will not be able to penetrate either the segment of the DNS server nor the inter-segment link, although she/ he can crack the computer that is already located in a suitable place). However, once these prerequisites are present, it is possible to perform an inter-segmental remote attack on the Internet.
Another variety of remote attack on the DNS system is based on the "Fake Object of Distributed Computer System" standard-type remote attack (utilising the flaws in remote search algorithms ). In this case, the attacker prepares in advance and then continually transmits a fake DNS response from the address of the real DNS server to the attacked host without waiting for a DNS request! In other words, the attacker creates a "flood" of fake DNS responses in the Internet. This is possible because the DNS requests are usually sent via the UDP protocol, which does not provide any means of packet identification. The networking OS of the host will accept a response from the DNS server if it meets the following requirements: first, the source IP address of the response should be the same as the IP address of the DNS server; second, the DNS response should contain the same name that was sent in the DNS request; third, the DNS response should be addressed to the UDP port used to send the DNS request (this is actually the first problem for the attacker); and fourth, the ID field in the DNS response header should contain the same value that was sent in the DNS request (this is the attacker's second problem).
In this case, the attacker cannot intercept a DNS request, so the main problem is to determine the number of the UDP port used to send the request. However, as it was noted earlier, the range for the possible port numbers is limited (>= 1023). So, the attacker can simply try them all by sending fake responses to each port in the range. The second problem appears to lie in the two-byte ID of the DNS request, but as we mentioned above, in our case this ID is either equal to one or close to zero (for example, if the DNS request is sent by Netscape Navigator the ID is incremented by 1 with each request).
Fig. 2. Introducing a Fake Server in the Internet by Creating a "Flood" of Fake DNS Responses Directed towards the Attacked Host.
Therefore, in order to perform a remote attack the attacker should choose some interesting host (for example, top.secret.com) and change the route to this host to include a fake server - the attacker's host. This is achieved by continually sending fake DNS responses (a "flood") from the address of the real DNS server to the relevant UDP ports of the attacked host. These fake DNS responses contain the IP address of the attacker instead of the IP address of the top.secret.com. After that, the attack can continue using the following plan. When the target (the attacked host) tries to access the top.secret.com host, it sends out a DNS request to the network. The attacker will never receive this request, but she/he does not need it anyway because the attacked host will immediately receive a fake DNS response, and the OS of the attacked host will accept it instead of the real response from the DNS server. That is all! The attack is complete, and now the attacked host transmits all packets addressed to top.secret.com to the IP address of the attacker's host. This host, in turn, forwards them to top.secret.com, and manipulates them using the "Fake DCS Object " method.
Let us examine the functional scheme of the suggested remote attack at the DNS system (fig. 2):
Therefore, this remote attack uses the flaws in the DNS system security and makes it possible to break the routing between two specified hosts from anywhere in the Internet. This attack can be performed from another network segment, and presents a threat to any Internet host that uses an ordinary DNS service.
As it follows from the algorithm of remote DNS search described earlier, if the DNS server cannot find the requested name in its own name database it forwards the request to one of the root DNS servers.
So, in case the DNS server does not have information about the requested host, it can initiate a remote DNS search itself. Therefore, nothing can stop one from attacking the DNS server with the help of any method described above. In this case attack is targeted at the DNS server, not the host. The fake DNS responses should be sent from the IP address of the root DNS server to the target DNS server.
It should be borne in mind that in order to speed up its performance, each DNS server caches its table of host names and IP addresses in the memory. Among other things, it also caches the dynamically updated information about the names and the IP addresses of the hosts found during the previous searches. Therefore, when a DNS server does not find a record about some host in its cached table, it sends a request to the next server. When the response arrives, it adds this information to the cached table. Therefore, when the next request for the same name is received, the DNS server does not start a remote search once again as the required information is already available in its cached table.
The analysis of this remote search algorithm makes it clear that when the attacker responds to a DNS server request with a fake DNS response (or if it "floods" the server by continually transmitting fake DNS responses), the server adds a forged record to the cached table. After that, any host that requests information from this DNS server receives this forged data. Therefore, when some other host tries to access the host whose IP address was changed by the attacker, communication with this host is performed via the attacker's host in accordance with the "Fake DCS Object " plan. And what is even worse, as the forged information is located in the cache of the DNS server it will be spread among the lower-level DNS servers. Thus, as time passes, more and more Internet hosts become fooled and can be attacked!
It is clear that if the attacker cannot intercept a DNS request from the DNS server, she/he should send a "flood" of fake DNS responses to this DNS server. This leads us to another problem quite different from guessing the UDP ports which we were faced with during the attack on the host. As it was noted earlier, when a DNS server sends out a request to another DNS server, it includes a two-byte ID in this request. This ID is incremented by one in each request. The attacker cannot know the current value of this ID. Therefore, the only possibility is to try each of the 216 possible values of this ID. However, the problem of guessing the UDP port is gone as all DNS requests from DNS servers are sent to port 53.
The next point important for a successful remote attack on a DNS server by sending a "flood" of fake DNS responses is the fact that such an attack is only feasible if the DNS server sends out a request to find a name that is contained in the fake DNS response. A DNS server sends out this request that is coveted by and essential for the attacker when it receives a DNS request for this name from some other host, and this name is not available in the cached table of the DNS server. Generally, such a request can be created at any time, so the attacker can wait for the result of her/his attack for an indefinite period of time. However, nothing can stop the attacker from sending such a request to the target DNS server her/himself without waiting for other hosts, thus forcing the DNS server to initiate a search of the name specified in this request! In this case, there is a very good chance that the attack will be successfully completed immediately after it starts.
Fig. 3. Adding a Fake DNS Server to the Internet by Intercepting a DNS Request from the DNS Server.
Fig. 4. Adding a Fake DNS Server to the Internet by Creating a "Flood" of Fake DNS Responses Directed towards the DNS Server.
To conclude this chapter, we would like to return to the DNS system description and note that as our previous analysis shows, the presence of the DNS system in the Internet makes it possible to attack almost any Internet host remotely, and creates a big loophole in the tainted security of the global network. Remember what S.M.Bellovin said in his almost classical work: "A combined attack on the domain system and the routing mechanisms can be catastrophic".
| обсудить | все отзывы (0) | |
| [37573; 11; 5.72] |
|
|
|