 Okay, so specifically what I'm going to be talking about is how an external attacker can gain access to the internal administrative interface of a lot of these standard consumer grade home routers. First of all though, my employer asked me to put this slide up. Basically stop calling them. I did not do this work for them. I did this work, in fact, before I started working for them, so stop sending your death threats there. Send them to me. All right, so why did I choose home routers as a target? Well, they're easy. Their security is terrible. I had like 30 more screenshots I tried to fit on this slide, just didn't work. And even if you figure, okay, my router doesn't have any bugs in it, which it probably does, most people just don't secure them very well. I mean, typically these are people who have no idea how to do anything related to networking or security. So the concept that they will securely configure a network device is just completely flawed. So how does an attacker gain access to the internal web interface of a router? Well, he's not on the land. So typically it turns out you can either do it one or two ways. Cross-start request forgery or DNS rebinding. Now, cross-start request forgery is really the most popular way because it's super simple. But it has a lot of drawbacks, especially when you're going after routers. First of all, there's typically no trust relationship between the client's browser and his router because they never log into their routers. So you can't take advantage of that. Secondly, you can't fake a login if the router uses basic authentication. Everyone remember how he used to be able to do user, colon, password, ad, and then URL? Yeah, that doesn't work anymore. IE doesn't even recognize that as a valid URL and Firefox will pop a warning to the user. A lot of routers, well, not a lot of routers. Some routers, such as this one that I'm going to be demoing later, actually have anti-cross-start request forgery mechanisms built in. So you can't do cross-start request forgery at all against those. And finally, of course, cross-start request forgery is limited by the same origin policy in the browser. And that's always been its biggest limitation. And if you're not familiar with the same origin policy, basically the browser says, okay, if you browse out to attacker.com and you load up some JavaScript from that site. That JavaScript can interact with any page on attacker.com, but it can't interact with Google.com or Yahoo.com or 192.168.1.1. And that's good because you don't want some random person's JavaScript interacting with your router, like we'll see later. So that's where DNS Rebinding comes in. And DNS Rebinding says, okay, if the browser is going to enforce security based on the domain name, let's just tell it that my domain's IP has changed. So the idea is you get someone to browse to your website, load up some JavaScript from attacker.com, and then say, oh, attacker.com's IP is now at 192.168.1.1. And the browser says, oh, okay, that's fine. And now that JavaScript can interact with the router. So this has been known for a really long time. DNS Rebinding dates back to, like, 1996. It's really old. And so browsers and plugins and everyone have put in these mitigations and band-aids to stop this. But they've never really fixed the actual problem of DNS Rebinding, which is a bad security model. And we also have services like OpenDNS, NoScript, and DNS Wall. And basically, all of these protections are designed to protect your internal network. And the way they do that is they say, okay, if you're an external domain, you shouldn't be resolving to an internal IP address. So they block anything that resolves to an internal IP. So there's a couple of ways to do DNS rebinding. The method I'm going to present is my favorite, because it's really the slickest of them all, I think. And it's better known as DNS load balancing. If we have any DNS admins in here, that's all it is. All right? So if you do a DNS lookup on Google, you don't get one IP address back. You get five. And the reason that is is if you're going to Google on one IP and that IP suddenly goes down, your browser can automatically switch to the next IP address. And so it provides redundancy. But if we try to use this in a rebinding attack, we find that we can't actually use it to rebind to an internal IP address. So let's take a look at rebinding to a public IP first, just to see how this works. All right? We have an attacker who has registered the domain name attacker.com. He legitimately owns that. And he has a server located out on the internet with an IP address of 1.4.1.4. Now he wants to attack a public web server that has an IP address of 2.3.5.8. But he doesn't want to directly connect to that server. So he's going to proxy all of his requests through this random person's browser. And this person is sitting over here behind his firewall, feeling very safe and secure. So what the attacker does is he has to get that browser to browse out to attacker.com. And the browser doesn't know where attacker.com is. So he does a DNS lookup. And the attacker's DNS server says, oh, yeah, I have two IP addresses, 1.4.1.4 and 2.3.5.8. And the browser has no way of verifying that. So he just trusts it and says, okay, you've got two IPs, that's fine. So the browser is going to try the first IP address first, which is the attacker's legitimate IP, and he's going to do a get request and the attacker will send back his JavaScript. And that JavaScript is going to immediately attempt a connection back to attacker.com. And the browser says, well, you came from attacker.com, you're going to attacker.com. My same origin policy is happy with that. But as soon as the browser attempts that connection back to the 1.4.1.4 server, that server responds with a TCP reset packet. So now the browser says, crap, that IP is down. Oh, but I have the second IP address. So it immediately switches over to the second IP, which is 2.3.5.8. Sends the request there, and as long as the 2.3.5.8 server doesn't care that the host setter says attacker.com, which unless you're using virtual servers on your web browser, you probably don't, it'll just send back the HTML code. So now the attacker's JavaScript has full interactive access to this other website, and he can send requests and see the responses and parse them and send them back to the attacker if he wants to. And this has always worked. And yeah, there are some security implications here for bypassing ACLs and that kind of thing. But the big problem has always been, OK, we don't want people interacting with stuff inside the network. So let's take a quick look at going after the internal IP. So I don't really care about that 2.3.5.8 server. That's not what I want. I want 192.168.1.1, which is the router, the client's router. Same scenario as before, browser browsers out to attacker.com and has to do a DNS lookup. And now the DNS server says, oh yeah, I have two IP addresses, 1414 and 192.168.1.1. The browser says, ah, you have two IP addresses, but one of them is an RFC 1918 non-routable IP. So the browser will always try non-routable IPs first, regardless of their order and the DNS response. So he's immediately going to just load up the router's web page, which does the attacker no good, because the attacker has zero presence in the browser now, because the client never made a request out to his server. So you can basically rebind to any public IP you want, but not to a private IP. But we can actually leverage this to attack the router, because routers have both a public and a private IP. And to understand how that we can actually accomplish that, let's take a look at how services get bound on the router. This is a screenshot of a net set output from an open WRT router. Look at the interfaces. Look at how it's binding to interfaces. It binds to everything. All the services are bound to all interfaces. So these services are actually listening on your WAN interface. But what stops a random person out on the internet from connecting directly into them is your firewall rules. And these are very simplified, just what's pertinent to the talk, obviously. But basically, this says, OK, my WAN interface is eth0. So I don't want people connecting in on eth0. So anything that comes in on eth0, drop it. And we'll accept everything else, because everything else is an internal interface. And there's nothing really wrong with this. But you notice we're, again, applying security based on a name, the interface name, not based on IP addresses. And where this comes back to bite us is when you look at how the underlying operating system on the router handles IP packets. So RFC 11.22 defines two models for implementing an IP stack. The first is the strong model. And the second is the weak model. Which do you think is better? Well, actually, the weak model is the more prevalent of the two. It's used by Linux, PSD, and even previous to Windows. So if you take a look at how the weak model works, it says, OK, if I am any host, doesn't matter if you're a router or anything. If you're a host and you have a packet come into you, you look at the destination IP. And if that destination IP matches any of your IP addresses on any of your interfaces, accept it and process it. So let's say I get a packet in on eth0, and the destination IP matches the IP on eth1. I'll still accept that packet. Because it's obviously intended for me, even though it technically came in on the wrong interface. So let's look at all this in the context of the router. You've got a router with two interfaces, internal and external. The external interface is eth0 with an IP of 2358. So what happens when our internal client tries to browse to 2358? Well, he's going to send a TCP send packet to the router, because the router is his default gateway. And the router is going to say, ah, well, this destination IP is one of my IP addresses, and it's going to port 80. And sure enough, I've got a service listening on port 80, because remember, the services get bound to all interfaces. So there is in fact a service listening on 2358 port 80. And so it completes the 3-way handshake, and now the browser has connected to the web server on the router using the router's public IP. But we had that firewall rule, remember? The firewall rule that said block everything coming in on eth0, why doesn't it block this connection? Well, if you look at the packet capture, the top window is eth0, and the bottom window is eth1. That router, that firewall rule that said block everything on eth0, never got applied, because there's never any traffic on eth0. The logic for the weak end system model occurs pre-routing. So nothing gets routed from eth1 to eth0. Everything gets accepted and processed on eth1, even though technically, you're connecting to an IP address that's assigned to eth0. So ultimately, what this means is an internal client can punch in the public IP of their router and get the internal interface. OK, big deal. He's an internal client. He can access the internal interface anyway. But I as an external attacker can rebind an internal client to any public IP I want, including his router's public IP. So let's take a look at the same attack. But this time, instead of targeting 192.168.1.1, we target 2358. So again, internal client browsers to attacker.com and has to do a DNS lookup. Now, the DNS server sends back two IP addresses. Again, 1414 and 2358. So the browser tries 1414 first. Attacker sends back his JavaScript. That JavaScript tries to connect back to attacker.com. And now the attacker server sends back a TCP reset packet, which forces the browser to switch to the 2358 IP, which the router accepts and sends back the HTML code for whatever the request is. So now an external attacker can provide an internal client with JavaScript that has full interactive access to the router's web interface, even though that router has remote administration disabled. So this attack has a lot of advantages. First of all, the rebind is nearly instant. Okay, so if you're doing like an anti-DNS rebinding attack, you have to wait a certain period of time before you can actually do the rebind. I mean, as soon as the browser realizes, hey, I got a TCP reset packet, it switches over to the next IP. We also don't have to know the router's internal IP address, which is really nice because different vendors will have different default IPs and people can change their internal network and that kind of thing. But we don't care about the internal IP because we're rebinding to the public IP, which by definition is public. So we can get that pretty easily. And finally, this is just how browsers work. This works in all major browsers. But the downside is we have some very specific requirements for the router. So the router basically has to have three requirements. It has to bind its web service to the WAN interface. The firewall rules have to be based on an interface name or some other configuration that basically does the same thing. And it has to implement the weak end system model and it's underlying IP stack. So not all routers are gonna be vulnerable to this. I went ahead and tested 30 routers. It worked against 17 of them. And that includes stuff from ASUS, Belkin, Dell, which I didn't know they made routers, but apparently they do. Thompson, which if anyone here is from the UK, these are pretty popular over there. I didn't get a chance to test the BT Home Hub, which is also really popular over there, but it's a rebranded Thompson. So there's a good possibility it'll work against that as well. Lots of linksys. This works against a lot of linksys devices. And I really like this slide, because those bottom two routers, the 54GL and the WRT-160N are both on Amazon's top five most popular selling routers list. Awesome. So a lot of people put third party firmware on their linksys routers, especially 54Gs. And it works against those too. Now I will, in PF Census Defense, I will say they actually contacted me like a month ago when they saw this talk up on the Black Hat page and the DEF CON pages. And they actually have fixed this now. They have anti-DNS rebinding stuff in their beta release. So kudos to them for that. As far as I know, they're the only router that actually has any of that in it. So that was awesome. My favorite though are the action tech routers. Anyone here have Verizon, Fios, or DSL? That's it? Really? Okay, well, everybody where I live has a Verizon Fios. And I saw an article on some business site, I forget where it was now, just last week. And Verizon claims that they have 3.8 million Fios customers now. That's not DSL customers, that's just Fios customers, internet customers. So I went ahead and I tested a lot of these action tech routers. The GT701 and 704 are both DSL routers and those are distributed by Verizon and Quest. The MI424, there's two of them here. Revision C is on the bottom and revision D is the one there on the right. Those are the Verizon Fios routers. And what's really interesting about the Fios routers, these action techs, MI424s, is action tech doesn't actually make the firmware for them. They actually purchased third-party firmware called OpenRG, which is a Linux-based firmware from a company called Jungo. And Jungo has partnerships with Linksys and US Robotics and Belkin and obviously Action Tech and others. And they claim that this firmware is deployed in every 23 million households worldwide. Also awesome. So we have a really big attack platform. Okay, there's a lot of people out there who are running routers that are potentially vulnerable to this. I mean, again, I only tested 30 routers. There's obviously more out there than that. But just based on the ones that I tested, there are millions of networks out there using these routers. So we have to take it a little step further. Now that we've proven the attack works, we have to make it practical. All right, if you just go up to someone and say, oh, I can see your internal login for your router, they're like, who cares? So first of all, we have to make this an attack that the attacker can just like fire and forget. A complete drive by attack. So we have to obtain the router's public IP before they ever do a DNS lookup on us. And that's actually fairly easy to do. But the bigger problem is we have to coordinate all our services. So the DNS server and the web server and the firewall all have to maintain the right state for each client that's browsing to you. And that requires a little custom code. And finally, we have to do something useful with it. Once we actually do the rebinding attack, we have to do something useful, something that people will go, holy shit, that's bad. So I went ahead and wrote Rebind, which is probably the most cleverly named tool ever. So basically it does everything for you except to register a domain name. It actually runs two web servers. It runs a DNS server. It interfaces with the IP tables, firewall, and Linux. It serves up JavaScript code to the client when they do the initial request. It also implements an HTTP proxy for the attacker to interface with the routers. And basically the HTTP proxy and the JavaScript code act together to forward requests from the attacker to the client. The client then sends it to the router, and then the router sends it back to the client and the client sends it back to the proxy and the proxy sends it back to the attacker. So I love the robot devil, by the way. He's awesome. So let's take a look at how this works when an attacker's running Rebind. Okay, again, same scenario. But the attacker's now configured Rebind to run on his 1414 server. Now before the attacker can get someone to browse out to Rebind, he's gotta configure his domain. So first of all, he has to register a name server. So if Rebind is gonna be handling all your DNS lookups, you have to make sure all the DNS lookups come to the box that you're running Rebind from. So the attacker has to go into wherever he registered his domain, GoDaddy or wherever, and has to register the 1414 IP as a name server. Just call it ns1.attacker.com. And then once that's done, goes into his DNS configuration for the attacker.com domain and say, hey, my DNS server is ns1.attacker.com. So let's make sure that all DNS lookups come to the box where Rebind's running. So Rebind can handle all the DNS lookups for your domain. So he gets the client to browse out to attacker.com slash init, INIT. So again, the client has to do DNS lookup. But at this point, Rebind doesn't know the client's public IP. Because the source IP in your DNS packet that you receive is not gonna be the client's. It's gonna be some random DNS proxy or caching server. So Rebind's just gonna say, I'm at 1414. Is it one IP address? That's it. But now the client says, okay, I know where you are and initiates a TCP connection to port 80 to do the GET request. But now that he's connected directly to the Rebind server, Rebind server says, ah, now I have your public IP. Your public IP is 2358. So what the web server does is it generates a random subdomain of attacker.com and redirects the client to that subdomain. Now the client says, okay, this is an HTTP redirect, no problem. But it's a new subdomain, so I have to do a new DNS lookup. Now he does a DNS lookup on the new subdomain, which, so by the way, WACME was actually a randomly generated subdomain when I was testing. Yeah, I was like, that's going in the slides for sure. So the client now has to do a DNS lookup for WACME.attacker.com. So the DNS server says, aha, I can't really see your, the actual client who's making this DNS lookup. But I know the web server just redirected 2358 to WACME.attacker.com. So if you're doing a DNS lookup for WACME.attacker.com, your IP must be 2358. So now he can send back the DNS response packet that has the two IP addresses in it. So again, as before, the browser tries the first one first and does the web requests and Rebind sends back its JavaScript code. Once the browser has that JavaScript code, Rebind tells the IP table's firewall, block everything coming into port 80 from 2358 with a TCP reset packet. So when the JavaScript attempts the connection back to the Rebind server, it gets the TCP reset packet and now the browser is going to Rebind to the second IP address, which is the router's public IP. And so now the JavaScript has interactive access to the router. Now, once this happens, Rebind's, the JavaScript code starts sending queries back to port 81 on Rebind, because it's still blocked on port 80, so it sends it to port 81. And basically these are just pull requests saying, hey, what do you want me to do? And at this point, Rebind doesn't have anything for it to do, so it's not going to send back anything. But once these pull requests are coming back, the attacker sees the IP address pop up in the web interface. So all he has to do is click on that IP and this request is going to go through the Rebind HTTP proxy. So Rebind says, okay, you want me to do a get request on the index page for 2358, no problem. So it holds the connection open to the attacker's browser and when the next pull request comes back from the JavaScript, it says, yeah, I have something for you to do, do a get request. And so the JavaScript doesn't get request, gets a response, sends the HTML code and the HTTP headers back to the Rebind server which forwards it on to the attacker's browser and now the attacker sees the web page in his web browser. It can click around and submit forms and pretty much do whatever he wants at that point. So demo time. Now, so the best way to find bugs in your code is to do a live demo. I found a really fun one in middle of my Black Hat demo. So we'll see if it crops up again here. But so I've already had the Rebind server running on this box here. This other one is my internal client. This is the ActionTech Verizon Fios router. So as an attacker, all you have to do is once you've configured your browser to use Rebind as your HTTP proxy, just type in Rebind and you get the web, let me see if I can full screen for this so it looks a little better. Yeah, so you get the web interface there. So I'm gonna get my client to browse out to the attacker.com domain and we should see them pop up over here. There you guys. All right, so now if I click on them, I should get the main page for the router. So that's the internal web interface for the router. Now, the ActionTech firmware, the firmware that runs here is actually kinda smart. It forces you to change the password. So trying to prevent like default passwords, but all of the Verizon techs change the password to password one and no one ever changes that password. So we click okay and we should get, hey, we're in. So you only have this access for as long as the client's on your page. So it behooves you to go into the advanced settings and enable remote administration. And there are like seven pages you have to click through on this stupid firmware to do that, but that's okay. Yes, I wanna proceed, thank you. So I'm gonna go ahead and enable remote telnet. And there we go. Okay, so the settings have been changed. We're done here. We've enabled remote telnet on that box. And the login's the same, admin, password one. Now this gives you this wireless broadband router shell. Just type in shell and you get root. How am I doing on time, by the way? Where's my guy? How am I doing on time? How many? Awesome. Okay, so I got time to do a little bit more with this. So these routers run Linux underneath, right? And they don't have a lot of really good tools on them like Netcat or Wget. Some of them do, but this particular one doesn't. So I went ahead and cross-compiled a quick scanning slash TCP connect tool to run on the ARM-based processor that this thing has. And you don't really have a whole lot of networking tools, but you do have TFTP. Oh, yeah. So I just TFTPed down the tools. I'll just mod it here real quick. All right, so now I can go ahead and scan IPs and ports on this internal network. And really, you can cross-compile anything you want and put it on here. The ActionTech guys actually do release some of their tool chain tools for doing that. So if you want to see a list of internal clients, of course you can just do ARP. And there we see our one internal client 192.168.14. So we can do a quick scan on that one. All right, so you guys port 80 open. So now you can just do a get request to port 80. Yeah, and you get whatever page is running on there. So you now have full access to the LAN and all those cool LAN attacks that everyone's like, oh, that doesn't affect me because I have WPA2. Yeah, you can do those, it's fun. All right, but another important note is we're not really necessarily restricted to the main web interface. We can go after SOAP protocols too. So universal plugin play, which how many people here have it enabled for their Xbox or their VoIP? Yeah, it doesn't require any authentication and lets me punch holes through your router all day long to internal clients. And we can interact with that using this attack. So even if you have a strong password on your web interface, you're still not necessarily secure. HNAP is another SOAP protocol you'll find on some routers. It's the home network administration protocol. I've only ever seen it on Linksys and D-Link routers. It's kind of a Cisco thing. But you can interface with that as well. It does require a login, but some implementations have been found to allow you to basically reconfigure the router without a login. So it's just another avenue of attack. We can also rebind, like I said, to any public IP. I mean, I'm obviously targeting routers because it's super fun. But we can rebind to anything. I can basically turn your browser into an on-demand botnet for me and proxy all of my web attacks through you. So guess whose IP address shows up in the server logs that I'm attacking? Not mine. So how do we protect ourselves? This way will work, but you're not gonna have much fun on the internet. So first of all, you have to identify if you are vulnerable. Basically, if you can punch in the public IP of your router and you get the router login or the web interface, this attack will work. Because like I said, PFSense is the only router I know of that does any kind of validation of their HTTP host headers or anything like that. So okay, let's say that you are vulnerable. This works. There are some very simple steps you can take to stop it as an end user. Okay, first of all, we can basically break any of those three requirements we have for the router. And if any of those are broken, the attack doesn't work. And we can also reduce the impact of the attack just by basic security measures. So if you have sufficient access to your router, you may be able to change the services so that they only bind to the internal interface. So a lot of these services though that are running on these are very, very simple. So even if you get command line access and you can reconfigure that, there's no guarantee that it will even allow you to tell it to only rebind to a single interface. A lot of them just rebind to everything, all interfaces, and you can't control that. But if you can change that, that's a good way to stop the attack. You can also reconfigure your firewall rules. Basically, anything coming from your internal interface that's going to your public IP, drop it. Now you notice I went ahead and I used the slash 16 because as soon as your public IP changes, you'll have to update that rule. So go ahead and figure out the net block that your ISP uses to hand out as DHCP addresses and just put that whole net block in. And then you don't have to update the rule anymore. Disable HTTP and enable HTTPS. Now people here in this room, I hope that you know how to use SSH. If you can use SSH, please do. Again, a lot of consumer routers don't allow SSH, but that's fine. If you're enabling HTTPS, you have to disable HTTP. Just enabling HTTPS doesn't help you because that means I can still rebind to the HTTP interface. You have to make sure you also disable HTTP. Disable UPnP as well if you can. I know a lot of people rely on it so that might be difficult. Some routers don't let you disable HTTP. There's just a checkbox to enable HTTPS. Some routers also bind the HTTP interface to multiple ports. So this one, for example, it runs on port 80 and port 8080. So when you disable HTTP, you have to make sure it disables all of that. Again, HNAP, that's a whole other talk in and of itself. But some routers don't let you disable that at all. If you don't have sufficient access to your router to do this, you can basically do the same thing on your host, okay? Because I have to use the host to access the router. I'm proxying everything through your web browser. So basically do the same rule. Anything destined for your router's public IP, drop it. Or you can configure dummy routes. Anything going to your public IP, route it to your loopback address. The downside to this is you have to do it for every single device on your network and every single device that will ever connect to your network in the future. That includes your friend's iPad when he comes over. Basic security precautions. I change your default passwords, please. Just do it. It's a good idea. Keep your firmware up to date. Again, a lot of these routers have a lot of vulnerabilities in them. And if you're lucky, your vendor will actually patch them. So make sure you keep that up to date. And don't trust untrusted content. And yes, the internet is untrusted. You can, this is kind of a good suggestion. It's not really practical for most people. You can't tell them disable a JavaScript or use no script. It's just too much of a hassle for them. But it's definitely something to be aware of. So for vendors, okay. The problem is with the same origin policy in the browsers. I know I've seen people say, ah, you can fix this in DNS. No, you can't fix this in DNS. It's not a DNS problem. And it's not really fair to blame DNS for this. Because the problem is that the same origin policy chose an insecure protocol that was DNS, which was never designed for security and designed to base a security model on it. So it really needs to be fixed in the browsers. Implement the strong end system model on your routers, if you're a vendor. Also build DNS rebinding mitigations into the routers. That means checking your HTTP host setters, which is typically not terribly difficult. So wrapping up, yes, DNS rebinding does affect you. Yes, there are tools out there to attack your router, your internal resources with DNS rebinding. And ultimately, you are responsible for your network. You can't rely on vendors to fix this because they'll either do it wrong or they won't do it at all. So make sure you go ahead and take mitigations yourself to fix your stuff. So with that said, the code for this should be on the DEF CON CDs. I'm also gonna keep it updated on rebind.googlecode.com. Again, death threats, send them to my Gmail account, not to my work. And with that said, do we have time for Q and A? Are we out? Okay, I'll be in room 113 if anyone has any questions. Also feel free to grab me if you seem to walk around or send me an email.