wyc0 / rebind Goto Github PK

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.

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. Victim queries DNS to connect to hfrcc.attacker.com/exec
9. Rebind responds with Attacker IP and Victim IP
10. Victim does HTTP GET to /exec, connecting to Attacker IP
11. Rebind responds with javascript code to setup callbacks etc, brings up 
iptables firewall to REJECT traffic
12. javascript connects to hfrcc.attacker.com/, connects to rebind first 
(thanks to DNS Pinning)
13. rebind connection fails (thanks to iptables in step 11)
14. Victim successfully connects to next IP address (Victims Modems IP)
15. Calls to hfrcc.attacker.com now will connect just to the victims modem
16. Victim connects to rebind callback port for a /poll request
17. Rebind responds with JavaScript callback request() <- this is the message 
that is causing issues

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

Step 17 responds with the standard HTTP Headers, with the additional javascript:

##############################
request('4','/',NULL,'Host: victimIP%%User-Agent: <snip>');
##############################

This calls the request function already setup during step 11, the NULL value is 
indicating there is no POST data to send. Unfortunately Internet Explorer 8 
interprets this NULL as a variable, IE8 expects a null string to be written in 
lower case. For example:

##############################
request('4','/',null,'Host: victimIP%%User-Agent: <snip>');
##############################

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

Internet Explorer 8.0.6001.18928, with Windows Vista.

Please provide any additional information below.

I've created a small patch file I was able to apply to resolve the issue for 
me. The changes are probably not in the preferred section, but it will 
hopefully be enough to demonstrate the issue. See attached patch file.

1. How do I know the attack is successful? Is not can login victim router at 
attacker browser?
2. I sniffer packet at victim router WAN site and check victim router public IP 
have to establish session to attack tool (rebind) port 81.
but this test step have any important information for attacker? 

In many cases DNS queries will contain a mixed-case domain name as a mean of 
additional security. The DNS server included fails to parse mixed-case domain 
names due a case-sensitive comparison. 

Example: nslookup yourdomain.com 167.206.245.135

Line 92 & 93 of dns.c seem to be the fail point

fqdn_offset = strstr(question_domain,fqdn);
if(fqdn_offset == NULL || (fqdn_offset && strlen(fqdn_offset) != strlen(fqdn))){

***References***

-Increased DNS Forgery Resistance Through 0x20-Bit Encoding

http://webcache.googleusercontent.com/search?q=cache:_LzckuNoOSYJ:courses.isi.jh
u.edu/netsec/papers/increased_dns_resistance.pdf