Introduction Have you ever thought about how to access a victim's internal network without running Malware on his computer or using 0day?
The result is that you open your browser, wait until the victim visits your website, and then start browsing the internal websites in their network. It’s a great tool especially if you’re part of a red team. We recommend you read more about DNS Rebinding in this link.
Let's try to understand the mechanism
In the picture above you can see the browser of the victim who makes a connection calles to different IP addresses, when the red arrows indicate a connection to an IP address that unreachable on the network, while the black arrows indicate IP addresses are reachable on the network. When an internal IP address is dialed on the network, the browser querying the router whether it knows the IP address, if he knows it, he will return a quick reply to the fact that the port is closed and therefore we will receive a quick answer about the closed port and we'll get an error about the rejected connection - so far it's clear. If we try to access an unreachable IP address, the browser will wait for timeout and we will be able to know for certain IP address is unreachable. It's important to note that each browser has its own limitations, such as the method we mentioned will work on Google Chrome but will not work in FireFox. However, in FireFox, we can send many more requests at the same time so we will not have to use this method just to know that we are only sending requests to reachable IP addresses.
Disclosure of internal IP address: In order to discover the internal IP address we used WebRTC Example script:
Detection of IP addresses on the network: To discover the reachable IP addresses in the network we used with timing attack via Ajax requests. The example script you can find here
Discover open ports that contains HTTP services: To discover open ports based on HTTP services, we created a DOM event whose source points to the port we are checking. according to the timings and events we will know if behind this port there really is an HTTP service, the event we need is "onload" event, if "onload" event is called then there is an HTTP service port behind it. A sample script can be found here The following illustration presents the RedTunnel architecture and explains the processes behind the scenes:
The victim browses to a site that contains the ReDTunnel (Core). the ReDTunnel Core service contains both the attack side and the management side.
ReDTunnel collection of victim's Information: Finding the victim's internal address, using the internal address to scan the IP addresses on the victim network, then find HTTP services on the victim’s network IP addresses. And of course reporting all findings to the ReDTunnel (Core) management server.
While victim's data is collected, the DNS Rebinding attack is executed automatically (via communication between the Core service and the DNS service.)
The attacker uses the Admin interface to browse applications on the victim's network or on the victim's computer (localhost) using his own browser and can even run automated scripts like SQLmap (if you send the ReDTunnel cookie content.)
In conclusion The ReDTunnel tool redefined the Rebinding DNS attack by automating the attack, gathering the information before the attack and the management of the victims in a safe and sophisticated manner allows the attacker to physically surf the internal network of the victims and run automatic tools on them, as well as the PATCH / PUT / DELETE methods and Basic Authentication Login for the attacker.