Full Disclosure mailing list archives
Re: DNS spoofing issue. Thoughts on potential exploits
From: "Troy Xyz" <fatpodesta () gmail com>
Date: Thu, 24 Jul 2008 23:41:45 +0300
I am now posting some analysis I wrote on the subject right after my last post. Since the exploits are now available too, this should primarily be helpful to the good guys. I wrote this without full details of the exploit, but it shoud all be pertinent nonetheless. It might help in some cases where there are firewall issues. I also propose a new solution. No response from ISC, so I don't know if they disagree or what. Anyway, this is my contribution. I hope it helps somebody. Cheers. -fatpodesta Further notes: 1. Using a dedicated nameserver for SMTP leaves the system susceptible to attacks on the mail system. To fix this too, the HELO checks must be removed from the mail system and moved to a separate HELO checking system (e.g. milter). The mail server can then be changed back to using the normal nameserver. 2. It should be noted that when resolvers and nameservers are configured to use random source ports, both the firewall between the internal LAN and DMZ and the firewall in between the DMZ and the Internet must allow for the random ports. 3. What is always required is a machine where the user has the ability to write packets to the network with any IP. This usually means super user access. It is difficult in most cases to send udp packets with forged IP since routers will not accept them. That is why it is difficult to conduct an attack against a random target. In certain situations, however, faking IPs is possible. The machine must also be somewhere in the path between the two networks, Company A and SiteB, so that packets released on the network get routed to the target IP (A or B). This scenario is realized if the attacker has access to a machine on the same LAN with Company A's nameservers. If the nameservers are (a) inside a DMZ (a LAN in between two firewalls, one to the company's internal LAN and one to the Internet). (b) on a company's internal LAN. (c) on a LAN directly connected to the Internet. In all scenarios, the attacker must get access to the LAN or in case (c) to the ISP's LAN which connects Company A to the Internet. The attacker can get access to the LAN in one of the following ways: 1. client virus (only works in scenario (b). 2. break-in to the server itself. 3. break-in to a machine on the same LAN. 4. If the server is in a virtualized environment, access to any kernel running on the hardware, and configured to use the same LAN. This can happen if the server is hosted on a service provider's virtualized machine. 5. break-in to the router/firewall which connects the nameservers to the Internet. Scenario 1 is feasible. The solution is to run servers inside a DMZ. Running them on a LAN is just not smart. Environments where servers are not inside a DMZ are inherently not secure because packets can be forged too easily. Scenario 2 with root access makes it unnecessary to go through the hassle of spoofing. Scenario 3 is feasible. Scenario 4 is feasible. Scenario 5 is the only on in which case nothing works. If the attacker gets access to the router/firewall, then even random ports will not help. This scenario exposes servers to so many possible attacks that guarding against them is seemingly impossible. I would have to say that this scenario should be excluded from this discussion because not only DNS, but all protocols which do not use cryptographic checks are vulnerable. All environments where machines share a LAN so that sniffing packets is possible from machines other than the sender/router/firewall/recipient pose a security risk from all kinds of attacks. Networks should be designed so that sniffing is not possible. In addition, if networks connected to the nameserver allow packets with any source address, then additional attack vectors become possible. Any DMZ should only allow packets with internal network IPs from the internal network, and others only from the Internet. If such strict checking is not enabled, attacks against a server inside a DMZ become possible even from the internal LAN. Consequently, only scenarios 3 and 4 are worthy of contemplation in this case. In both cases, if the attacker is able to sniff traffic on the network, it can always succesfully conduct the above mentioned attack, since it then knows the ID, the IP and the port. Randomizing the port works even when the attacker can sniff the network, because there is no time for the attacker to do a DOS against the legitimate nameservers. If randomizing is not possible, servers should be protected against sniffing by using hardware solutions which make it impossible. This should be done in any case, since sniffing exposes traffic to analysis, which can expose other vulnerabilities on the network. In the case of virtualized servers, if this is not already done, then it should be. Other apps which use udp could have similar problems. I would think that only protocols which can be invoked by a remote user face similar risks. Therefore the obvious udp using protocols such as RPC and NTP are excluded. Attack against client resolvers: A LAN attack works if the attack is conducted against individual client machines. The attack makes client+resolver "A" and the caching nameserver "B." In this case it is sufficient to get a virus in one client machine and conduct attacks from there. There is no need to poison the cache on the caching nameserver if all clients' caches can be poisoned. Poisoning the nameserver cache is only possible if the firewall between the internal LAN and the DMZ allows packets with external IPs to pass. In terms of getting the client's resolver to make queries, the question is how? Images on web pages can trigger a DNS query. Javascript, java and flash can also be used to trigger DNS queries. Another potential way to trigger a DNS query is if the client uses software which resolves IPs. Firewall logging software might do this. This would only be a threat to the arpa domain for resolving IPs, though. Javascript, java and flash pose a real threat, since the client can be forced to query any list of hostnames. An attack would need to coordinate the two attacks, so this seems a bit complicated. OTHER SOLUTIONS: The randomized port solution essentially makes it more difficult for an attacker to guess what data is sent by the resolver/nameserver in its query packets. With only a 16 bit ID, there are 2^16 values to guess. With the added ports, there are 2^32-1024 possibilities. It also makes a DOS impossible. The exactly same effect (except for the DOS) could be achieved by adding 2 bytes to the ID, or by using 2^16 random IPs to send the query. The random IP solution is not practical. Adding more bits to the ID is feasible only through modifications to the DNS protocol. Any changes would have to be backwards compatible, so as not to break compatibility with unpatched systems, or systems which use the random port solution. Where to add the extra bits? (a) use qdcount and ancount fields (both 16 bits) to send the extra ID bits. A query has an unused ancount and a response has an unused qdcount, so these are available. (b) always send two questions (qdcount always >= 2). The second question should be a for a random name. The response doesn't matter, as long as it contains the random name. (c) add RR (resource record) data with the extra bits. This is probably the easiest one to implement, and is also what is used by DNSSEC. A new type would need to be added, called DNSID or something of the kind. Solutions (b) and (c) have the advantage that more than 16 bits of randomness can be added, making guessing even harder. The other benefit of random source ports is that a DOS against the nameserver will not succeed. Using more random bits in the DNS packet will still allow for the DOS. A disadvantage of random source ports is that it adds burden to the network, especially for large installations. Another disadvantage of random ports is that if the attacker is able to induce the attacked system to use many of its ports, with the information on the ports available to the attacker (e.g. through sniffing or by forcing the nameserver/resolver to query hosts whose DNS was under the attacker's control), randomness is reduced. It should be fairly easy for an attacker to force a large number of queries to its own nameservers within a short period of time, thus reducing the available port range considerably. Also, most systems (at least GNU/linux and windows) allow the user to limit the number of ports available for outgoing connections. This will also reduce randomness. A third disadvantage of random ports is that large installations might have difficulty with only 2^16-1024 available connections for all udp traffic. A cryptographic solution such as DNSSEC would also solve the problem, since faking responses wouldn't be possible. A DOS should still be possible even with DNSSEC. The difficulty with DNSSEC is its slow implementation. DNSSEC adds extra data to DNS packets, just as the above mentioned solution (adding extra bits to the ID) does, and is also backwards compatible. The advantage of the solution above is that it doesn't necessitate signing of DNS records, and can thus be implemented through regular software updates. A disadvantage of the above mentioned solution with extra bits of randomness is political. Would it slow down the spread of DNSSEC? My speculation is that it wouldn't, since it wouldn't diminish the additional benefits of DNSSEC, which are, namely, integrity of records for owners of domains. A more serious disadvantage is that both the authoritative nameserver and the caching nameserver have to implement the solution against attacks from the Internet. As a solution to maintain compatibility with unpatched systems, caching nameservers could disable caching for responses where extra ID bits are not included. Attacks from the LAN do not suffer from this issue with the same acuteness, since only the caching nameserver and clients need to be updated. Client resolvers can be configured to disallow responses without the extra ID bits, since they only use one nameserver for all their queries. We can also conclude that the issue under discussion exposes a vulnerability also in DNSSEC, since clients who make queries cannot know whether a particular domain uses DNSSEC or not before they make a query. Thus, if an attacker can DOS a caching namserver or an authoritative nameserver, he can also send fake data to the client, who is none the wiser. If an external mechanim is used to verify the existence of DNSSEC for a particular domain, then spoofing wouldn't work. I am not familiar enough with the details of DNSSEC implementations to say whether this is the case. Using TCP will remove the possibility of a spoofing exploit. A DOS would still be possible. A disadvantage of TCP is that it is heavier on networks because if multiplies the number of packets sent. The best solution in my mind would be to combine the information we have and device a solution as follows: Add at least 16 bits to the ID. Send a normal UDP query from a static port. Only allow several seconds for the nameserver to respond. If a response is not received, wait and try again with a new ID. Reject messages received after the window has passed. The key is to not resend a query with the same ID. The second query uses TCP (which always uses a random source port) or a random UDP port. This would solve the DOS issue without adding burden to the network in most cases, since only one source port and UDP would be used in normal situations. Since TCP would only be used when a DOS is taking place, or during congestion, normal DNS related packets wouldn't increase. Systems able to implement source port randomization for UDP would be able to use UDP. Installations without source port randomization for UDP would be able to use TCP. Adding bits to the dns IDs will achieve better randomness without adding but a minimal amount of burden to the network (using the qdcount and ancount variables, no burden is added). Using random UDP source ports or TCP only on the second query will reduce the burden on firewalls. All systems could protect themselves against a DOS and against the spoofing exploit. END
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Re: DNS spoofing issue. Thoughts on potential exploits Troy Xyz (Jul 24)
- Re: DNS spoofing issue. Thoughts on potential exploits list-fulldisclosure (Jul 24)
- Re: DNS spoofing issue. Thoughts on potential exploits Mark Andrews (Jul 26)
- Re: DNS spoofing issue. Thoughts on potential exploits list-fulldisclosure (Jul 24)