>I am sorry to burst the bubble but this has been a known problem for >more than 5 years: Dear Iván, At first site It may looks like the vulnerability reported cited by you, but in fact It isn.t. The CERT did the same question when we were doing tests. Of course, if was the same attack released in 1993 the CERT had not released a Vulnerability Note. http://www.kb.cert.org/vuls/id/457875 >Original advisory posted in 1997: > >http://www.codetalker.com/advisories/sni/sni-12.html >http://www.corest.com/common/showdoc.php?idx=133&idxseccion=10 (spanish) I know this attack methodology. Christopher Schuba and Eugene Spafford outline this attack in the paper "Addressing weaknesses in the Domain Name System Protocol" in COAST Laboratory, Department of Computer Science, Purdue University, 1993. This attack is the simplest and most widely used attack to do DNS Spoofing on bind 8.1.x, 4.9.3, 4.9.5 and 4.9.6. Bind running with these versions increase the ID by 1 for each query. They don.t randomize the dns id. This is a problem of pedictable ID's and not the problem that I reported. The algorithm initially used to generate ID in BIND 8.1.x and 4.9.[3-6] u_int16_t nsid_next() { ! if (nsid_state == 65535) ! nsid_state = 0; ! else ! nsid_state++; return (nsid_state); } :-), :-) BIND Versions current (8.3.4, 4.9.11) and older (8.2.x, 9.x) are not vulnerable to the attack presented in this advisory (cited by you). However, I get to implement DNS Spoofing attacks remotely with very easily in the bind 8.3.4 ,4.9.11 and older bind, and I can prove THIS. The problem that I described attests BIND versions 4 and 8 do not prevent sending of two or more resolution requests for the same domain name allowing DNS Spoofing attacks with significant probability of success, then I implemented specific techniques (originals) to have good results in the attacks. In the link cited by you, the attacker has complete control of DNS.ATTACKER.COM's network, he can both spoof and sniff DNS packets there. In particular, he can sniff DNS packets sent to DNS.ATTACKER.COM. The attacker needs to get the IDs to send the replies. The attacker sniff DNS.ATTACKER.COM's local network and retrieve the query packet sent by DNS.TARGET.COM to DNS. ATTACKER.COM. He can then determine the query ID (qid0) and source port used by DNS.TARGET.COM. Chances are that the next queries generated by DNS.TARGET.COM will have query IDs that will fall in the range [qid0,qid0+N] where N is dependent on the amount of queries DNS.TARGET.COM is generating in the period of time on which the attack takes place. N is usually <= 15 for most cases. In this attack methodology (released by Schuba) is not implemented anything to determine the source IP address that should be used in the reply packet because the attacker get the victim DNS current ID (sniffing technique) and other. In my attack methodology, I implemented techniques to determine ID, Source IP address and the attacker can apply the attack successfully FROM any network. The attacker does not need to be at the same DNS.ATTACKER.COM's local network. The attacker does not NEED to sniff queries to determine the source port and ID. The success probability in my attack methodology to implement of DNS Spoofing attack in BIND 4 and BIND 8 is calculated by the equation: n-request-sent/65535, where n-request-sent is the number of requests sent simultaneously to the target DNS server. Another difficulty that I have in the remote attack is to imprecision from establishing the ID to be used in the replies. In example presented, the attacker doesn.t have difficulty because the his host keeps capturing all packets in its local net, applying a sniffer technique. ;-):-) >+ /* >+ * The 16 bit space is very small and brute force attempts are >+ * entirly feasible, we skip a random number of transaction ids >+ * so that an attacker will not get sequential ids. >+ */ Using only brute force, the attack is very difficult to be applied. I tried this several times. I did several tests in my experiments. The probability of success is very low to get implement the attack using only brute force. >I have not read BIND source for years, is this not explicitly mentioned >anywhere in the source or docs or updated RFCs?? However, I have read BIND source for months currently. The ISC has omitted the problem, but I think there is .people. exploiting the vulnerability that I reported in underground. wget ftp://ftp.isc.org/isc/bind/src/8.3.4/bind-src.tar.gz tar .xvzf bind-src.tar.gz cd src/bin/named The bug is in this file: src/bin/named/ns_forw.c In this function: int ns_forw(struct databuf *nsp[], u_char *msg, int msglen, struct sockaddr_in from, struct qstream *qsp, int dfd, struct qinfo **qpp, const char *dname, int class, int type, struct namebuf *np, int use_tcp, struct tsig_record *in_tsig) { .. //HERE for (qp = nsqhead; qp != NULL; qp = qp->q_link) { if (qp->q_id == id && memcmp(&qp->q_from, &from, sizeof qp->q_from) == 0 && ((qp->q_cmsglen == 0 && qp->q_msglen == msglen && memcmp(qp->q_msg + 2, msg + 2, msglen - 2) == 0) || (qp->q_cmsglen == msglen && memcmp(qp->q_cmsg + 2, msg + 2, msglen - 2) == 0) ) { ns_debug(ns_log_default, 3, "forw: dropped DUP id=%d", ntohs(id)); nameserIncr(from.sin_addr, nssRcvdDupQ); return (FW_DUP); } } } //Insert this line of code to correct the problem || (!strcmp(qp->q_name,dname)) ) for (qp = nsqhead; qp != NULL; qp = qp->q_link) { if (qp->q_id == id && memcmp(&qp->q_from, &from, sizeof qp->q_from) == 0 && ((qp->q_cmsglen == 0 && qp->q_msglen == msglen && memcmp(qp->q_msg + 2, msg + 2, msglen - 2) == 0) || (qp->q_cmsglen == msglen && memcmp(qp->q_cmsg + 2, msg + 2, msglen - 2) == 0) ) || (!strcmp(qp->q_name,dname)) ) // HERE { ns_debug(ns_log_default, 3, "forw: dropped DUP id=%d", ntohs(id)); nameserIncr(from.sin_addr, nssRcvdDupQ); return (FW_DUP); } } >BTW, what does BIND 9 do to prevent this? The BIND 9 doesn.t generate multiple simultaneous queries for the same resource record. Only THIS. The problem is in the BIND implementation. The ISC think not. However, you can see and analyze that an only code line resolve part of the problem. Of course It does not resolve problems of brute force attacks, but resolve the problem that I reported. || (!strcmp(qp->q_name,dname)) ) If the ISC and other vendors correct their code, they will reduce almost 98% success probability of an attacker to implement the attack remotely. The 2 % is attacks successfully via brute force. >> . configure anti-spoofing rules on the firewall or border router; >> >> . considering the network topology, set up the DNS server into a DMZ >> (demilitarized zone). > >Maybe I am missing something but how will this prevent cache poisoning >of the DNS server in the DMZ? (assuming it does recursion) >Inbound DNS replies (with spoofed source IP address) to >DNS requests forwarded to Internet servers will look perfectly valid to the >border router or firewall. This way (DNS in the DMZ), you can to dropp packets sent to your DNS that are using spoofed source IP address of your local network. This is the first step to implement attack. The attacker has to do the target DNS server to generate multiple simultaneous queries for the same rr. If you has configured this option in named.conf: allow-query{IP-internals;}; the attacker will try use IP-internal to generate the queries for the same rr. If the ISC doesn.t correct the problem, perhaps, I can send the exploit that I implemented to the list (bugtraq and other). I can assure that I get to implement DNS Spoofing attacks with high probability of success with very facility in BIND 8.3.4 and 4.9.11 (Released November 16th, 2002 by ISC) Iván, thanks by observations. Regards, Vagner Sacramento
