BG - State of DNS Rebinding - Attack & Prevention Techniques and the Singularity of Origin - Gerald

good afternoon everybody welcome to besides Las Vegas breaking ground track this next talk is called state of DNS rebinding and our presenters today are Sarala do so and Roger Mayer a few announcements before we get started we'd like to thank our sponsors especially our inner circle sponsors critical stack and Vala mail and stellar sponsors silence Microsoft and Robin Hood it's because of the support of these sponsors and our other sponsors and our volunteers and Duncan donors that we're able to do b-sides so thank you these talks are being streamed are being streamed live so as a courtesy to our speakers into there everyone else in the audience we ask that you leave your cell phones on silent position at the end if

you have a question please raise your hand I'll bring you the mic we want to be sure and get your question on the microphones so that the YouTube audience can hear it and that's it with that let's get started and here's Gerard and Roger thank you so today we're going to discuss the current state of DNS rebinding including recent attack and preventive prevention techniques we will discuss our new tool singularity of origin and how it incorporates this new technique and how you can use them today so our contribution in the domain of DNS rebinding are twofold one is our new tool singularity it includes everything you need to perform a DNS rebinding attack it is reliable performance it

includes built-in payload for command services and allow it to perform automatic service detection and exploitation the second area of our contribution is in the research of improving the speeds of Dentistry binding how to bypass a command Genet's protection remaining protection so our talk is focused around our tool and these new techniques we will include customary DNS rebinding refresher and we will also this gasps HTTP proxy less architecture to browse the victim internal network so well we we are do so and Roger mayor we are security consultants at NTC group we are attached to the San Francisco office in California and we are the authors of singularity of origin water why should he care about DNS rebinding most

developers understand that when they bind their web application to all interfaces they expose their application to remote access and they see that this is not a good idea so what do they do to fix this they bind the application to the local host they think this is a trusted environment they don't need authentication because only local users can access right then all these DNS rebinding issues happen the eos cryptocurrency vault was vulnerable DNS rebinding the Google home Roku so no speakers so vulnerable the gap here iam client Redis memcache the elasticsearch kubernetes dashboard on mini cube was horrible to RC in VMs gave via DNS rebinding the rels web console was vulnerable we see more and more

applications exposing an HTTP server on the local host especially through the popularity of frameworks such as electron the rise of IOT Rises exposing sensitive interfaces on internal networks with our authentication will make dis even worse and then we would like to clear up certain misconceptions suggest that we honest DNS rebinding is slow and can be solved by out-of-the-box DNS filtering products or solutions which is not the case we would like to start with a quick refresher on how DNS rebinding works the origin consists of the scheme host and port two origins sorry 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 origins to little news websites can interact with each other certain interactions are allowed between all origins such as form submissions links redirects come from the beddings cross origin reads are typically not allowed this is important if you're logged into Gmail account for example and browse to an attacker control site you don't want the attacker to be able to read your Gmail messages DNS rebinding permits us to bypass this same origin policy let's start with the visual walkthrough to show you how such an attack will work we have the victim the browser we have a target service this can be a service listening on the localhost as shown here or another

service listening on the internal network on the right side we have the attacker which consists of a DNS server and the web server on this public IP so on the right side we have the Internet left-side intranet the victim can access the target service without authentication that's a requirement and the attacker cannot directly reach the target service otherwise you wouldn't need DNS rebinding step 1 the victim browsers to the attackers web server this creates requests to rebind the IT that's the domain in the origin where we were hosting or attacker web server we respond with the public IP address and we return in some JavaScript which keeps running in the browser and waits until the DNS record expires once it expired

we create another request this time we respond with a different IP address the IP address of our target service on 2701 notice that the origin rebind ID did not change so the JavaScript the browser will make its request and the browser will allow to read the response because we did not violate the same origin policy the origin is still the same and we can then export rate the data back to the attacker this was a high-level overview which omitted a lot of detail some of them will go over and if you want to know more details there are a lot of previous really good presentations which go into much more detail we would like to start with our first demo this is a

demo on Safari oh and I are showing that DNS rebinding can be done in just five seconds on iOS using the cache flooding technique we will be targeting a home router on a relative basis of a system that's the target and we will read the response of the index page and display it in a JavaScript alert pop-up for demo purposes so it is a safari in the latest iOS we're browsing to target route that's our target now we're setting up the attack we're going to the singularity manager web interface we're setting the target to router SS comm we are leaving the target at port 80 we are setting the attack payload to a simple fetch gap we are using the rebinding

strategy first and second as well as one second and we're enabling the cache flooding we start the attack this takes just five seconds and we should see the response this pop-up which is displaced the response on the index page it's a redirect to main login dot ASP but it shows that we were able to read the response from the router

thank you so no but we have a grasp on the basics of DNS rebinding we are going to show how we were able to make dentistry binding attack more reliable in singularity so let's say you a fan of horse riding and you are trying to organize your vacation around this team and so you visits web sites and it has a Trojan horse picture displayed here nothing wrong in fact the site was compromised and it's running a hidden high frame for singularity so you connected the website and you do not the malicious JavaScript code from singularity and the codes emits its first DNS query so what's in a query the genus query sent by the father to the

singularity server is made of several components with components and codes all the interim information but security needs to perform the DNS rebinding attack so first you have a start tag it is further than by the IP address of the attacker host in this case singularity then you have the target IP address or DNS name you have a session ID the session ID so the session are used to support multiple user or victim and and services then you have the DNS rebinding strategy in this case FS first one second singularity include the number of DNS rebinding strategy we're going to cover some of these later Fred cig first twenty second is also known as a time

bearing attack it is the most reliable and easiest to implements attack you can perform when you have your and tag and you have your attacker host domain but the attacker may have purchased or I've compromised so to improve the reliability of Dentistry binding attack you want to disable all form of HTTP caching and we do that for all browser implementation in India Maori cache that's ensure that the target browser always fetch fresh copies of resources we also instruct singularity to dropped to drop idle connection from target browser so when Deena's remaining time is happening the browser doesn't stick to the attacker server but switch to the victim service whatever TTL value so most literature and tools around DNS

rebinding implements a TTL value of 1 second we used zero in the hope but break stuff however it didn't that was disappointing but zero is a very valid value so we stick to this so how do we figure that DNS rebinding has happened how does the browser figure - historically singularity used an index token embedded into the HTML web page to detect whether it is pointing against singularity or against the target service we recently moved in to make uses data in in the HTTP header so if the JavaScript code that was do not read on the target browser see this header it knows but it is pointing against security if it doesn't sit in anymore

it means the rebinding has successfully happened note that we still used index token in some circumstances especially in multiple a genus rewinding strategy but we were going to cover shortly where the the singularity will drop the connection to the target browser very abruptly the browser get confused and the index token is one way to detect but it's pointing against singularity or the target service another thing you need to consider as well that's when you perform you attack you may be facing an environment but include IPS and ideas these IPS and IDs may emit spurious DNS queries of their own which means that the response might be out of sync and but the targets browser will

never see the IP address of the attacker server in its response meaning that they cannot get the manage to Java scripts to perform the DNS rebinding attack so to schedule for this type environment we implemented a random DNS rebinding strategy where a singularity will reply randomly either with the attacker IP address or the target service so it's a much slower technique in general but you could get lucky so we're going to cover now how we improve the speed of DNS rebinding in singularity so this rebinding a speed very on the number based on the number of elements including whether you use a Windows or unix-like operating systems such as linux or mac o s-- the browser vendor

obviously I edged firefox chrome and chromium and all just enough including the recent version of edge safari sh the target specification as well matters whether you specify a service on the loopback interface or whether it's on the private network or it's a remote public IP address obviously external factors such as the spurious DNS queries may slow down the DNS rebinding so just to illustrate DNS rebinding may take up to 40 plus minutes on edge and with the appropriate strategy you can reduce about 3 seconds singularity can automatically fingerprints to optimize for speed in certain circumstances we're going to cover this short leash so the time bearing attack but we implemented insecurity typically Tech approximately 60 seconds to rebind all

browsers except ie or edge so we implemented another rebinding strategy called multiple answers multiple answers we thought what it was not going to work originally there was some paper stating but it would work in certain circumstances and one of our colleague Michael Roberts made a quick proof of concepts showing us it was working very well on Windows with the targets IP address address set 127.0.0.1 so we implemented this and we got a three second dentistry binding time on Windows however this didn't work on unix-like operating systems such as Linux or Mac OS but I stopped digging we found out but when you set the target IP address to 0.0.0.0 when you get the same three

second remaining time for an annex and MCOs this means that we have a solid and fast DNS rebinding against all local host type of services just to illustrate at high level how the multiple answer abiding strategy works so the target browser will emit its first query to the attacker server as usual but where the first one second of time barring attack will reply with the attacker IP address first then the targets IP address the multiple answer rebinding strategy will respond with both IP address record at the same time when the target browser will poll singularity to determine whether it's still pointing against the attacker server or the target IP address after a while singularity will implement dynamic

ephemeral fire rule that will block the requests from the target order to itself this will fall spend the target browser to use the second IP address that we sent initially and then point against the target service so multiple answer worked very well with the loopback interface as we said 0.020 on unix type operating system and one to seven on windows however we were getting inconsistent result for our target specification for instance we'll work on the one time out of five so we implemented another technique called DNS cache flooding where so this technique works well on Google Chrome on all aquatic system and on Safari or in the iOS platform so we observed in a three

binding time we've the time varying attack and DNS cache loading at the same time from five to forty seconds the demo but Roger performed on iOS what is this technique and we obtained a five second remaining time flooding of the cache is performed in a separate in the web worker so basically what's happening in blue here we are in the side the browser console and you can see that in blue with performing the regular fetch against singularity and between all these fetch we're sending thousands of dumi requests for for resources that will flood the cache of the browser and will evict once the caches is a full evict singularity IP address so the only IP address that remains is the target IP

address which will facilitate the DNS rebinding so here we have waited a number of target specification and and platform and the strategy combination and what you can expect as a time to exploit in seconds so for instance on Windows that then if you used a mutable a strategy it takes approximately three seconds Roger okay let's talk about DNS rebinding protection bypasses using singularity we can bypass all known DNS rebinding protections such as those implemented in unbound or yes masks open source yes servers we would like to emphasize that common recommendations and default configurations often do not provide complete protection how do common DNS protections look like most solutions block certain DNS responses at the perimeter when they

enter your internal network some solutions block RFC 1918 IP addresses commonly used internally so just 10/8 or 180 mm 68 star 60 some block local host IPS 127 / 8 range some tools can be configured which IP addresses you're using internally if you're using public IPS you can configure those to be blocked some tools block the 0/8 range DNS mask and unbound are widely used open-source dns servers they are used in tools such as pfSense open wrt certain home routers have them there are also free public services dns services to just open DNS which advertise that they have a solution for DNS rebinding attacks in case of open yes they call it block internal IP addresses and they

block private eye peace DNS mask has a configuration setting called stop DNS rebind which blocks private IPs the 0/8 range and the 127th language this does not block local host will talk about what we mean localhost in a minute the unbalanced open-source DNS servers DNS server has a configuration called private address where you can configure the internal IP address range you're using and then blocks this range this does not block the 0 0 0 0 IP 127 0 0 1 and localhost or first bypass is using a 0.0.0.0 IP address this is a non-routable or invalid IP address but it works very well on Linux and Mac OS using Chrome and Firefox to access the local host

this bypasses protections that block DNS responses containing the IP address of one 27001 we look at a DNS request when we query singularity we specify the target here with 0 here 0 0 and then return DNS response containing an a record of 0 0 0 0 what if all internal IP addresses are blocked then we can use C names canonical name records our Guinness records which map one domain name to another domain name we can return a DNS cname record instead of an internal IP address suggest wikidot and jenkins internal whatever our target name is this bypasses protections that block DNS responses containing private IP addresses the local internal in a server will then resolve the cname and you

don't want to block internal resolution if you want to use DNS names internally if we query singularity we can specify the cname here wikithon XE 0 target and then we return again a cname record to week or third bypasses using a variation of the previous cname it's in this case we can return a cname of local host this bypasses protections that block DNS responses containing the IP address of one 27001 this works well on Linux and Mac OS as well we specified a local host in their request and then returned a cname pointing to local host

so now we're going to discuss the architecture we implemented in singularity to interact Li rouse the victim internal network after DNS rebinding so there have been as there there there is there are tools such as beef the browser express expectation framework and fire drill a DNS rebinding attack tool I can use a hooked browser to as a gateway to access environment that are typically not directly accessible by your attackers so we know that beef require you or the attacker to configure their browser to use beef application server as an HTTP proxy we don't know how fire drill does this because the code is not available but we decided to implement the browsing of a service Yahoo brother in singularity

without requiring the attacker to set up its browser to use HTTP proxy so at a high level this is how it works so once the Rabine rebinding as a punch the hooked browser will establish his WebSocket connection to singularity and a wait for instruction the attacker will then connect to his brought to his browser connect singularity and list all the target that were hooked and select one to two brows so what's happening let's say you want to browse the the home directory of service listening on 127.0.0.1 the attacker browser will make emits normals excuse me regular HTTP requests to the home directory by this time to singularity application server the singularity application server will translate this to a WebSocket fetch

operation and send this WebSocket request to the hooks browser the the JavaScript codes running on the hook browser will in turn translates this requests into a regular fetch API request to the target service and then will send the data all the way back to the attacker browser at the Louisville we just customize the Goyang rot run tripper interface which is an interface that represents request and response and you can mangle with them we use WebSocket Pentax protocol to package all the fetch request and response between all the party involved this nothing that increase the size of the message by for further of the original entered the message because we're using a basic C for encoding to package the request and

response you don't have to use your browser you can use any other user agents such as curl or HTTP inspecting proxies such as verb or zap or sequel map so we when we implemented this architecture we encountered a number of challenge the first assumption that we made but we didn't have to care about cookies but the victim browser will handle all of this force in a transparent manner however our first test case Deepika T which is a backup application but was very bored to DNS rebinding attack as you can see in this code sample extract sister of token from the cookie and it does is to generate the link to browse the application so when we tried this new architecture in

singularity didn't work because the link didn't tell the system token embedded so we had to read these cookies from the target browser so the victim browser will would is instructed to fetch the cookie from the service and send them to the singularity server when the singularity server set them on the attacker browsers so when the attacker browsers can generates the link with the CSF token so that's work well for HTTP on the cookies fun known as TP on the cookies or if you if your victim service is setting HTTP only cookies well we don't really care because javascript cannot read them on the attacker browsers so it are not being used so we don't need them on the

attacker browser either another channel we encourage is that to be able to read the cookies when we omit the fetch requests you know you must pass the option credentials include and if your application also require our HTTP authorization when you can completely forget about this and the reason why is that if you have a simple service that require HTTP authentication and you're in your console you can type this command you do a fetch request to the local service with reddit credentials include past's authentication dialog box proper which will warn the victim but an attack is ongoing however if you pass the credentials omits to the fetch requests no authentication dialog box will pop up so the victim will be none

the wiser so the the gist of it is that if your application requires HTTP authentication when we decided not to pass cookies Quadra all right now that Geralt introduced us to this local control concept we'd like to show you a first live demo of how this feature works if we have working internet so we will use two browsers one is the victim browser one is the attacker browser in our demo they're both on the same host but in a real-world attack it does not need to be so the attacker can be anywhere so this is chromium and we have the that's a victim browser which has a jenkins instance install in the localhost that's what we are trying to

exploit we have Firefox and this is the attacker browser so what you see here is the the hooked client that means the the victims should show up here once it's hooked and you reload this page there's nothing here so ask the victim we are setting it up manually and for this demo we are browsing to the singularity manager web interface we are setting the target host to zero zero zero zero this means the localhost we are setting the target port 8080 where our Jenkins instance is running we are using the hook and control payload we are using the multiple answers rebinding strategy an interval of one second and we are launching the attack now

we see the DNS rebinding is already successful in just three seconds we're going back to the attackers browser reloads the page and we now see this new session the victim session so we click on it and we should be able to browse the victims and Jenkins instance as if we were we would be able to directly access it and browse to financials for example or anything this works over the Internet wherever the attacker is this singularity here is just on the Internet we would like to show you how the requests look like in the victim browser bigger we see here the request to credentials which the attacker is browsing to we see the remote address set to 0 0 0 0 for

localhost and we see the request URL the origin is still pointing to the attacker want to show you also how we exfiltrate our data back to the attacker this is the s o WS endpoint so these are the WebSocket messages this is how we send the data back to singularity where the attacker can browse to it

now we're going to discuss how we implemented scanning of vulnerable hosts and services in singularity so they have been a lot of smart attempt to replicate the power of n map or network scanning we've had the power of raw sockets in the browser for our purpose it was it is often unreliable or did too much for instance we don't care whether quartz is a listening sorry whether SSH port is open or not the only thing we care about is does it speak HTTP because in DNS rebinding so far is concerned with the HTTP protocol only so this what we targeting for aiming for so our solution is very simple we use modern API so that such as fetch and abort and

wrap the fetch request we have a timeout outputted timeout so we distribute our scan target across four web workers we only fetch the resource headers during the scan and we implemented a hard time out of 300 milliseconds and we don't bother with the response body so the timeout will drive our fast scan can go so you the scanner would only spend a maximum of 300 millisecond per target if you get a fast response then it will be lower than batch if you don't get any response for instance be called because the pot is firewalled when you will have a hard limit of trailermate second and we'll move on to a new target so this is fast for open HTTP ports and

for close port cross spot because when you send a request to a close port you get the tcp/ip stack we respond immediately we've reset packets so in so you're not going to linger here it's slower for firewall ports because you don't get any response at all so you're going to hit the limit of 300 milliseconds and obviously slow for slower HTTP service and possibly protocol like SSH and stuff which are not speaking HTTP so you want to use at all timeouts when you're scanning the LAN and fast HTTP service you want to use higher timeout when you're scanning different network with a higher than latency such as a VPN over interesting piece of information we used

web RTC IP address leaked when a variable is available on Chrome and Firefox to obtain the IP address of the target browser and try to derive a subnet that we can scan when with cigarette II we obviously use fetch with credentials omits that so when we do a scan of the network there's no dialog box popping up and that will inform the victim by the scan is ongoing we're currently considering adding a second scan path for potentially slower services this is not to do lists so we have discussed how we can how image DNS rebinding attack more reliable how we made them faster we have means to scan for vulnerable services so now we're going to show you how you can automate

all that we are discussed to automatically detect and attack targets so singularity comma comes with Auto attack HTML automation file it is fully customizable it allows you to leverage all the features that we have discussed so far and so you can choose a specific exploitation payroll for instance you can target Ruby on Rails or you can a single write it to auto select the payloads based on the service it has detectives you can output your target selection or you can add security to search for more targets same thing for the for the courts the services you can configure your default DNS strategy strategy and asking rightit's who optionally auto optimize and find the best route

to use in a specific case for faster rebinding and obviously you have always your option such as flooding the DNS cache or hiding the activity from the user and so on so we intend to implement more auto optimization so you don't have to read our extensive wiki so when you're designing your attack you want to mix and match different specification of the same targets for the added reliability to bypass security controls and for speed so as we discussed on a look at the loopback interface you can use zero at zero at zero localhost and one to seven you can ask singularity to find and use the external IP address to exploit the internal interface of your routers or

Wi-Fi access points for device that's used a week and system model and I can only encourage you to look at the DEF CON talk in that manner to understand how it works and you should really do your homework and do some open source intelligence try to determine how a corporate environment names as assets so and you want to use a dictionary of service name and try to specify them as cname science for instance Jenkins that in general that cop comm which is likely going to pay off so we briefly mentioned service detection Social Security comes with a number of attack payloads targeting services such as Ruby on Rails or the AWS metadata instance so we recently

added a service detection routine to this payload so for instance if singularity detects but there is a HTTP header containing the value X Jenkins it's more of an active at it is pointing against a Jenkins instance so when you select automatic payloads singularity will try to detect sis the service and automatically deliver the appropriate attack it has so with without - we were hoping to blur the lines of origin and nothing we have achieved that with security of origin ends the name so how do you protect from DNS rebinding so you often read or hear but you should use DNS blacklist or sometimes people will uncertain actively maybe you should consider DNS SEC or use this DNS

provider or I bought this future states but it has DNS rebinding protection so maybe you should consider this well we learned but common wisdom is not enough it's hard enough to understand all the certainties of DNS rebinding and to devise appropriate protection is not easy and no DNS SEC doesn't help in that case at all so rata was the the best way to remedy ace vortex against DNS rebinding so there are three separate ways to properly protect yourself you can use TLS on your target service even on services listening on the local host you can require authentication if your tiger doesn't know the password to access your service they can't make you valued requests and you can validate the

host header for incoming requests using a white list of trusted value such as local host or 127 zero zero one remember the origin you know our demo still points to the attacker and this won't be in this whitelist there is also a proposal called course RFC 1980 which would require a pre-flight course request for websites hosting a public IP address making a request to a private IP address this is currently a draft and not not shipped in browsers but if it does it can prevent the other three right we have one live one last live demo where we would like to show you how to automate this process so previously the the victim was browsing to the single

RIT manager web interface Rick figured everything that's not very realistic so this time we we start with a with a port scan so you victim browsers to singularity launch reports can discover listening ports on the localhost rebind to them in three seconds all the detect the services and launch the exploit right away so for our demo we have rails console installed on a local host for three thousand and the Jenkins instance on port 8080 this is the victim browser and we are now going to browse to this auto attack demo site that's all the victim has to do and then the atop the attack launches automatically so we see here the already detected port 8080 and

three thousand it tries to rebind to those does the rebinding was already successful three seconds it detected Jenkins and rails for rails we have code execution a calculator and for Jenkins we are just dumping the plaintext passwords stored in Jenkins this is the source code of this auto attack script where we can configure what we would like to attack so here we have the rebinding strategy we can figure that we can say which attack payload we want to use so we say automatic automatic means it tries to automatically detect what's running on the service and exploit it if we have a payload available we can specify the ports we want to scan so it supports port ranges but for this demo

we only scan port 8080 and 3000 to make it fast and then we can specify the target service we use the zero zero zero IP address for localhost there are a few other configuration options but none of them are are required you can get our slides on this URL you get singularity on our github page with with all these features and we should have some time for questions okay anybody have a question hands up please

how much of the prevention piece of this is just to not run web servers on your endpoints well so if you don't run any web server on your endpoints when you're completely safe yeah but we found but especially in development of developer oriented companies and stuff but a lot of these services are running the other aspect as well if you have any service but is not running on your machine but let's say you have a Jenkins instance running on your on your network on your corporate network and you don't have automation setup oh you don't have HTTPS setup then you you'll be able to attack them using just the boss at the victim

I'm commenting on the thick client apps that I take a look at ones that you wouldn't imagine our web servers our web servers so I mean this is broadened just beyond the core development group but more of just you know your everyday users I don't know if you had any commentary and the proliferation of web servers on computers right there there is a proliferation of web servers in the corporate environment I think it's just down to the ease of implementing HTTP interface on your environment the success of a framework like electron j/s which make it easy to write an application for the web and for the desktop so yeah you're increasing your attacks your faith one you have both

listening and you need to consider the point cons of of doing version

you have a question

going once going twice alright I want to say thank you to Gerard and Roger thank you very much for a great talk