Autore Topic: Singularity - A DNS Rebinding Attack Framework  (Letto 156 volte)

0 Utenti e 1 Visitatore stanno visualizzando questo topic.

Offline Flavio58

Singularity - A DNS Rebinding Attack Framework
« Risposta #1 il: Settembre 21, 2018, 02:04:54 am »
Advertisement
Singularity - A DNS Rebinding Attack Framework


Singularity of Origin is a tool to perform DNS rebinding attacks. It includes the necessary components to rebind the IP address of the attack server DNS name to the target machine's IP address and to serve attack payloads to exploit vulnerable software on the target machine.
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.

Screenshots

Singularity Manager Interface


Fetch a Vulnerable Application Home Page on Localhost


Requirements

Setup
Let's say that we want to retrieve the homepage of a tool listening on localhost, port 8080, of a victim desktop machine from domain "dynamic.your.domain." You personally own/manage domain "your.domain." You will mount attacks from a server with IP address "ip.ad.dr.ss". This server will run the Singularity DNS and HTTP servers.

On the DNS Registrar Web Management Interface
Configure appropriate DNS records to delegate the management of a test subdomain ("dynamic.your.domain.") of a domain you own ("your.domain.") to the Singularity's DNS server that we will deploy shortly:
  • A Name: "rebinder", IPv4: "ip.ad.dr.ss"
  • NS Name: "dynamic", Hostname: "rebinder.your.domain."
This sample setup informs DNS clients, including browsers, that "ip.ad.dr.ss" answers queries for any subdomains under ".dynamic.your.domain.", e.g. "foo.dynamic.your.domain.". This also permits one to access the Singularity management console using the "rebinder.your.domain" DNS name with a web browser.

On the Attacker Host

Install Golang
Follow the instructions from the official Go Programming Language web site.

Obtain Singularity
Open a terminal and type the following command:
go get -v github.com/nccgroup/singularity/

Compile
$ cd ~/go/src/github.com/nccgroup/singularity/cmd/singularity-server
$ go build

Deploy
  • Deploy the "html" directory in let's say "~/singularity".
  • Deploy the singularity-server binary in "~/singularity".
$ cd ~/
$ mkdir -p singularity/html
$ cp ~/go/src/github.com/nccgroup/singularity/cmd/singularity-server ~/singularity/
$ cp ~/go/src/github.com/nccgroup/singularity/html/* /singularity/html/*

Run
Start singularity-server with sudo ./singularity-server --HTTPServerPort 8080. This will use a DNS rebinding strategy based on the content of the DNS query by default e.g. s-ip.ad.dr.ss-127.0.0.1-<random_number>--e.dynamic.your.domain will return first "ip.ad.dr.ss", the attacker host IP address, then "127.0.0.1" for subsequent queries for a limited period of time.
Note: You will need to verify that other services do not listen on ports required by Singularity.

Minimum required ports:
  • UDP 53 (DNS)
  • TCP 8080 (configurable default port for the manager web interface)
  • The port where the vulnerable application is running (e.g. port 3000 for the Ruby on Rails Web Console or port 9333 for VS Code Chrome DevTools)
On Ubuntu 18.04 LTS, by default, systemd-resolved is listening on the localhost UDP port 53. This will prevent Singularity from starting. Disable systemd-resolved with this command: sudo systemctl disable --now systemd-resolved.service. Next, update the file /etc/resolv.conf to make sure it does not contain nameserver 127.0.0.53 but something like nameserver 8.8.8.8. Replace 8.8.8.8 with the IP address of the DNS server of your choosing (e.g. nameserver 169.254.169.254 on GCP).

Firewalls
Singularity requires multiple ports exposed to the Internet (or at least to the network from which you access the tool via your browser). The minimum required ports are UDP 53 for DNS and the port where the Singularity manager web interface is running. The default port for the manager web interface is TCP port 8080. Additionally, Singularity requires that the payload is served from the same port where the vulnerable/exploited application is running on to not violate the same-origin policy.
Minimum required ports are listed above.
Please check with your hosting provider to configure allowed inbound ports:

Test

On the Victim Host
  • Deploy a local test service with python -c 'import BaseHTTPServer as bhs, SimpleHTTPServer as shs; bhs.HTTPServer(("127.0.0.1", 8080), shs.SimpleHTTPRequestHandler).serve_forever()' from a directory containing some test data files, on your client machine.
  • Browse to "http://rebinder.your.domain:8080/manager.html".
  • Ensure that the following fields contain the correct information:
    • "Attack Host Domain" e.g. "dynamic.your.domain"
    • "Attack Host" e.g. "ip.ad.dr.ss"
    • "Target Port" e.g. 8080
    • "Attack Payload", "payload-simple-fetch-get.html".
  • Click on "Start Attack".
  • The content of your victim host directory should be displayed within a few seconds/minutes in an alert box.

Browser Support
Singularity has been tested to work in the following browsers:
                                                                                                           
BrowserOperating SystemTime to Exploit
FirefoxWindows 7 / 10~1 min
ChromeWindows 7 / 10~1 min
FirefoxUbuntu~1 min
ChromiumUbuntu~1 min
EdgeWindows 10~21 to ~49 min
FirefoxOSX~1 min
ChromeOSX~1 min
SafariOSX~1 min
ChromeAndroid~1 min
FirefoxAndroid~1 min
SafariiOS~1 min
FirefoxiOS~1 min
The above was tested with Singularity's default conservative settings:
  • DNS rebinding strategy: DNSRebindFromQueryFirstThenSecond
  • Fetch interval (Web interface): 20s
  • Target: 127.0.0.1.
Much faster attacks can be achieved in certain configurations, as detailed in the table below:
                                                                                                                                 
BrowserOperating SystemTime to ExploitRebinding StrategyFetch IntervalTarget Specification
ChromeWindows 10~3sDNSRebindFromQueryMultiA1s127.0.0.1
EdgeWindows 10~3sDNSRebindFromQueryMultiA1s127.0.0.1
FirefoxWindows 10~3sDNSRebindFromQueryMultiA1s127.0.0.1
ChromiumUbuntu~3sDNSRebindFromQueryMultiA1s0.0.0.0
FirefoxUbuntu~3sDNSRebindFromQueryMultiA1s0.0.0.0
ChromeOSX~3sDNSRebindFromQueryMultiA1s0.0.0.0
FirefoxOSX~3sDNSRebindFromQueryMultiA1s0.0.0.0
SafariOSX~3sDNSRebindFromQueryMultiA1s0.0.0.0
We will add more platforms as we test them. We elected a delay of 3s to perform DNS rebinding to cater for targets with a poor connection to the internet/network.

Using Singularity
When Singularity is run without arguments, the manager web interface listens on TCP port 8080. Browse to that port to configure and launch the DNS rebinding attack.

Personalizing The Manager Configuration File
Singularity comes with a default configuration file in html/manager-config.json. You can modify this file to change the default parameters, such as the attackHostDomain, the attackHostIPAddress, and the attackPayloads. You need to edit this file if you add your own payloads. You do not need to edit the configuration file if you want to use existing payloads as you can change the parameters in the web interface.

Server Arguments
Launch the Singularity binary, (singularity-server), with the -h parameter to see its parameters.
  • -DNSRebindStrategy string : Specify how to respond to DNS queries from a victim client. The supported strategies are:
    • DNSRebindFromQueryRoundRobin
    • DNSRebindFromQueryFirstThenSecond (default)
    • DNSRebindFromQueryRandom
    • DNSRebindFromQueryMultiA (experimental, requires Linux iptables)
  • -HTTPServerPort value : Specify the attacker HTTP Server port that will serve HTML/JavaScript files. Repeat this flag to listen on more than one HTTP port.
  • -ResponseIPAddr string : Specify the attacker host IP address that will be rebound to the victim host address using strategy specified by flag -DNSRebingStrategy (default value is 192.168.0.1).
  • -ResponseReboundIPAddr string : Specify the victim host IP address that is rebound from the attacker host address (default value is 127.0.0.1).
  • -dangerousAllowDynamicHTTPServers Specify if any target can dynamically request Singularity to allocate an HTTP Server on a new port. This feature may be dangerous as it allows opening new ports via the unauthenticated web interface.
  • -responseReboundIPAddrtimeOut int : Specify a delay in seconds for which we will keep responding with Rebound IP Address after the last query. After the delay, we will respond with ResponseReboundIPAddr. The default is 300 seconds.

Manager UI
The manager web interface is where you configure and launch the DNS rebinding attack. It listens on port 8080 by default. The following table describes all form fields and buttons in the manager interface:
                                                                     
Field NameDescription
Attack Host DomainThis is the (sub-)domain where the Singularity web server is running. Default value: dynamic.rebind.it
Attack HostThis is the IP address where the manager and the attack payloads are hosted. Default value: xxx.xxx.xxx.xxx
Target HostThis is the IP address of the target system where the victim (target) application is running. Default value: 127.0.0.1
Target PortThis is the port where the victim (target) application is listening on. Default value: 8080
Request New PortThis will request Singularity to listen on a new port. This feature is only available when Singularity has been started with the -dangerouslyAllowDynamicHTTPServers command line option.
Attack PayloadThis is where you select the payload, i.e. which application you are trying to exploit.
Start AttackStart the DNS rebinding attack. Be patient and wait for at least one minute. Open the browser web console to see debugging logs.
Toggle Advanced OptionsThis button will enable the advanced fields described below.
IntervalHow long to wait between connection attempts to the target application in seconds. Default value: 20
Index TokenThe index token is used by Singularity to detect if the rebinding has happened yet. Default value: thisismytesttoken

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.json file. 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.

Advanced Techniques
  • Use the -DNSRebindStrategy DNSRebindFromQueryRandom DNS rebinding strategy instead of the default - DNSRebindStrategy DNSRebindFromQueryFirstThenSecond if you suspect the presence of an IDS in one or more environments that sends several DNS requests to the attack server in addition to the actual target. This will ensure that the target will eventually obtain the required IP address, albeit a bit more slowly.
  • Singularity responds with a DNS CNAME instead of an A record if one specifies "localhost" as the target instead of "127.0.0.1". This may work around DNS filtering of responses containing "127.0.0.1", at least on Chrome and Firefox. Chrome & Firefox appear to look at their internal database upon reception of the CNAME record containing "localhost" instead of making another DNS lookup. Chrome populates its DNS cache with both "127.0.0.1" and "::1" in particular. Related: https://tools.ietf.org/html/draft-west-let-localhost-be-localhost-06.
  • Similarly, specifying "0.0.0.0" on Mac and Linux, which corresponds to "this host, on any interface" on these platforms may work around some filters/controls.

Useful Notes and Other Loose Ends
  • Cross-platform compilation: go to "~/singularity/cmd/singularity-server/" and type env GOOS=linux GOARCH=amd64 go build for a Linux build or go build from a mac OS machine for a Mac build.
  • The fetch API based attack scripts in the "html" directories will stop after 5 attempts if there are network errors.
  • Going to chrome://net-internals/#dns in the Chrome browser is great for debugging.
  • Test dig query: dig "s-ip.ad.dr.ss-127.0.0.1-<random_number>--e.dynamic.your.domain" @ip.ad.dr.ss
  • sudo ./singularity-server -HTTPServerPort 8080 -HTTPServerPort 8081 -dangerouslyAllowDynamicHTTPServers starts a server on port 8080 and 8081 and enables requesting dynamically one additional HTTP port via the Manager interface.
  • Testing a service for a DNS rebinding vulnerability: In an HTTP intercepting proxy such as Portswigger's Burp Suite, replay a request to localhost, replacing the host header value e.g. "localhost" with "attacker.com". If the request is accepted, chances are that you have found a DNS rebinding vulnerability. What you can do after, the impact, depends on the vulnerable application.
  • Use the DNSRebindFromQueryMultiA strategy for instant rebinding when supported by the target browser/OS combination and with the tested settings, summarized in the table above.
  • The DNSRebindFromQueryMultiA rebinding strategy does not support the "localhost" target value if trying to evade IPS/IDS and DNS filters.



Source: Singularity - A DNS Rebinding Attack Framework


Consulente in Informatica dal 1984

Software automazione, progettazione elettronica, computer vision, intelligenza artificiale, IoT, sicurezza informatica, tecnologie di sicurezza militare, SIGINT. 

Facebook:https://www.facebook.com/flaviobernardotti58
Twitter : https://www.twitter.com/Flavio58

Cell:  +39 366 3416556

f.bernardotti@deeplearningitalia.eu

#deeplearning #computervision #embeddedboard #iot #ai

 

Related Topics

  Oggetto / Aperto da Risposte Ultimo post
0 Risposte
134 Visite
Ultimo post Aprile 11, 2018, 01:32:37 pm
da Flavio58
0 Risposte
242 Visite
Ultimo post Maggio 13, 2018, 07:05:16 am
da Ruggero Respigo
0 Risposte
76 Visite
Ultimo post Giugno 26, 2018, 12:01:28 am
da Flavio58
0 Risposte
108 Visite
Ultimo post Luglio 24, 2018, 06:03:24 am
da Flavio58
0 Risposte
405 Visite
Ultimo post Settembre 05, 2018, 08:04:26 pm
da Flavio58

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326