|
Feeds -
Exploits
|
|
Written by Kevin Day
|
|
Friday, 20 February 2009 20:23 |
djbdns dnscache SOA Requests Remote Cache Poisoning Vulnerability
-\\Bugtraq ID:
33818
-\\Class:
Design Error
-\\CVE:
CVE-2008-4392
-\\Remote:
Yes
-\\Local:
No
-\\Published:
Feb 09 2009 12:00AM
-\\Updated:
Feb 20 2009 05:07PM
-\\Credit:
Kevin Day
-\\Vulnerable:
djbdns djbdns 1.05
-\\Discussion
The 'djbdns' suite is prone to a remote cache-poisoning vulnerability.
An attacker may leverage this issue to manipulate cache data, potentially facilitating man-in-the-middle, site-impersonation, or denial-of-service attacks.
This issue affects djbdns 1.05; other versions may also be vulnerable.
-\\Exploit(s)/PoC(s):
Below is a description of how dnscache was successfully exploited. The domain to be hijacked has
two nameservers that are authoritative for it, NS1 and NS2. They are both running tinydns from
djbdns-1.05, the latest currently available.
They publish one A record, the correct IP for www.example.com, 1.2.3.4:
;; QUESTION SECTION:
;www.example.com. IN A
;; ANSWER SECTION:
www.example.com. 86400 IN A 1.2.3.4
;; AUTHORITY SECTION:
example.com. 259200 IN NS ns1.example.com.
example.com. 259200 IN NS ns2.example.com.
The intended victim is running dnscache from djbdns-1.05. The victim takes approximately 120ms to
get a response from the authoritative servers, due to their geographic distance and network latency.
The attacker is physically located in a different datacenter in the same city, with approximately
20ms latency between it and the victim. This simulates a customer/ISP relationship, showing how a
customer could poison their own ISP's server relatively easily.
*Attack
The attacker sends 200 SOA requests to the victim, in order to immediately fill as many outgoing
UDP slots as possible. It then begins sending SOA requests and spoofed SOA replies in a pattern;
75 spoofed SOA replies, followed by another SOA request. The exact numbers don't matter, but the
goal is to keep all 200 UDP requests on the victim busy as close to 100% of the time as possible. The
spoofs alternate between the source IPs for NS1 and NS2.
A legit reply for the SOA record contains:
;; QUESTION SECTION:
;example.com. IN SOA
;; ANSWER SECTION:
example.com. 2560 IN SOA ns1.example.com. hostmaster.example.com. 1217307566 16384 2048 1048576 2560
;; AUTHORITY SECTION:
example.com. 259200 IN NS ns1.example.com.
example.com. 259200 IN NS ns2.example.com.
;; ADDITIONAL SECTION:
ns1.example.com. 86400 IN A 1.4.4.4
ns2.example.com. 86400 IN A 1.5.5.5
A spoofed reply for the SOA record contains:
;; QUESTION SECTION:
;example.com. IN SOA
;; ANSWER SECTION:
example.com. 2560 IN SOA ns1.example.com. hostmaster.example.com. 1217307566 16384 2048 1048576 2560
;; AUTHORITY SECTION:
example.com. 259200 IN NS ns1.example.com.
;; ADDITIONAL SECTION:
ns1.example.com. 86400 IN A 2.1.1.1
www.example.com. 86400 IN A 2.2.2.2
Here, we replace www.example.com with an IP of our choosing, and for good measure replace one of
the nameservers with our own IP too. We could easily replace this with replacing both nameservers,
replacing several other hosts, MX records to redirect email or whatever we choose. After a successful
poisoning, dnscache believes the new addresses listed in the spoof section, and will cache them for as
long as we ask.
-\\Solution
Currently we are not aware of any vendor-supplied patches. If you feel we are in error or if you are aware of more recent information, please mail us at:
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
.
-\\References(s)
--djbdns Home Page
http://cr.yp.to/djbdns.htm (djbdns)
--djbdns patches
http://www.your.org/dnscache (Your.Org)
--Rapid DNS Poisoning in djbdns
http://www.your.org/dnscache/djbdns.pd (Kevin Day)
|
