Rebind and Victim IP in A Record Response Issues with DNSSEC and/or EDNS

[GoogleCodeExporter]

What steps will reproduce the problem?

Using steps in: 
https://media.blackhat.com/bh-us-10/whitepapers/Heffner/BlackHat-USA-2010-Heffne
r-How-to-Hack-Millions-of-Routers-wp.pdf

1. Prepare example scenario
2. Sign up domain with registrar 
3. Configure domain NS records to point to attacker
4. Connect to http://attacker.com/init/
5. Rebind responds with it's own IP
6. HTTP GET to /init
7. Rebind Sets Location header to random sub domain of attacker.com (eg 
hfrcc.attacker.com
8. Instead of victim's web browser sending request - use dig to simulate DNS 
requests from the victim's IP.

What is the expected output? What do you see instead?

My issue was an A request for hfrcc.attacker.com was only responding with the 
IP address of rebind it does not include the IP address of the victims router 
(at this stage it should). 

For example:

This output shows a request from the victim directly to rebind using dig. As 
you can see, this output looks correct, the A record has both rebinds 

IP and the victims IP. 
######################################################
Command: dig @rebindIP hfrcc.attacker.com
######################################################

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> @rebindIP hfrcc.attacker.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40990
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;hfrcc.attacker.com.   IN      A

;; ANSWER SECTION:
hfrcc.attacker.com. 5  IN      A       rebindIP <- both results within Answer 
Section
hfrcc.attacker.com. 5  IN      A       victimIP <- both results within Answer 
Section

;; Query time: 21 msec
;; SERVER: rebindIP#53(rebindIP)
;; WHEN: Fri Aug  6 20:12:31 2010
;; MSG SIZE  rcvd: 77

######################################################

However, when I made the queries using our local ISP's DNS Cache, the results 
were exactly the same but without the victims IP. I noticed the only 

difference between my DNS queries and my ISP's queries was my ISP's queries 
"set the DNSSEC OK bit (DO) in the OPT record in the additional section 

of the query.". Whether setting this bit was actually the cause, I don't know - 
but when dig was given the +dnssec option, I was able to reproduce 

the issue. 

In the previous example out, the dnssec option was not set, in this example, 
the only difference is setting the dig option +dnssec. Instead of the 

victimIP being within the Answer Section, it is within the Additional Section 
(which never made it through my local ISP's DNS Cache). 

######################################################
Command: dig @rebindIP hfrcc.attacker.com +dnssec.
######################################################

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> @rebindIP hfrcc.attacker.com 
+dnssec
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40468
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 2048
;; QUESTION SECTION:
;hfrcc.attacker.com   IN      A

;; ANSWER SECTION:
hfrcc.attacker.com. 5  IN      A       rebindIP <- result within Answer Section

;; ADDITIONAL SECTION:
hfrcc.attacker.com. 5  IN      A       victimIP <- result not within Answer 
Section

;; Query time: 27 msec
;; SERVER: rebindIP#53(rebindIP)
;; WHEN: Fri Aug  6 20:12:32 2010
;; MSG SIZE  rcvd: 88

######################################################

What version of the product are you using? On what operating system?

Rebind v0.3.2
Server: Linux 2.6.20 i686
Victim: Windows 7 64bit / Mozilla Firefox 3.6.8
Victim DNS Queries were from a virtual guest NAT'd behind the Victims IP. 
CentOS 5 x86_64.

Please provide any additional information below.

I noticed direct queries using dig set the recurse bit, whereas my local ISP 
did not. Whether I ran dig with recurse set or not set, I was unable to 
reproduce the issue.

Also I am not convinced this is an issue within rebind at all. I believe it 
could be an issue with our local ISP and it's handling of EDNS. The client 
isn't requesting/advising support for EDNS (via the OPT flag) but the DNS Cache 
is asking other name servers to support it (it's queries are setting OPT which 
I assume is for DNSSEC). The results given back to the DNS Cache include the 
Answer of rebindIP and an Additional Answer of victim IP, instead of both of 
the IP's appear in the Answer section. The DNS Cache responds to the client, 
stripts out Additional Answer section and the client is left with just the 
rebind IP. What I don't know is who is at fault there, should rebind only be 
answering in the Answer section or because EDNS is reported, it must use the 
Additional section ?

Also, no useful logs have been displayed with rebind.db. I can reproduce this 
with public details off list if required.

Original issue reported on code.google.com by bradstaone@gmail.com on 6 Aug 2010 at 3:33

[GoogleCodeExporter]

I'm looking into the issue, and it is reproducible. Based on my initial 
testing, this looks like a bug in Rebind; the code will likely have to be 
updated to explicitly handle queries with the OPT flag set.

Original comment by heffne...@gmail.com on 7 Aug 2010 at 8:37

[GoogleCodeExporter]

Update: I've confirmed that this is a bug in the Rebind DNS server. With OPT 
set in the DNS request, Rebind places the OPT response in the Answers section 
instead of the Additional Records section of the DNS response packet. This 
makes the second IP address (that of the victim IP) appear as part of the 
Additional Records section. 

Original comment by heffne...@gmail.com on 7 Aug 2010 at 8:48

[GoogleCodeExporter]

Bug fixed. DNS responses for dnssec and non-dnssec lookups both report the 
correct IP addresses in the answer section:

##########################################################################
user@machine:~$ dig @<rebind IP> wacme.attacker.com
##########################################################################

; <<>> DiG 9.7.0-P1 <<>> @<rebind IP> wacme.attacker.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5352
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;wacme.attacker.com.            IN  A

;; ANSWER SECTION:
wacme.attacker.com.     5   IN  A   <rebind IP>
wacme.attacker.com.     5   IN  A   <target IP>

;; Query time: 47 msec
;; SERVER: <rebind IP>#53(<rebind IP>)
;; WHEN: Sat Aug  7 19:47:19 2010
;; MSG SIZE  rcvd: 62

##########################################################################

##########################################################################
user@machine:~$ dig @<rebind IP> wacme.attacker.com +dnssec
##########################################################################

; <<>> DiG 9.7.0-P1 <<>> @<rebind IP> wacme.attacker.com +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30948
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;wacme.attacker.com.            IN  A

;; ANSWER SECTION:
wacme.attacker.com.     5   IN  A   <rebind IP>
wacme.attacker.com.     5   IN  A   <target IP>

;; Query time: 47 msec
;; SERVER: <rebind IP>#53(<rebind IP>)
;; WHEN: Sat Aug  7 19:47:22 2010
;; MSG SIZE  rcvd: 73

##########################################################################

Code changes should also enable Rebind to handle other types of DNS requests 
that have Additional sections.

Original comment by heffne...@gmail.com on 8 Aug 2010 at 12:16

• Changed state: Fixed

[GoogleCodeExporter]

Perfect, can't reproduce this issue with version 0.3.3 any more on ISP's DNS.

Thanks

Original comment by bradstaone@gmail.com on 8 Aug 2010 at 1:10

[GoogleCodeExporter]

Awesome, thanks for the bug report and verification. Marking bug as verified.

Original comment by heffne...@gmail.com on 8 Aug 2010 at 1:17

• Changed state: Verified