 Let's get started. Uh, please give Gerald and Roger a very great DEF CON welcome. Hello DEF CON. Hello everybody. Um, today we're going to, uh, discuss the current state of, uh, DNS rebinding, including attack, recent attack and prevention technique. We will also discuss, um, our tool, uh, Singularity of Origin. It's a DNS rebinding attack framework and how it incorporates this new, um, technique and how you can use them today. So our contribution in the domain of DNS rebinding are, um, two-fold. Uh, the new tool, Singularity, uh, it has everything you need to perform DNS rebinding. It is reliable. It is performance. It has built-in payload for, uh, command services and can perform, uh, automatic service detection and exploitation. Um, the second area of contribution, uh, is, uh, in the research of, uh, technique to improve the speed of DNS rebinding and how to bypass command DNS rebinding protection. So, um, our talk would be articulated around, um, uh, the new tool and the, the techniques, uh, intake operates and, uh, we will, uh, include the customary, um, uh, refresher on the basic of, uh, uh, DNS rebinding. We will also discuss, uh, uh, an architecture we have implemented in Singularity, which allow you to interactively browse, um, uh, hooked browser, uh, internal network. So who are we? We are Gerard Lusso and Roger Mayer. We are security consultant at NCC Group. Uh, we are attached to the San Francisco office. And, uh, we are the authors of Singularity of Origin. Roger? So why should you care about DNS rebinding? Most developers understand that when they bind their application to all interfaces, that they expose themselves to remote access and this is not a good idea. So what do they do to fix this? They bind the application to the local host. They think only trusted users can access, it's a trusted environment so they don't need authentication, right? And then all these DNS rebinding issues happen. The EOS cryptocurrency wallet is vulnerable. Google Home, Roku, Sonos speakers are vulnerable. The Geth, Ethereum client was vulnerable. Redis, MemcashD, Elastic Surge, the Kubernetes dashboard on Meacube is vulnerable to DNS rebinding, allowing RCE and VMScape. The Rails web console was vulnerable. We see more, more applications exposing, uh, where, uh, HTTP server on the local host, especially through the popularity of frameworks, such as Electron. The rise of IoT devices exposing sensitive interfaces on internal networks without authentication will make this even worse. We would also like to clear up certain misconceptions such that DNS rebinding is slow and can be solved by out of the box DNS filtering products or services, which is not the case. We'd like to start with a quick refresher on how DNS rebinding works. The origin is, consists of the scheme, host and port. Two documents share the same origin if they have the identical scheme, host and port components. The same origin policy is an important security concept implemented in browsers that dictates how two different sites with different origins can interact with each other. Certain interactions are always allowed between all origins, such as forum submissions, links, redirects, content embedding, but cross origin reads are typically not allowed. This is important, for example, if you're logged in to gmail.com and browse to an attacker controlled website, you don't want the attacker controlled code to be able to read your gmail messages. DNS rebinding permits us to bypass this same origin policy. We'd like to show you a visual walkthrough to make it easier to understand the concept. So on the left side we have the victim, which is the browser. We have a target service, which can be a service on the victim's local host or on the internal network. We have an attacker, which consists of a DNS server and a web server on this public IP. So on the right side we have the internet. On the left side we have the intranet. The victim can access the target service without authentication and the attacker cannot directly reach the target service, otherwise we wouldn't need DNS rebinding. So step one, the victim browsers to the attacker's website, hosted on rebinds.it, that's our domain name. We respond with the DNSA record of the public IP address and load some JavaScript, which keeps running in the victim's browser and waits until the DNS record expires. Once it expired, we make another request in the same origin. This time we respond with a different IP address, the IP address of our target service, 127.001. Notice that the origin, rebind.it, did not change. We did not violate the same origin policy. The browser will make this request and will allow the JavaScript to read the response and where we can exfiltrate it back to the attacker. All of this is possible because we did not violate the same origin policy. It's still pointing to rebind.it. We only change the IP address. This was a high-level overview which omitted a lot of details. There are a lot of previous good research which you can look at if you want to know more about the details. We would like to show you a first demo on iOS using Safari where we can achieve DNS rebinding in just five seconds using the cache flooding technique. In this case, we will be exploiting a home router on router.asus.com and we will be just reading the index page and displaying the results in a JavaScript alert box for demo purposes. This is Safari. We're going to router.asus.com. This is the target we're trying to exploit. Now we're setting up the attack. We're going to the Singularity Manager Web Interface. We're setting the target host to router.asus.com. We're leaving the target port at port 80. We're setting the attack payload to a simple fetch gap. We're using the first and second strategy, the interval of one second and we're enabling the cache flooding technique. We're starting the attack. This only takes about five seconds and we display the results. What we see here is the return of the index page which is just a redirect to the main login on ASP web page but it shows that we were able to read the response from an internal system, the home router. Thank you Roger. Now that we have a grasp on the basics of DNS rebinding, we are going to explore how we made DNS rebinding more reliable within Singularity. So let's say that you are a fan of horse riding and you're trying to plan your next vacation and you found a website that just allowed you to do that. There's nothing wrong with this website. Displayed permanently is a trojan horse picture. In fact the website was compromised and is running a hidden high frame with Singularity. So you connect to the website and you download the malicious JavaScript from Singularity and the code emits its first DNS query. So what is in a query? As you can see the query is made of several components. These components encodes everything Singularity needs to perform an attack. So first you have a start tag, then you have the attacker host IP address where we run Singularity, then you have the target IP address or it can be a name as well followed by a session ID. Session allow for the use of concurrent users and targets. Then you have the DNS rebinding strategy. Singularity incorporates a number of different DNS rebinding strategy. Here you can see FS, first and second, although known as a time-varying attack. This is the simplest and most reliable DNS rebinding strategy you can implement. Then you have the end tag and then you have the attacker domain, the one that you have ever purchased or compromised. So to improve reliability, you want to remove any HTTP performance enhancing technique that may impede DNS rebinding or stop it completely in its track. So we try to disable HTTP caching in all browsers implementation and intermediate cache to ensure that the browser gets a fresh copies of folder resources. We also instruct Singularity to drop idle connection from browsers. So when it is time to rebind against the target IP address, the browser doesn't maintain a connection to Singularity. What about TTL value? Um, most literature and other tools use a value of one second. Uh, we tried zero in the hope that, um, it will break stuff. It didn't. Uh, zero second is a valid TTL value so we just ticked with that. So how do we know that we have, uh, successfully rebind it against the target service? Um, historically, uh, Singularity use an index token in the HTML body. Um, so if this index token is present, um, then the Java script code knows, uh, it's still pointing against Singularity. If this token is, uh, disappears on the next, next fetch, uh, then it means that you have successfully rebind it. We recently moved to a custom HTTP header. Uh, however the index token is still useful in a, uh, one specific DNS rebinding strategy, uh, where we, uh, abruptly, uh, terminate the connection, uh, from Singularity to the browser and the browser get confused. We will, uh, go into more details, uh, on this later. Something you need to consider as well is that, uh, you may, uh, encounter an environment, uh, where there is an IPS, an IDS, um, and, uh, this IPS IDS may emit their own, uh, spurious, uh, DNS queries when they see, uh, requests from, uh, the, uh, the target browser. So it, it means that you may receive, uh, uh, IP address, uh, out of sequence when you make your DNS query, uh, um, which, um, uh, means that, um, the target browser will never see the IP address of Singularity, only the target, so we'll never be able to download the code and, uh, perform DNS rebinding. So to address that, we, um, have implemented a random DNS, uh, rebinding strategy where, um, um, uh, we respond either with the attacker IP address or the service, um, IP address, uh, which is a much slower technique in general but you could get lucky. So, um, we're now going to explore how we, um, improve the speeds, uh, uh, of DNS rebinding in, uh, in Singularity. So the first thing to know is that implementation details matter. Um, the DNS, uh, rebinding speed will vary, uh, depending on the whole implementation. Whether you use, uh, Windows or Unix like environments, uh, operating systems such as, um, Linux or MacOS, the browser vendor, uh, i.e. Edge, uh, Firefox, Chrome and all the, it's been off, uh, and Safari. The target specification matters, um, whether you use, uh, uh, a service, you're po- you're targeting a service that's bound to the loopback interface or, uh, uh, on the private network or a remote public IP address. Obviously we just, uh, solve that, uh, external factor may impact the speed such as the presence of an IPS and IDS. So just to illustrate, uh, DNS rebinding may take 40 plus minutes, uh, when, uh, uh, using Edge, uh, and down to three seconds depending on what strategy you use. Uh, Singularity can automatically, uh, fingerprint to optimize for speed, uh, in some condition. We'll discuss this later. So the time varying attack, uh, uh, Singularity first and second is approximately 60 seconds on all browsers except, uh, i.e. an Edge. Um, we, um, there's another technique called multiple answers that we didn't believe would work. Uh, however, uh, one of our colleagues Michael Roberts from NTC Group, uh, created a small proof of concept, uh, demonstrating that, uh, it was working on Windows when we specified, uh, an IP address of 127.0.0.1 and that we were achieving rebinding time of, uh, of three seconds once, uh, we implemented that. Uh, however, it didn't work with, um, the same technique didn't work with a Unix-like machine, uh, such as Linux or, um, MacOS. However, after a bit of digging, when we specified, um, uh, target service IP address of 0.0.0, uh, we achieved, uh, approximately three seconds, um, rebinding time. So now we have a solid and fast, uh, DNS rebinding against all loop back bound, uh, services. Just to illustrate at a high level how the multiple answer rebinding strategy work, so the target browser will emit its DNS query, uh, to rebind at its, uh, where we run Singularity as usual. Um, instead of responding, um, with the IP address of the attacker, then, uh, the IP address of the service, uh, as we do for the time-varying attack, we respond with both recorded at the same time. So then the target browser is going to keep, uh, polling, uh, the service, uh, and, um, uh, to determine whether it's pointing against Singularity or the targets. Uh, Singularity is going to then implement at some stage, uh, a firm role, um, uh, firewall rule that will, uh, abruptly block the traffic. This will force the browser, uh, to, um, uh, connect, uh, to the target service using the second IP address we provided earlier. So the multiple answer technique, um, my strategy worked very well for loop back bound type of, uh, services. So if your service, uh, uh, for instance, for instance is listening on 127.0.0.1, but we were getting inconsistent results for over target specification, for instance on the, uh, private network, uh, where one attempt out of five would, uh, succeed. Uh, we implemented another technique called DNS cache flooding. Um, this worked very well in, uh, Google Chrome and, uh, Safari and iOS platform. Uh, you basically, basically, uh, flood the cache of the browser with thousands of queries. Um, and, uh, you can reduce vendor DNS rebinding time from five to 40 seconds, which is a great progress over the average of 60 seconds. Uh, Roger Demo was using this technique, uh, when we were using iOS and we got a rebinding time of five seconds. Um, flooding the cache is performed in a separate web worker. So here you have a Chrome, um, uh, console and in blue, uh, you have your regular, uh, attempt to fetch, uh, uh, resources to determine whether, um, um, we were pointing against the target service or not. And, uh, uh, in between all these, uh, requests you have thousands of queries that fill the cache of the browser, the DNS cache, uh, in an attempt to, uh, evict the IP address for the singularity server, forcing then the browser to point to the service for instance 127.00.1. So we have, uh, illustrated in this table some configuration and, uh, what can you expect, uh, uh, from a, uh, DNS rebinding time perspective. Roger? Let's talk about DNS rebinding protection bypasses. Using singularity, we can bypass all known DNS rebinding protection such as those implemented in open source DNS service unbound or DNS mask. We would like to emphasize that common recommendations and default configurations do not provide complete protection. How do common DNS protections look like? Most solutions block certain DNS responses at the perimeter so when they enter your internal network. Some tools block RFC 1918, private IP addresses such as 10 slash 0, 192.68 slash 0. Some tools block local host IPs, 127 slash 8. Some tools can be configured with, with IP addresses you're using internally if you're using public IPs on your internal network you can get those blocked. Some tools block the 0 slash 8 range. DNS mask and unbound are two widely used open source DNS servers. They're used in tools such as PF Sense, OpenWRT and certain home routers. There are also free public DNS services such as Cisco's OpenDNS which advertise that they have rebinding DNS rebinding protection implemented for OpenDNS. It's called block internal IP addresses and that just blocks private IPs. DNS mask has a setting called stop DNS rebind which blocks private IPs, the 0 slash 8 range and 127 slash 8 range. This does not block local host. We will talk about what we mean by local host in a minute. The unbound DNS server has a configuration setting called private address where you can configure internal IP address range and this will then be blocked. This does not block the 0 0 0 0 IP, the 127 0 0 1 or the local host. Our first protection bypass is using this 0 dot 0 dot 0 dot 0 IP address. This is a non rodable or invalid IP address but it works very well on Linux and macOS using Firefox and Chrome to access the local host. This bypasses protections that block DNS responses containing the IP address of 127 0 0 1 or the whole 127 slash 8 range. When we query singularity we can specify the target here so we can use the 0 dot 0 dot 0 target and then the DNS response will be an A record pointing to 0 0 0 0. What if the DNS protection solution blocks all internal IP addresses? Then we can use C names. Canonical name records are DNS records which map one domain name to another domain name. We can return a DNS C record instead of an internal IP address such as wiki.ncc group.com or chenkins.internal.card.com whatever our target is. This bypasses protections that block DNS responses of private IP addresses. The local internal DNS server will then resolve the C name for us and you don't want to block internal DNS resolution if you want to use internal host names. When we query singularity we specify the target here so instead of an IP address we specify wiki.nccgroup.com and then the DNS response will be a C name pointing to wiki.ncc group.com. Our third bypass is a variation of the previous technique. We can use the C name of local host. This bypasses protections that block DNS responses containing 127 001. This works well in linux and macOS. When we query singularity we specify local host here and then in the response we just return a C name pointing to local host. Okay. Now we're going to discuss the architecture we implemented in singularity to browse the victim internal network after a DNS rebinding. So tools such as beef, the browser exploitation framework and fire drill, a DNS attack tool can use a hook browser to access targets which are not typically available directly from an attacker such as your own appliance or corporate environment assets either via cross-site scripting or DNS rebinding. So we know that beef required the attacker to configure its browser or operating system to use the beef application server to avail of this functionality. We don't know how fire drill does it since the codes and the binaries are not available. We implemented the browsing of service in singularity without requiring the attacker to setting up its browser to use an HTTP proxy but instead just to point to singularity using normal HTTP requests. So at a high level once your browser has been hooked or the victim browser has been hooked the browser will make a web socket connection to the singularity application server and wait for instruction. The attacker will use his browser to connect to singularity and display the list of a victim that's been hooked and select one to browse. So let's say you want to connect to the home directory of a service bound to 1-2-7-0-0-0.1. The attacker browser will emit a normal HTTP request to obtain the directory. The singularity application server will translate this into a web socket operation to fetch the resource. Then the target browser using the singularity JavaScript code will translate this web socket fetch operation into a normal fetch API call to the home directory. Then the data will be sent back all the way back to the attacker browser. At a low level we just customize the Golang ground-tripper interface and we use the web socket plain text protocol to package each fetch request and response. Since we use base 64 encoding the size of the message is increased by 4-3 of the original length of the message. Please note that you don't have to use a browser. You can use any user agent. You can use KERL, HTTP inspecting proxy such as a port-sweager or wasp-zap or SQL map and so on. So when we implemented this architecture in singularity we encountered a number of challenge. The first assumption we made was that we didn't have to care about the cookies exchanged between the victim browser and the victim service, the target service. However our first test case was duplicity, a backup solution that was vulnerable to DNS rebinding. And as you can see the code snippet here, duplicity is extracting C-surf token from the cookie to generate links that are used to browse the duplicity application and perform a number of actions including running a backup. So singularity didn't work with that. So we had to consume this cookie so we read them from the target browser and we transmit them to the singularity server of a web socket and then the singularity application server set them on the attacker browser for the target domain that singularity has constructed. For HTTP only cookie, we don't really care about them. They cannot be read by JavaScripts. So they cannot be used by JavaScript on the attacker browser. So we let the target browser handle them for us. Another challenge is that to be able to read cookies when you perform a fetch request, a fetch API, you have to pass the credentials includes option to the fetch request. And if your application require HTTP authentication, this is not going to work. And why is that? This is illustrated in this slide. So let's say you have a service that requires HTTP authentication and you issue the command fetch HTTP 127.0.0.1 with your credentials includes then authentication dialog box appears. That will warn the user that something is amiss. So we don't want that. However, if you type the same command but you pass a different argument credentials omits, then there's no authentication dialog box so the victim is none the wiser. So when we have cookie and HTTP authentication required then we forget about we actually don't transmit the cookie to the attacker. Okay, now that Gerald introduced us to this hook and control feature we would like to show you how this works in a demo. For this demo we'll have two browsers. One is the victim, the other one is the attacker. In this case they will be both on the same machine but in a real world attack this does not have to be the attacker can be anywhere. So the victim will have a Jenkins instance installed in the local host and the attacker will try to access this. So this is the victim chromium browser which has Jenkins instance running listening in the local host. Now we're switching to the attacker. This is the hooked victim clients which will show up here so we reload the page and show it's currently empty there's nothing there. Switching back to the attacker sorry to the victim browser we're going to the singularity manager interface. We're setting target to zero zero zero for local host target port is eighty eighty. We're using the hook and control attack payload. We're using the multiple answers attack strategy. We're using one second interval. We're starting the attack. It only takes three seconds. The attack was successful. We're now we're switching back to the attacker. We're reloading the page and we can see this new victim session. So we click on it and we can now browse the victims Jenkins instance over the internet. So the attacker browse this credentials endpoint. We're going back to the victim to show you the requests. The first request is this slash credentials which the attacker was browsing to show you how this looks like. We can see the slash credentials. The remote address is zero zero zero for local host and the request URL is the origin still points to the attacker. We'd like to show you how we exfiltrate our data back to the attacker. So this S-O-O-W-S endpoint is how we send and exfiltrate the data back to singularity using web socket messages and that's how we can all the attacker can then browse to Jenkins instance. Okay now we're going to discuss how to scan for vulnerable hosts and services. So in the past there have been many very smart attempts to replicate end map behavior in the context of the browser but we've had the power of four sockets. So many of the solution we have looked at are either not completely reliable or do too much for our purpose. For instance we don't care whether SSH port is open or not. Denys rebinding is concerned with exploiting issue with HTTP resources so far. So the only thing we care about is does it speak HTTP. So we implemented a very simple solution that leveraged modern API and so it's including sorry fetch abort for implementing a timeout. So we distribute the list of targets we want to scan. That includes IP address and ports across four web workers. We only fetch the resource header. We don't bother with the response body. And we have a outcoded limit of 300 milliseconds before we move on to the next target if we don't get sufficient results. So the timeout will obviously drive how fast you can scan a host or a whole network. It is fast for HTTP open port obviously and it's fast as well for closed ports because if you send a packet to a closed port the TCP IP stack of the target will respond with a reset packet if nothing is listening on this port. It is slower for firewall ports but because here typically a firewall will drop any response so you don't know what's going on. So the scan will wait 300 milliseconds and then move on to another target. And slow as well possibly for slow HTTP service and over protocol that are not handled by fetch. So you want to use a lower timeout when you're scanning a LAN or fast HTTP service. Or you can use higher timeouts when you scan over a network. Make the one that I have high latency such as VPN. Over interesting bits and pieces we use the classic web RTC IP address leak to obtain the IP address the private IP address of the victim when available it works on Chrome and Firefox and we use this IP address to derive a subnet we can use to scan. We obviously pass the credentials omits to fetch. So the victim is not made aware that a scan is ongoing and we currently considering performing a second pass scan to identify slower HTTP service that we may have missed. So we have learned how we made singularity more reliable, faster, how we can find vulnerable targets and services. Now we're going to show you how you can implement all the above, orchestrate all the above and perform service detection and auto exploitation as a bonus. So singularity provides a sample auto attack.html file, it is fully customizable and permits to leverage all the features we have discussed so far including but not limited to you can specify specific exploitation payload for instance targeting a service like Jenkins or you can ask singularity to auto select the payload based on the service it detected. You can out code your targets and ask a singularity to optionally detects more targets maybe on your network. Same thing for ports. You can specify a DNS, a default DNS rebinding strategy and ask a singularity optionally to auto optimize and find the best strategy for you. And obviously you have all your options such as flooding the DNS cache, visibly hiding activity and so on. In the future we intend to implement more auto optimization so you don't have to read the extensive wiki. So when you're designing your attack you want to mix and match different specification of the same targets. For instance for local host bound service specify 0.0.0.0.0 local host as a C name or 1 to 7.0.0.1. This will improve reliability, the permit you to bypass security controls and for speeds. You can instruct singularity to find and use the external IP address to exploit the internal interface of Wi-Fi access points and routers for a device that use the WIC and system model. I can only encourage you to refer back to the DEF CON presentation, DEF CON 18 in that regard to see how it works. And you want to do some homework using open source intelligence. Try to figure what is the naming convention for assets in a corporate network or even use a dictionary of service name and specify them as C name in your target list. For instance Jenkins.internal.corp.com. This is likely going to pay off because a lot of service are still not updated in a corporate environment. So we mentioned that singularity can do service detection as well. So singularity come with a number of attack payloads that target services such as Ruby on Rails, Admin console, Amazon, AWS Instance metadata and so on. And we recently added a service detection routine that allow you to detect what service is running behind and try to deliver an appropriate payload. So for instance if you find that the service responds with a HTTP address that contains the value X Jenkins, then singularity will figure out that's more and more likely is using, is facing Jenkins application instance. So when you select the automatic attack payload, singularity will try to detect a service and deliver the appropriate payload it has. So without tool we were trying to blur the line between origin and I think we have achieved that. Hence the name, singularity of origin. So how do you protect from DNS rebinding attack? You often hear comments or on blogs or recommendation to use DNS blacklist or to use tentatively to use DNS sec maybe or to use this DNS service provider or one of your colleague or friend bought this appliance that or router that state that it provides DNS rebinding protection. Well as we learned command wisdom is not enough. It is hard to understand all the subtleties of DNS rebinding and no DNS sec won't help you there. So Roger how do we protect from DNS rebinding? There are three proper ways to protect your service. One is to use TLS on your application including the service listening on local host. You can require authentication if the attacker doesn't know the credentials. They can't make a valid request. Or you could validate the host header for all incoming requests using a whitelist of trusted domain names such as localhost or 127.0.1. Remember when we showed the origin in our last demo it was still pointing to the attacker which won't be whitelisted. There is also a proposal called course RFC 1918 which would require a pre-flight course request for websites hosted in a public IP address when they make a request to a private IP address. This is currently a draft and not shipped in any browser but this may prevent the DNS rebinding in the browser. We have one last demo where we show you how to automate this process. Previously the victim was browsing to the singularity manager interface where they had to configure everything which is not very realistic. So in this demo we'll show that the victim only has to browse to singularity. We start with a port scan to detect services listening on the local host. We rebind to these discovered services in three seconds already detects the service listening for the payloads we have and launch the exploit right away. For this demo we have a Rails console listening on the local host port 3000 and a Jenkins instance listening on port 8080. So this shows the managed rebind phase which we are not going to use. What we're going to use is this auto attack demo page. So browsing to the page we see that we detected port 8080 and 3000. We're launching DNS rebinding right away. The rebinding was successful. It detects already detects the services. We, not sure, let's go back one more time. It didn't update quite well. It detected Jenkins right away and it should detects launch. It detected Jenkins and here it's still rebinding, already detecting. It doesn't seem to update quite well. So for Rails we have remote code execution which launches the calculator and for Jenkins we just dump the plain text password stored in credentials to the console. We'd like to show you how the script looks like, the configuration script. It's very simple, the auto attack script so we can define the rebinding strategy. Here we use multiple answers. We use the attack payload automatic which automatically tries to detect the service. We specify the port, port 8080 and 3000 in this case only and we can specify which address to use. There are a few more settings but which we don't need for you. You can get the slides including your notes on this URL. You can get singularity or tool on our github page with all these features. Let us know if you have any questions. Thank you.