DNS Rebinding

Blog on how DNS Rebinding is exploited with a HackTheBox Challenge

In this blog we will take a look at how adversaries use DNS Rebinding technique to bypass ip restrictions to access the prohibited internal enterprise network and ex-filtrate sensitive data.

First we will take a look at how DNS Rebinding techniques work with a simple example. Then we will perform DNS Rebinding on a challenge from Hackthebox called BabyCachedView.

Note - The references for all the information will be available in the references section

DNS Rebinding Explained

DNS rebinding is a method of manipulating resolution of domain names that is commonly used as a form of computer attack. In this attack, a malicious web page causes visitors to run a client-side script that attacks machines elsewhere on the network.

DNS rebinding establishes communication between the attacker’s server and a web application on an internal network through a browser. To explain how this works, let’s first look at two concepts: same-origin policy (SOP) and time to live (TTL).

Same Origin Policy

The same-origin policy is a web browser security mechanism that aims to prevent websites from attacking each other.

The same-origin policy restricts scripts on one origin from accessing data from another origin. An origin consists of a URI scheme, domain and port number. For example, consider the following URL:

http://normal-website.com/example/example.html

This uses the scheme http, the domain normal-website.com, and the port number 80. The following table shows how the same-origin policy will be applied if content at the above URL tries to access other origins:

Time To Live (TTL)

In a DNS system, time to live defines the amount of time in seconds that a record can be cached before a web server will re-query the DNS name server for a response. For example, a 300-second TLL keeps records for five minutes. After that, the records become stale and will not be used. TTL is usually set by the authoritative name server of a domain.

DNS Rebinding

The same-origin policy identifies different origins with the combination of URI scheme, hostname and port. Among these components, browsers rely on hostnames to recognize different servers on the internet. However, hostnames are not directly bound to network devices. Instead, they are resolved to IP addresses by DNS. Then, IP addresses bind to devices statically or dynamically. Since domain owners have complete control of their DNS records, they can resolve their hostnames to arbitrary IP addresses. The DNS rebinding attack abuses this privilege. After the victims' browsers load the attacking payloads from the hacker's server, attackers can rebind their hostnames to internal IP addresses pointing to the target servers. This allows attackers’ scripts to access private resources through malicious hostnames without violating the same-origin policy.

Refer the image below form PaloAlto blog (Link in the references)

The above figure demonstrates the mechanism of a DNS rebinding attack with a hypothetical example.

  • In this example, the victim, Alex, has a private web service in his internal network with IP address 192[.]0.0.1. This server contains confidential data and is supposed to be accessed by Alex's computer only.

  • On the attack side, Bob controls two servers: a DNS resolver (1[.]2.3.4) and a web server (5[.]6.7.8) hosting the malicious website. In addition, Bob registers a domain, attack[.]com, with its nameserver (NS) record pointing to 1[.]2.3.4.

  • When Alex opens attack[.]com in his browser, it sends a DNS request to Bob's resolver and retrieves the address of the malicious server, 5[.]6.7.8

  • Once loaded in Alex's browser, the malicious script in Bob's website attempts to trigger another DNS resolution for its own domain. However, this time the resolver will return 192[.]0.0.1 instead

  • So attack[.]com is rebound to the target IP address. After that, the malicious script can keep sending requests to attack[.]com, which eventually reach the private server. Since Alex's browser won't recognize these requests as cross-origin, the malicious website can read the returned secrets and exfiltrate stolen data as long as it's open on the victim's browser.

Exploitation Example

Now we have the basic knowledge of how DNS Rebinding works, we can take a look at similar example from a challenge from Hackthebox called Baby CachedView

To begin with start the instance and download the required file. The zip files will contain source code of the application.

In the search field we can see an example query to the google's URL. We can take it as a hint to solve this

Source Code Analysis

Open routes.py

The /flag endpoint will give us access to the flag but there is a decorator called @isfromlocalhost that has reference to utils.py. The /cache endpoint returns a function cache_web function from utils.py

Open utils.py

In the cache_web function there are restrictions on IP addresses in the function, mainly on the 127 network segment, the 172.16 network segment, and the 192.168 network segment.

def is_from_localhost(func):
    @functools.wraps(func)
    def check_ip(*args,** kwargs):
        if request.remote_addr!='127.0.0.1'or request.referrer:
            return abort(403)
        return func(*args,** kwargs)
    return check_ip

If /flag the path is accessed, it will be processed in the decorator, check_ip and if it is not a local address (127.0.0.1), it will be prohibited.

Exploitation

No we understood the logic behind the application, we can move towards exploitation. You can register your own attacker server or use already registered dns in this we will be using google.com ip address to bind it with the localhost address -> 127.0.0.1

For this to happen there is a website called

In simple words in the above image the website will bind the address B with address A. First getting the google ip address

root@kali ~/h/cached_view# dnsrecon -d google.com
[*] std: Performing General Enumeration against: google.com...
[-] DNSSEC is not configured for google.com
[*] 	 SOA ns1.google.com 216.239.32.10
[*] 	 SOA ns1.google.com 2001:4860:4802:32::a
[*] 	 NS ns1.google.com 216.239.32.10
[*] 	 NS ns1.google.com 2001:4860:4802:32::a
[*] 	 NS ns3.google.com 216.239.36.10
[*] 	 NS ns3.google.com 2001:4860:4802:36::a
[*] 	 NS ns2.google.com 216.239.34.10
[*] 	 NS ns2.google.com 2001:4860:4802:34::a
[*] 	 NS ns4.google.com 216.239.38.10
[*] 	 NS ns4.google.com 2001:4860:4802:38::a
[*] 	 MX smtp.google.com 74.125.68.27
[*] 	 MX smtp.google.com 172.253.118.26
[*] 	 MX smtp.google.com 74.125.24.27
[*] 	 MX smtp.google.com 74.125.24.26
[*] 	 MX smtp.google.com 142.251.10.27
[*] 	 MX smtp.google.com 2404:6800:4003:c02::1a
[*] 	 MX smtp.google.com 2404:6800:4003:c05::1b
[*] 	 MX smtp.google.com 2404:6800:4003:c03::1b
[*] 	 MX smtp.google.com 2404:6800:4003:c03::1a
[*] 	 A google.com 142.250.67.46

Paste the ip address 142.250.67.46 in the B field

This will generate a link -> 7f000001.8efa432e.rbndr.us

The following things will happen in the backend

  • The DNS Server of the target will make a DNS Request to 7f000001.8efa432e.rbndr.us and get the ip address as 142.250.67.46,

  • Then in the utils.py it will check the ip restrictions and then will assign a TTL for 1 sec (depending on the application) because it didn't have it on the blacklist

  • And when the TTL is expired it will make another request to the 7f000001.8efa432e.rbndr.us and this time the attacker server will get the ip address as 127.0.0.1 which is allowed to access the internal files.

To get the flag navigate to

http://7f000001.8efa432e.rbndr.us/flag

References

  1. https://www.paloaltonetworks.com/cyberpedia/what-is-dns-rebinding

  2. https://unit42.paloaltonetworks.com/dns-rebinding/

  3. https://portswigger.net/web-security/cors/same-origin-policy

Previous2FA Broken LogicNextWindows Security

Last updated