DNS Rebinding Attack
Last updated
Last updated
A DNS rebinding attack is a technique used by attackers to bypass the security restrictions built into web browsers, specifically the same-origin policy. This policy is designed to prevent a website from making requests to a different domain than the one it originated from. DNS rebinding allows attackers to trick a victim's browser into thinking that an attacker-controlled domain is the same as a trusted domain, thus enabling unauthorized access to internal resources or sensitive data.
In the context of SSRF (Server-Side Request Forgery), DNS rebinding can be used to manipulate a reverse proxy or internal server into making unauthorized requests to localhost or other internal resources. Here’s a step-by-step illustration of how this process works:
Initial Request:
The attacker sets up a malicious website, e.g., attacker-controlled.com, which contains JavaScript code designed to exploit the vulnerability. The victim visits this site, and the JavaScript starts executing in their browser.
DNS Resolution by Reverse Proxy:
The victim's browser makes a request to the attacker's site. This request is forwarded to a reverse proxy server of a target application. The reverse proxy resolves the domain attacker-controlled.com using its own DNS settings, which initially points to the attacker's server.
Short TTL (Time To Live):
The attacker's DNS server provides a DNS response with a very short TTL value. This short TTL ensures that the reverse proxy will frequently re-query the DNS server for updated IP addresses.
DNS Rebinding:
When the TTL expires, the reverse proxy requests a new DNS resolution for attacker-controlled.com. This time, the attacker’s DNS server responds with the IP address of the internal server or localhost (e.g., 127.0.0.1).
Request to Internal Server:
The reverse proxy, now believing that attacker-controlled.com points to an internal address, forwards the request to the internal server or localhost. This is because the DNS rebinding trick has made the attacker’s domain resolve to an IP address that the internal server accepts.
Exploitation:
The malicious JavaScript running in the victim’s browser can now send requests to attacker-controlled.com. Since the reverse proxy has been tricked into resolving this domain to 127.0.0.1, these requests are forwarded to the internal server.
Imagine an attacker sets up a malicious website with a domain like malicious.com. The attacker controls the DNS settings for this domain. When a victim visits malicious.com, the JavaScript on this site initially points to an IP address the attacker controls. However, after a short time, the DNS settings are changed to point to the victim’s internal network (e.g., 127.0.0.1). The JavaScript then makes requests to 127.0.0.1, which are interpreted by the victim’s browser as requests to the victim’s own server. If the victim's server has sensitive APIs or data, the attacker can now access this information.
The lab environment needed to be prepared before diving into the exploitation. The setup began with building the Docker image:
Running the Docker container:
The journey began when I opened the lab, which greeted me with a normal login page.
After logging in, I observed an API request that retrieved user files using a UUID. While it wasn't vulnerable to IDOR (Insecure Direct Object References), I made a mental note of it, suspecting it might be useful later.
On the application's homepage, there was a functionality allowing file uploads from external websites. This immediately triggered thoughts of a potential SSRF (Server-Side Request Forgery) vulnerability.
Attempting to fetch a file from localhost, I encountered a 403 status code with an "invalid URL" message.
With a list of SSRF payloads in hand, I sent the request to Burp Suite's Intruder and began fuzzing using the payloads from my wordlist:
Initial attempts did not yield any promising results.
Next, I decided to try a DNS rebinding attack using a tool I found online:
I configured the tool to rebind between Google's IP address and localhost. Verifying the DNS rebind was successful through nslookup:
So here what we need is to make multiple tries in the request until we success, But unfortunately the still couldn't bypass SSRF protection
Despite the rebind working, the SSRF protection still held strong. I thought to confuse the server by changing the content type of the request, which sometimes tricks servers.
I used Content Type Converter Burp Suite Extension to do so
Original Request:
Modified Request with JSON Content-Type:
Even with the content type change and DNS rebinding, success was still elusive, This approach yielded a promising message: "requests to localhost not allowed."
I then decided to try another common technique: downgrading API versions from v3 to v2 and fortunately i found indicator to Vulnerable SSRF Parameter.
The Server returned A response with Status Code of 404 NOT FOUND cause actually there is no secret.txt on the local host
Seeing a glimmer of hope, I started brute forcing files and directories using a common wordlist:
To streamline the brute forcing process, I wrote a Python script to automate the attempts:
Requesting the /api endpoint revealed the following directories:
Requesting /api/users returned all registered user UUIDs. I used one of these UUIDs to retrieve user files:
Remember this Request ?
I used the parameter user_uuid in the request as a get parameter to make server requests the user's secredt files but the response didn't change indicating that this is not the write parameter
The parameter user_uuid needed to be changed to uuid:
The response indicated success:
And here we go—we did it! The server revealed the sensitive file, "my-twitter-creds.txt."
By following the above steps and utilizing tools like Docker, DNS rebinding, and directory brute-forcing, we were able to bypass SSRF protections and exfiltrate sensitive information from the target application. This demonstrates the effectiveness of DNS rebinding in circumventing security measures that rely on IP-based access controls.
