>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]
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
>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)
>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
[ reply ]