Singularity – DNS Rebinding Attack Framework

It also ships with sample payloads to exploit several vulnerable software versions, from the simple capture of a home page to performing remote code execution. It aims at providing a framework to facilitate the exploitation of software vulnerable to DNS rebinding attacks and to raise awareness on how they work and how to protect from them.

How Do DNS Rebinding Attacks Work?

DNS rebinding changes the IP address of an attacker controlled machine name to the IP address of a target application, bypassing the same-origin policy and thus allowing the browser to make arbitrary requests to the target application and read their responses. The Singularity DNS server is responding with short time to live (TTL) records, minimizing the time the response is cached. When the victim browses to the Singularity manager interface, the Singularity’s DNS server first responds with the IP address of Singularity itself where the client-side code (payload) is hosted. When the DNS record times out, the Singularity DNS server responds with the IP address of the target host (e.g. 127.0.0.1) and the victim’s browser can access the target application, circumventing the browser’s same-origin policy.

It is also possible to trigger DNS rebinding before a cached DNS record expires, depending of the target platform and using a combination of techniques that are described in later sections.

Features

• Singularity provides a complete DNS rebinding attack delivery stack:
  • Custom DNS server to rebind DNS name and IP address mapping from the attacker web server address to the target machine address
  • HTTP server to serve HTML pages and JavaScript code to targets and to manage the attacks
  • Several sample attack payloads, ranging from grabbing the home page of a target application to performing remote code execution. These payloads can be easily adapted to perform new and custom attacks.
• Supports concurrent users
• Provides several DNS rebinding strategies, including sequential mapping from the attacker to the target IP address and random mapping, to minimize the impact of IDS/IPS interfering with the attack
• A number of technical controls to maximize the reliability and speed of attacks:
  • Disabling HTTP keep alive, caching, DNS prefetching
  • Aggressive DNS response TTLs
  • Option to use DNS CNAME instead of A records to evade several DNS filtering solutions
  • Near instant rebinding for several browser and OS combinations, using multiple DNS answers and dynamic HTTP port blocking.
• Ability to allocate HTTP servers at startup or dynamically thereafter
  • A convenience feature to avoid restarting Singularity to listen on a different HTTP port.
  • To lay the ground work to attack vulnerable ports discovered after a scan.

Requirements

• A DNS domain name from a domain registrar such as gandi or namecheap. You need be able to add and edit your own DNS records for your domain.
• A Linux server instance from a hosting provider such as Linode, Amazon AWS, Google Cloud, Microsoft Azure etc.

Payloads Description

Singularity supports the following attack payloads:

• Basic fetch request (payload-simple-fetch-get.html): This sample payload makes a GET request to the root directory (‘/’) and shows the server response using the fetch API. The goal of this payload is to function as example request to make additional contributions as easy as possible.
• Basic XHR request (payload-simple-xhr-get.html): Another sample payload to make a GET request to the root directory (‘/’) and showing the server response using XMLHttpRequest (XHR).
• Chrome DevTools (payload-exposed-chrome-devtools.html): This payload demonstrates a remote code execution (RCE) vulnerability in Microsoft VS Code fixed in version 1.19.3. This payload can be adapted to exploit any software that exposes Chrome Dev Tools on localhost.
• etcd (payload-etcd.html): This payload retrieves the keys and values from the etcd key-value store.
• pyethapp (payload-pyethapp.html): Exploit the Python implementation of the Ethereum client Pyethapp to get the list of owned eth addresses and retrieve the balance of the first eth address.
• Rails Web Console (payload-rails-webconsole.html): Performs a remote code execution (RCE) attack on the Rails Web Console.

Creating Your Own Payloads

Creating your own payloads is as simple as copying the sample payload HTML file (payload-simple-fetch-get.html) and modify it according to your needs. The sample payload makes a single GET request and displays the response. Start with copying the content of this file to a new .html file and add its name to the attackPayloads list in the manager-config.jsonfile. Then modify the new HTML file to change the request URL for example.

Preventing DNS Rebinding Attacks

DNS rebinding attacks can be prevented by validating the “Host” HTTP header on the server-side to only allow a set of whitelisted values. For services listening on the loopback interface, this set of whitelisted host values should only contain localhost and all reserved numeric addresses for the loopback interface, including 127.0.0.1.

For instance, let’s say that a service is listening on address 127.0.0.1, TCP port 3000. Then, the service should check that all HTTP request “Host” header values strictly contain “127.0.0.1:3000” and/or “localhost:3000”. If the host header contains anything else, then the request should be denied.

Depending on the application deployment model, you may have to whitelist other or additional addresses such as 127.0.0.2, another reserved numeric address for the loopback interface.

For services exposed on the network (and for any services in general), authentication should be required to prevent unauthorized access.

Filtering DNS responses containing private, link-local or loopback addresses, both for IPv4 and IPv6, should not be relied upon as a primary defense mechanism against DNS rebinding attacks. Singularity can bypass some filters in certain conditions, such as responding with a localhost CNAME record when targeting an application via the Google Chrome browser for instance.