 Hi. So, for those of you that didn't catch that, my name is Luke Young, and I'm here to talk about Achieving Reliable DNS Rebinding in Modern Browsers. Thank you everyone who made it out here, woke up early and got your badge. Really appreciate it. All right, so, my name's Luke. Like I said, I'm a senior information security engineer at LinkedIn. I've been there for about a year now since I started full-time. I've interned at a couple different security teams at a few other companies. I see some familiar faces out in the crowd. That's my email address, both work and personal, linked to my LinkedIn profile. All of that will be up at the end if you have any questions. Just shoot me a message. And as mentioned, this is my third year at DEF CON. So, I gave a talk last year on the subject of attacking network infrastructure to generate a four-terabit a second DDoS for five bucks. And the year before that, I gave a talk about investigating the practicality and cost of abusing memory errors where I explored DNS bit flips. So, in case you don't see a bit of a theme there, I like networking stuff, specifically anything that has to do with DNS. So, when I heard a bit about DNS rebinding, I decided it was right up my alley. So, here's how we're going to talk about this today. We're going to establish a fictional company called ACME Corp. And we're going to use that for all of our references so that everyone can understand DNS rebinding. We're going to establish a network topology for this company. We're going to talk about how DNS rebinding could be leveraged in an attack against this company and then how to automate some of that using the tool that I built, which will be released at the end of the talk. And then finally, I'm going to talk about some of the practical exploits of DNS rebinding against some real tools and applications. All right. So, we have our ACME Corp. And we're going to start with an internal corporate network, which we're going to refer to as corp.acme.com. Of course, we need some employees. So, we're going to add a developer, Chris. Chris needs somewhere to commit all of that wonderful code that he writes to. So, we're going to add a code repository located at code.corp.acme.com. Of course, our developer, Chris, needs to get to the internet so we can look at cat pictures at work. So, we're going to connect the corp internet to the actual internet. And finally, we need our bad actor in this scenario. So, we're going to add our attacker who owns attacker domain. All right. So, a couple of quick notes about this architecture. First off, we're going to refer to this entire area on the right as the intranet, essentially the internal network of this fictional company. Next, we're going to assume that our attacker has insider knowledge of this network layout. So, whether your network engineer decided to post the entire network topology on his resume, on his personal website, or a disgruntled employee took some internal docs, I'll leave that entirely up to your imagination. And we'll get to why that's necessary in a little bit. For the sake of simplicity, we're going to assume that code.corp.acme.com has no authentication on it. So, Acme had a long meeting with their single employee and decided they trust their one employee and you have to be on the intranet in order to access this. So, they're not going to put authentication on it. Now, this is just an example. This code repository could be anything lacking authentication on your internal network. It could be a wiki page containing company secrets. It could be your internal HR system. It could be some marketing website for a new product that hasn't been announced yet. Who knows? It could be anything. And I don't think I need to ask people to raise their hand to about at least one of those things probably has existed on their network at some point in time. Everyone spins up something and goes, oh, it's fine. It's safe. It's only accessible on the intranet. Only our employees can access it. All right. Finally, the edge of our network, like I said, is going to act as a firewall preventing our bad actor from directly accessing code.corp.acme.com. So, the only way you can access that is again being on the internal network. And lastly, we're going to assume that our developer, Chris, just loves to click on links. Doesn't matter if it's a sketchy ad or a fishing email, Chris is going to click on that link. All right. So, before we get into how DNS rebinding works, I wanted to do a quick refresher on same origin policy and browsers, how they work. So, let's suppose that our developer, Chris, has browsed to attack our domain. Now, Chris has loaded our malicious website. It can start executing active content like JavaScript or Flash. Assuming he doesn't have any plug-in set up. But Chris likes to click all of the links. Doesn't like to install things like NoScript. And since Chris is on the internal network, he also has access to code.corp.acme.com in another tab. So, as you can see here, we have Hello World, their, you know, billion-dollar company plan from HelloWorld.CPP. All right. So, what if our attacker domain loads evil.js and evil.js makes a request to code.corp? Does the browser just let this through and we get a 200 okay? Of course not. This is blocked by the browser's same origin policy. So, same origin policy is exactly like it sounds. It checks if a request has originated from the same origin as the current, currently executing script. So, while a request to code.corp.acme will fail, our request to the same origin attacker domain would, would succeed. Of course, there are exemptions to same origin policy. You have cores or JSONP. But overall, same origin policy is actually pretty restrictive. You can't even do things like accessing a subdomain. That will get blocked by default same origin policy. So, but like I said, cores, JSONP, there are special exemptions to same origin policy but it requires opt in from the participating server. So, this is kind of same origin policy at the most basic level. This is what protects all of your information when you're browsing Facebook in one tab and your bank is open in another. All right. So, how does DNS rebinding play into all of this? DNS rebinding allows us to essentially trick the browser into making what it believes are same origin requests that actually reach different servers on the back end. So, let me get a little bit into how that works. So, let's imagine we have a browser run by our developer, Chris. We have our internal DNS server located at 10.0.0.1, our attacker server which we located at 137.137.137.137. And finally, our internal coder repository located at 10.0.0.99. So, our developer, Chris, goes to his keyboard and types in rebind.attackerdomain and hits enter. Now, our browser takes a look at this and goes, I don't know what to do with this and so it asks our DNS resolver for help. It says, can you help me locate rebind.attackerdomain and sends an A query. That A query gets sent along. DNS resolver goes, I don't know about this and so it asks the DNS root. The DNS root comes back and says, hey, if you want to know about rebind.attackerdomain, you have to ask attacker domain. They have all the info about that. So, it forwards our question along to attacker domain who goes and faithfully returns a response that rebind.attacker domain is located at 137.137.137.137. And we set a TTL of two. So, TTL basically says how long you're allowed to cache this record for. So, this gets sent back along through our DNS resolver all the way back to our browser. And our DNS resolver goes and saves that in its cache. Alright, our browser takes a look at IP and it generates a generic HTTP request. Note, this is an HTTP request, not HTTPS and we'll talk about that in a little bit. Our browser sends this. It gets sent along to our attacker controlled server and our attacker controlled server generates a response, sends it back to the browser and the browser renders it. So far, this is a completely normal flow. This is exactly how you would answer the infamous interview question, what happens when you type www.google.com and hit enter. So, this is where it gets a little messy. Let's imagine that our webpage that we just loaded wants to make a request to secrets.txt. Again, on rebind.attacker.domain. So, it sends this request. The browser goes, oh, I don't know what rebind.attacker. domain is and it asks our DNS server again. Our DNS server takes a look at that question and normally this is where the flow would end. The DNS server would say, hey, I have a cached response from last time. But if any of you have been timing, it's been more than two seconds since the last time we sent that response there and so our DNS resolver has completely forgotten where rebind.attacker.domain is located. So, it asks the DNS root again who gets told, ask attacker domain. This question gets relayed along to attacker domain and this time attacker domain sends back a different answer. So, we say rebind.attacker.domain is actually located at 10.0.0.99. This gets sent back to the browser. The browser goes along its merry way and generates an HTTP request and sends it along to the IP it was given. That of code.corp. Code.corp sees a request and because it doesn't have authentication, sends the response back and now our browser has a copy of the billion dollar business plan but it's loaded on rebind.attacker.domain where our attacker can read that file and exfiltrate it. So, if we take a step back for a second here, let's look at what happened. Did we violate the DNS spec? No. This is a perfectly legitimate answer. Companies do switch around IPs all the time and companies do have extremely short TTLs all the time. So, for example, companies that commonly come under attack will fast fluctuate between short TTLs so that they can change servers quickly. Did we violate the HTTP spec? No. We sent a regular HTTP request. This is all perfectly valid. So, this right here is DNS rebinding at its simplest. Basically, we've tricked the browser into rebinding the DNS record as the page was loaded. All right. So, if we loop back to that ACME network diagram, what we've done is just let our bad actor actually utilize the access that Chris had on the network in order to access the code exfiltrate data from code.corp. If you want to think about this in another way, what we've essentially done is let our bad actor assume Chris's position on the network in the physical sense. An easy way to think about DNS rebinding is if our bad actor was physically in the room and plugged into the same network jack as Chris. This company was already vulnerable or at risk to having all of their code stolen if you walked into their office and plugged into a jack, we've just eliminated the need to be physically present to do so. The other reason that analogy actually holds up pretty well is because we weren't able to assume Chris's authentication for code.corp. Just as if I walked into your building and plugged into a network jack, I don't know what your developer's password is. And DNS rebinding works that same way. Because when the browser access rebinded attacker domain, it wasn't the same DNS entry that all the cookies were saved under, which was code.corp, they won't get sent. So, it's an unauthenticated request. So, that sounds a little bit scary. Let's talk about some of the gotchas about this attack. For any of it to happen, Chris had to visit a malicious web page. Then we required internal knowledge of the ACPY network. And we had to know the internal IP of code.corp.acpy.com ahead of time. So, for those of you that don't work with split DNS, basically the way it works, if you're on the corporate internet, you have certain results that will only resolve when you're inside of the network. And the way that works is your DNS resolver takes, when it gets a query, it looks at it and says, is this coming from inside? Okay, let me serve it these records over here. And, oh, this request came from the outside. Let me serve it those records over here. That's called split DNS. So, we can't go query code.corp.acpy.com from the outside to know its IP. We had to know that ahead of time. And finally, it was, the DNS rebinding is notoriously unreliable. So, let's break some of these down and talk about how to get past some of these. First, had to visit the web page. I don't really feel like I even need to talk about this. If you honestly believe that I can't convince a single one of your employees to click one link, you're lying to yourself. And that's literally all you have to do. You just have to click the link. You don't have to click on the page or interact with it in any way. You just had to open it up. Of course, there are other delivery mechanisms for something like this too. You could serve this in a drive-by malware or a drive-by malicious ad. You could of course send phishing emails, all of the traditional ways to get someone to click a single link. Yep. The next thing we needed to do was we needed internal knowledge of the target network. We had to know that code.corp.acpy.com existed. Now, I wish I could say that would be difficult to obtain that sort of information, but I wasn't joking when I said your network engineer probably put the entire diagram on his resume. I've seen that before. And you have people leaking host names all over the place. All of those GitHub issues that your developer posts and accidentally includes all the host names in the debug log, people like me are scraping those all the time. It doesn't matter if you had it up there for 60 seconds, someone pulled it down and we have that host name now. Plus, these host names are typically built for people, you know? They're not that hard to guess. Code.corp.acpy.com. Get.corp.acpy.com. SVN.corp.acpy.com. Wiki.corp.acpy.com. They're very predictable. So let's say we probably didn't actually need to know that. Of course, we had to know it lacked authentication. There's no real way to get around that requirement. We can just try it though. So if I was a malicious actor, I can try it, see if it works. If it works, great. It didn't need authentication. If it doesn't, move on to the next target. And we had to know that secrets.txt was located there. But I don't really think this one's a requirement either. Again, all of our web pages are built for people. I'll bet you if I went and hit the root of code.corp.acpy.com I would get a beautiful directory listing with all of the nice icons next to every file telling me where secrets.txt is. It's not difficult at all for a script to do that and do some real basic checks for anything with the word secret in it. Anything with the word password in it, etc. All right. Next, we had to know the internal IP of code.corp.acpy.com. And unfortunately, people don't really leak internal IPs nearly as often as they leak host names. Thankfully, at least in some configurations, we can just use that host name. So DNS has this wonderful feature called CNAME records. They basically act very similar to a sim link on Linux. When your DNS client reaches a CNAME record, it just starts over the process with the value you gave it. So when I asked for a rebind out attacker domain, if I serve a CNAME for code.corp, my DNS resolver will get, say, oh, where do we go? Oh, let me go look up code.corp instead. And we've just now bypassed that requirement. And what's really, really interesting about this, we let the internal DNS resolver do all of this work for us. So even though that record isn't accessible externally, your DNS client that's looking up this record is coming from internal. So I can CNAME to internal DNS records that don't exist from the outside and they will faithfully resolve on the inside. Now, in theory, you could block some of this on your DNS name server. You could never let external DNS records resolve to an internal IP address. Unfortunately, as far as I'm aware, no DNS resolver with split DNS functionality supports this sort of setup. If anybody is aware of any that do, by all means, please let me know. I'd be more than happy to take a look at the implementation. All right. And the next problem. DNS rebindings notorious unreliability. So if you do manage to find some of the folks that have heard of DNS rebinding, one of the first things they say is, that doesn't work anymore. It's so unreliable. It's not practical in the real world. Unfortunately, this unreliability and kind of the stigma around it from everything is commonly used as an excuse to avoid fixing vulnerable services. Everything from small applications to popular libraries like one of the Ruby on Rails web console scripts has this issue and commonly developers will decide not to fix it because of concerns that it's not a real world attack. So let's talk about where some of that unreliability comes from. There's a lot of ways that this can go wrong. You have a lot of layers here, both in DNS and TCP and in the HTTP level. So first thing you've got is browser DNS caches. So some people don't even know this is a thing. Some browsers, Chrome for example, depending on your system configuration, implement their own entire DNS client. They don't use the OS one or they build on top of the OS one. And so internally to the browser, they actually have DNS records that are cached. So if you take a look, Chrome colon slash net internals is a wonderful tool if you're ever debugging any network issues in Chrome. It will actually tell you all of the DNS records that it has cached, how long they're going to live for, when they expire, you can view them in flight, actually, as they go across the wire. But things like this can interfere with a successful DNS rebinding attack. For example, if in certain configurations Chrome will cache all records for 60 seconds, even though the TTL is set shorter than that, which means I don't have to keep my developer, Chris, on the page for 60 seconds. And Chris has a really short attention span. So that's not going to work very well. And we have the same issue at the OS level. So lots of OSes now actually do DNS caching internally as well. So Chrome will actually, again in certain configurations, build on top of the OS cache as well. So you now have two layers of caching where your record can get mangled, get modified in some ways. And that can cause more problems. You have name server, DNS caches. So for example, that internal DNS resolver probably caches that record for some time. That also means if I'm executing an attack against Chris and Chris' fictional second employee at the same time, both of those records can get confused in the DNS resolver because one of them is cached. So we'll talk about how we kind of get around some of that later. Browsers. So browsers have some protections here as well. Some of them will pin DNS records. So basically what that means is when you get a DNS query and an answer, it will save that tuple together. So you have the host that it looked up and the IP address it resolved to. And they won't let that resolve to a different IP on the same page. If you open up a new tab, it'll go make a new query, but that way you can't rebind on the same page. Some of them have done stuff like blacklist really dangerous ports. I'm pretty sure it's actually the same list between all the browsers for the most part of common ports that have had issues as a result of DNS rebinding or even other just generic XHR things. So for example, the SMTP port or I believe SSH is in there as well. You basically cannot make requests to those ports when it's on internal RFC 1918 IPs. And then some of them have some failed attempts at detecting DNS rebinding and trying to avoid it. So they try to look and see are DNS records changing in between responses. I have yet to see one of those actually really work super well. So give that. You have network protections. So this is kind of interesting. You can actually try to fix some of this at your DNS resolver. So DNS mask on the top has some settings that you can turn on to basically try to prevent DNS rebinding attacks. And open DNS has a similar commercial actually it might be free if you already have an account with them that you can turn on and it will try to prevent some of these attacks. Now the really important part with all these network protections is they only work if you can figure them correctly. And nobody does. So lots of people will block for example local host. I can't set a DNS record that resolves to 127001. But I can set it to resolve to 192.168.1.30 which is your IP address on the network still. So if you do use things like this and these are not a solution for everyone and they will not fix the problem overall, you have to make sure you can figure them correctly. And then finally just the general hackiness of this sort of approach. So we'll touch on that again in a minute. Okay. So this is DNS rebinding. Why isn't this fixed yet? This has been around, this has been a known issue. Like you said, this is an old attack. This has been here forever. Why isn't this fixed? Arguably it's not the browser's fault. And it's not that easy to fix either. There are legitimate use cases for all of this functionality. For example, if any of you guys use Plex, the media server, Plex will commonly trigger DNS rebinding warnings because of the way that they do their local network configuration. I believe Spotify as well will actually do if you use any of their web client, they have this feature where you can go to browse music on their site and click play and it opens up in the browser. The way some of that works is do basically a DNS rebinding attack and it will trigger some of these issues. So you will break legitimate functionality if you try to fix this. So there are open bugs against a lot of the browser vendors. It's basically asking them to fix these and most of them have come out and said we're not going to fix this. So Firefox's response was I'd also recommend that Firefox not fix this issue. It's not feasible for the browser to protect the user from DNS rebinding attacks. Servers need to protect themselves by validating the host header and firewalls need to protect themselves by preventing external names from resolving to internal IP addresses. Okay. So and we're going to talk about those protections in a minute and we're going to show a demo. But there are some things they can fix. So for example, there's this wonderful feature called HTTP 0.9. So for those of you that aren't aware, HTTP 0.9 is a very lenient parsing of HTTP. So the way that works is if I have a, I send a request and the server doesn't answer back with a full HTTP 200 okay, we still let the request go through and we continue talking to that server. This can be really, really problematic because you have things like for example, Memcached or Redis that speak line protocols that you can actually attack using this thing. So you send a request to Memcached. Memcached says I don't know what this is. I don't know what this is. You know, they basically returns. I don't know because it's a line protocol for every line of your HTTP request until you reach a command and you can then send commands to these and it never answers back with a valid HTTP request. So this is here because of legacy reasons. This was a lot more common back when basically servers weren't configured right. You had a lot of legitimate use cases for this. There aren't really any today and most of the browser vendors have decided or are working on getting rid of this functionality. Either they're actively turning it off, they have plans to turn it off or it's turned off already. So here are two examples of that both in Safari and Chrome. So this is what I would ask that the browser vendors do. Turn off HTTP 0.9. After that it's on each of the applications to fix this issue. All right. That general hackiness. Let's talk about how we're going to fix this. This is a weird attack. It wasn't designed to be abused in this way and so it just doesn't work sometimes. So like any true engineer I decided the best way to fix this was brute force. So basically what we're going to do here is try a whole bunch of DNS rebinds at the same time. And we multiplex that out across a couple different iframes and we take whatever one succeeds and save that. And then we use that again next time. We know that this technique works against this user. At this point in time we're going to try that attack first. A couple other things we wanted to do. So I took a look at some of the existing tooling that's there for DNS rebinds. And some of it's great. There's a couple different ways you can do DNS rebinds and the tools in support all of these ways. They didn't have some features like IPv6 DNS rebinding. Basically I could not find a tool that that works correctly in. I wanted to have that sort of intelligent method selection. So certain methods work better in certain browsers. I wanted to be able to have the server try to target this DNS rebinding method versus that one for a certain browser. And then finally I wanted the ability to have dynamic payloads. So some of these tools the way they work you write up an HTML page and put it in with the tool and you have to serve that tool and get it running on the network. And you can only serve that one payload or you have to go and restart the server every time you change the payload. That's not very efficient. We want to do that better. And then finally some of these tools do some really interesting stuff with the TCP stack. So either listening on all ports or attempting to listen on all ports. I saw one that I don't actually think worked. I was using libpcap to try to detect when a request came in and spin up a listener first before it actually handled it. We want to avoid all of that. We want to do basically on the fly IP and port allocation. So when I have a request come in that I want to attack this server on this port. The server goes okay give me a second, grabs an IP, grabs a port and triggers that. So let's talk about quickly about what the different types of rebinds that this tool supports. So TTL rebind this is kind of the simplest rebind. This is the one I showed you guys earlier. So basically you rely on the TTL expiring for that record. So you send one answer and then immediately flip any time you get asked about that question again you send a different answer. And then you exponentially back off on those TTLs to handle weird edge cases with caches. So this is what that looks like when you're actually triggering an attack. So those are flipped around. There should be the other way. So the first time, no actually that's correct. Sorry. So the first time you get a question you respond with the server's IP and a TTL of say two seconds. The second time you get a question you respond with the internal IP address that you're targeting. All right. Pretty simple. Threshold rebind. This relies on basically the second DNS request. So you say after I receive this threshold of questions, change my answer. So the reason this happens is you get really weird configurations for some of these caches. Some of them will send the same question like three or four times. Even though there was only one question internally that triggered it. So things like the TTL rebinds can get really messy there. So basically what this says is I got one request. I got two requests. I got three requests. Okay. Change my answer. And so you do the same sort of thing. You send, you set up one of these with a couple different back offs there in terms of timing. All right. Multi record rebind. So this one is super interesting. This one is, was I believe most publicly talked about, I think at DEF CON 18. And the way it works is very interesting. It's nearly instant in most configurations, but it's really expensive to, to host on the other side. So the reason that, that it's expensive is this. So I get a question for my DNS rebinding record and I respond back with two records. I say rebind.attacker domain is located at 203 and at 192.168. And some browsers basically if, if you're following the POSIX spec and everything correctly, you should try both of these IPs. Not all browsers do, some of them do, especially if they've been like Chrome will try to do this if it's, because it has its own custom DNS stack. So the way this works is the page loads, the first time you get a query to 203, you serve up your payload. And then on your server, you blacklist the IP address here. Literally set up an IP tables rule to block any new requests coming from this client over here at Acme Corp. Then when I go to make an XHR request, it goes, it tries to make an HTTP request to 203, it fails because it's blocked in IP tables. It can never complete the TCP handshake so it falls due to the second record. This one is super interesting as well because it defeats a lot of the protections in place by some of the browsers or some of the other DNS rebinding tools or detection. Because it's only one answer and it's just two records. There are legitimate reasons to serve round robin DNS like that. Lots of companies do. One of the problems with this though is the spec, I don't actually know what the spec says about this but lots of ISPs will actually rotate those answers. So you can't guarantee that they're going to show up in the right order. And the only way that this attack works is if your attacker server is served as the first request. So yeah. And the other reason it's really expensive to host is you have to cycle IPs very quickly. So if I blacklist the IP of you at Acme Corp and I'm trying to target another employee at the same time, they won't even be able to get the page to load because it's already blocked by their IP address. So what you have to do is you have to maintain a pool of IPs and basically dynamically allocate them out and say, oh, I'm targeting two people at the same company here, we have to give them different external IPs. And IPv4 IPs are getting harder and harder to get a hold of, especially if you're hosting on really cheap VPSs like I am. All right. So this is the usage of Janus, or not a Janus, of Jacket. So this, it's simple. This was the idea was make it as simple as possible and hide all of that. Do all of that for you in the background and you don't have to worry about it. Basically include the rebinding JavaScript and then use a standard JavaScript fetch and it's magically done for you on the back end. So hopefully, demo question mark, we'll be able to see this live. So let me a second. So we've got, up on the top, I have a server which I now have the tool running on. So the tool is written in Golang. It's up on GitHub right now. I'll have the link at the end. And it's pretty easy to use. Basically you provided a couple tools. You say what is the base URI that I'm going to serve from? So in this case v1.rebind.attack or domain. And then you serve, let's see. Okay. So you pass it a pool of IPs that it's going to be able to use. So in this case we have some IPv6 IP addresses. We have some IPv4 IP addresses. And I wanted to show this is one of the features of the tool as well. This is an internal IP. So this is a digital ocean box. And they have this thing called anchor IPs that basically it's an external IP but it comes to your box as an internal IP address when you look at it. So that's a configuration that's kind of interesting. The tool is built to handle some of this. So basically you can provide a mapping and say this internal IP is actually this external IP and it will serve the correct DNS records. So that means you could actually, if you really wanted to, you could put like this tool behind a load balancer or something. If you for some reason needed to do that many DNS rebinds. All right. This is the problem with live demos. All right. So here we go. Hopefully. So what I've got here on my attacker server, oops, we've already got it triggering in the other tab. So what I've got here in the bottom left tab is a basic Python HTTP server. And right now it's listing to the world serving up the entire file system. This is a brand new VPS. So not actually anything on there. Please don't go try to pull SSH keys or anything off it. You'll waste your time. So hopefully I'm having network issues this morning. So. All right. So you can see what it's doing here on the left. Apparently we don't have an Etsy password. So someone has already gotten to this box. Um. But we can see there that is the 404 page from Python there on the right. So it did actually trigger a rebind and request the file even though that file doesn't seem to exist. So if we take a look at actually in the network tab here you can see kind of how the attack works. Loads up the JavaScript. It starts a web socket with the back end where we send some information. Uh it loads up a bunch of iframes. And so you can see some of these hopefully uh are red. So these are the ones that failed to load cause they directly rebinded. So you can see it's trying the multiple attempts. It starts pinging. We see success here. Once it finally hit a successful one, deletes all of the frames and makes our request to Etsy password. Which of course resulted in our 404. And so what that looks like here on the back end. This is running in extremely verbose mode. But you see it goes. It finds IPs meeting certain criteria. So for example if there were multiple people I was targeting here. Like I said it would balance between IPs. It'll go create HTTP servers on the fly. It leases the IPs basically. Um and then it goes and serves all of that. Alright. I'm running low on time so we'll hopefully. So how do you fix this issue? Here's the suggested mitigations. First off add strong authentication to your services. You should be doing this already. Anything that is vulnerable to DNS rebinding for the most part. You already have risk there of someone internal to your company taking that data. You should put strong authentication on everything. Even if it's internal. There are cases where that's not possible. For example local tools that are bound to loop back. Uh one of the ways that you can do some of that is verifying the host header instead. So you take a look at what the host request is. So for a legitimate request that host header will be 1-2-7-0-0-1. In the case of a rebind it'll be rebind dot attack or domain. So you should whitelist. Here is the expected host that this machine will ever be served on. For example wiki dot code dot or wiki dot corp dot acme dot com. That's the only address that should ever be accessed as you should whitelist that. So um I'll have a link at the end. We have a blog post up on the LinkedIn engineering blog with a link to the tool and some of this. We actually linked to uh how Kubernetes fixed this issue with their local tool. They basically did this. It's a really good implementation verifying the host header. They just check against a couple reg X's. Make sure you anchor the reg X though or else it doesn't work. And then finally adding TLS can be in a way to fix this as well. The reason is if you have your HTTPS cert it's only valid for wiki dot corp dot acme dot com. If you have a rebind that host name doesn't match and so the the rebind will fail. However you're relying on your developer not to just click okay on the cert mismatch. So not the best fix. Alright. So super excited to announce that this tool is live right now on the LinkedIn GitHub. Uh you can go check it out. Uh it's released under BSD 2 clause. Um and it's all go lang more than happy to uh accept some some inputs on it uh or file any issues. What is the future of the tool? Uh bug fixes. Lots of bug fixes. Uh if you have it and it doesn't work under certain configurations please open an issue. I'd be more than happy to take a look at it. I'd love to dockerize it or something similar so that you can literally just drop this on a VM and get it running. Uh and and then what I would really love to see is automated browser testing. I like to set up sort of a browser stack type setup where you can see oh they changed the DNS handling on Windows 10 for this version of Firefox uh and get alerts for a site or sort of that so that we can improve the tool. Alright. So like I promised here's all of my information. Um I will have the slides up on my blog. The uh blog post is actually I'm not sure it's up on the security blog yet but it's on the engineering blog that has a link to all of the mitigations in more depth along with uh all of the actual code or there's a direct link to the code. Thank you. Okay. A couple of announcements here. Um first of all uh we are not going to be dumping the rooms at least for now so people can hang out if you want to hang out for the next talk. But just kind of be polite. Last year we had some issues with people just kind of camping out all day. There's a lot of people getting here today. There's uh not a lot of stuff going on at the same time so be nice to other people. Kind of cycle through. Um yes yes. Oh and and this is more critical. If you're walking to that side don't. Exit out the back. Exit out the back. Exit out the back. Well look at that. That was fun. I feel like I'm playing a real time strategy game. Just draw the box. Through the back. Through the back. Okay. Second major announcement and this is going to apply in every track all weekend. Uh really the only danger to the con is the fire marshal. And the fire marshal can come in and say nope nobody's playing this game anymore. If we do something like stand along the walls. See all those people back there along the walls? They're now sheepishly moving towards the seats. Yes those people are doing it wrong. Um so what we're going to have to do and this is a change from prior years where we kind of let you mill about and sits uh that as long as there was a path it was cool. This year it's not cool. So find a seat or you're going to have to leave the room. So that's going to mean we're all going to need to make friends. Sit together. Learn how to defragment the room. But we'll deal with that again here in a few minutes. Um let's give our first speaker another big round of applause. That was a heck of a job.