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.
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):
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.
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.
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.
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:
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:
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:
Now modify the reverse DNS zone file (/etc/bind/zones/rev.0.168.192.in-addr.arpa):
And finally restart the bind and alter /etc/resolv.conf to:
To check whether everything went as planned look-up a domain like so:
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:
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.
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:
Red packet:
Blue packet:
For the purpose of this, below I've visualized it within another scheme (correspondingly for the green, red and blue packets):
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).
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:
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:
Show spoiler
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.
0 comments:
Post a Comment