Full Disclosure mailing list archives
DNS spoofing issue. Thoughts on potential exploits
From: "Troy Xyz" <fatpodesta () gmail com>
Date: Thu, 17 Jul 2008 18:59:07 +0300
Hi, I am troubled by these kinds of solutions which only help administrators with standard distributions. Any kind of deviation from the norm, and it will be impossible to fix one's servers, or assess possible vulnerabilities. I wanted to understand how someone could exploit this flaw against systems I deal with, so I wrote some scenarios on how DNS could be exploited in general. I believe the exploit, which is now unpublished, will probably be something along the lines below. Of course I could be wrong. These are just my thoughts. First we have to understand the variables involved. They are: -Client+resolver. -Caching name server used by client. -Authoritative name server for a domain. As far as I know, the attack enables an attacker to cause false DNS data to be served to clients. This implies that clients are affected because they can be misled to fake sites. It also implies that domains can be compromised because e.g. mail directed at them doesn't arrive, but is directed to an attacker's site. This would only apply to specific clients, of course, but creates a serious problem if one really thinks about it. Here are my thoughts: Possible attack vector No. 1: 1. EvilIP wants to redirect traffic from Company A, intended for SiteB, to EvilSiteX. 2. EvilIP sends a large number of queries to SiteB's nameservers, using Company A's nameserver IP and port (i), making the packets look as valid as possible, with random IDs and the port used by Company A's nameserver for outgoing queries (ii). 3. EvilIP connects to Company A's caching nameserver, and queries for SiteB's DNS info (iii). 4. Company A's nameserver sends a query to SiteB's nameserver. 5. SiteB's nameserver doesn't respond to Company A's nameservers' requests, as it considers them to be a DOS attack. All queries appear to come from the same IP and port, using various valid IDs. 6. EvilIP can now iterate through the ID address space of valid IDs, sending responses to Company A's nameservers, using SiteB's nameservers' IP in the udp packet. The port number (53) is inconsequential, since Company A's nameservers have no information on it. 7. One of the packets matches the ID of the query and is accepted by Company A's nameserver. The result is stored in cache. 8. Future queries made by clients using Company A's nameservers will receive the entry sent by EvilIP. (i) We assume Company A has one nameserver for simplicity's sake. The same method can be used for multiple nameservers. (ii) EvilIP can find out the outgoing IP used by Company A's nameservers by making them send queries to a nameserver which is controlled by EvilIP. Information on the IDs can also be gathered this way. (iii) Step 3 can be achieved by connecting to Company A's SMTP server, and using Site B as HELO. Unless the SMTP server is using a dedicated nameserver, it will query Company A's nameservers. Possible attack vector No. 2: An attack can also be done against the resolver. This involves a DOS between the client and the caching nameserver. Otherwise the attack is the same. Solutions: Randomizing ports: If the caching nameserver randomizes its source port, EvilIP will not be able to create a DOS because SiteB's nameservers will only consider invalid queries to be those on ID/port pairs with too much traffic. The DOS attack might still work if EvilIP is able to flood all possible IP/port pairs. This depends on the amount of the time SiteB's nameservers refuse to accept packets from Company A's nameservers. If the window is too long, EvilIP is able to flood all of them. This still leaves the issue that EvilIP will also have to send packets to all ports on Company A's nameservers. Since there are {possible IDs} * {possible ports} possibilities, a practical attack is made unfeasible. If there is a firewall in between the Internet and the caching nameserver, it must be made sure that incoming traffic to UDP ports 1024 and above are allowed. If NAT is used, it must be made sure that it doesn't alter the source port of UDP packets. If it does, those ports must be randomized as well. Port randomization in NAT can also replace it in the name server. Without random ports: A. If randomizing ports is not feasible either at NAT or nameserver level, the caching nameserver should not be exposed to clients outside the LAN. An SMTP server should be configured to use a dedicated DNS server, or one which does port randomization. This approach still leaves the caching nameserver vulnerable to attacks from the LAN. This can occur if one of the clients on the network is compromized (virus etc.). B. If TCP is used, an attack of this type is not possible. -fatpodesta
_______________________________________________ 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:
- DNS spoofing issue. Thoughts on potential exploits Troy Xyz (Jul 17)