 Okay, it's a quick disclaimer. For those of you who saw Dan Kaminski's presentation yesterday or at Black Hat, you'll notice that there's some overlap between mine and the first half of his presentation. I'll be doing some more live demonstrations though, and we'll also go into more details about the attack technique. So while I was preparing my presentation, I was thinking about how firewalls have become so common that they've really entered pop culture. I've never seen a movie where the hero is rushing off to update IDF signatures or to install the latest Microsoft patch. We hear firewalls mentioned all the time. There's even that movie last year named Firewall. And the movies never get the details right, of course, but the point is that firewalls have become synonymous with security for many people, ranging from senior citizens checking their email at home to realistically most IT professionals, and even some security professionals seem to be under the impression that firewalls are some kind of magical black box, drop them at a perimeter, and suddenly their private network is protected from the rest of the world. Now, I'm pretty sure that most people here have already come to the realization that it's not, but what I'm going to demonstrate today is how anti-DNS pinning attacks can be used to completely bypass perimeter firewalls using technology that's so ubiquitous that only the most paranoid of organizations are completely immune. Now to set some terminology real quick, you sometimes hear anti-DNS pinning referred to as DNS rebinding attacks or even more rarely as quick swap DNS attacks. A quick Google search shows that anti-DNS pinning is the most common term, but strictly speaking DNS rebinding refers to a broader category of attack and anti-DNS pinning is a specialized form of that. I'll be touching on some other forms of DNS rebinding, but the bulk of my presentation and the demonstrations will be on actual anti-DNS pinning. Now out of curiosity by show of hands, how many of you have heard of anti-DNS pinning or DNS rebinding before you saw the black cat schedule? Okay, yeah, not that many. How many of you have heard of and know how to launch a cross-site scripting attack? Okay, good. I'm going to be referring to some more common forms of JavaScript and web-based malware, things like cross-site scripting, port scanning using JavaScript. There's a lot of different techniques that have been well documented and much more than DNS rebinding. I'm not going to talk about these, but if web security is part of your responsibilities or part of your interest if you're more on the supply side, then you definitely should be familiar with these techniques. There are four things that I will be covering in the presentation. First, I'll talk about what simple DNS rebinding attacks are and why DNS pinning was the proper solution for them. I'll show how anti-DNS pinning attacks can be used to turn a web browser into an HTTP proxy using nothing but JavaScript. Even better, I'll show how a web browser can be turned into a SOX proxy using nothing but Java applets. And then finally, I'll touch on some other DNS rebinding attacks that are related. I'm not going to get too much into fundamentals, but I do want to talk about the same origin policy because it is so critical to most of the web browser security model. The same origin policy was introduced by Netscape, along with Navigator 2 when they debuted JavaScript. And essentially, the policy says that a script from origin A cannot read or manipulate data from origin B. The origin is defined as the protocol or scheme, so usually HTTP versus HTTPS, the host name and the port number. If any one of those three change, then it becomes a different origin and the script can't manipulate that data. The IP address is not part of the same origin policy. Originally, that was because of virtual hosting and load balancing issues, but that is critical to the attacks I'll be demonstrating since IP address is actually how servers and hosts on the internet communicate. The same origin policy was a good idea when Netscape first introduced and it's definitely prevented a lot of attacks over the years, but as you'll see the rest of my presentation, it's also very flawed and very broken today. Probably the best known example of that is cross-site scripting, which essentially gets around the policy by injecting references to JavaScript into the targeted host. Now without a properly secured website, it's not going to be vulnerable to cross-site scripting with the exception of a handful of rare client-side vulnerabilities, but if an attacker is able to control the DNS server for an internet domain, a new type of attack to bypass the same origin policy becomes possible, that's simple DNS rebinding. Now as I alluded to earlier, simple DNS rebinding is kind of the grandfather of anti-DNS pinning attacks, so you'll see a lot of similarities between this slide and some future ones. The DNS rebinding goes something like this, a web browser is convinced to visit a malicious site probably through cross-site scripting, so the first thing it does is send a DNS query for that host name. The attacker controls DNS, so he responds with the IP address of his attack web server. The browser sends a request there and some kind of attack payload is returned. Now at this point we're still looking at it from a high level, so this payload can be written in anything. The browser becomes infected, pauses long enough for the TTL or lifetime of that DNS record to expire, and then initiates a new request back to the same host name. Because the IP address is timed out and is no longer in the DNS cache of the browser, the browser sends a new query back to the same DNS server. But this time the attacker responds with the IP address of the victim server, which is usually on the same private network as the browser. The browser lets the payload connect to that server, some kind of attack is launched, presumably useful data is returned, and then forward back to the attacker. So the entire time the protocol didn't change, the host name didn't change, and the port number didn't change, which means that none of this violates the same origin policy. DNS pinning was introduced to prevent this type of attack. Essentially it causes a browser to walk the first IP address it sees for a host name into its cache to pin it there. In theory, all subsequent requests to the same host name should use that IP address, and no further queries of DNS during that pinning period should be possible. The first attack against DNS pinning was documented in 1996 by some researchers at Princeton. It was against the JBM, not against web browser, so I'll go into detail about it more later. Interestingly though, DNS pinning is really a violation of the standard. RSC 2616 clearly states that any HTTP client that is going to cache DNS responses must respect the TTL. Now if this was actually implemented, then it would cause simple DNS rebinding attacks to be trivial against browsers. Ironically, the reason that the authors put this rule on the standard was for security. They were concerned that if a client cached an IP address for too long, that it would, during that caching period, the IP address might be reassigned to a different party. And if the client decided to send more data to that IP address, then the data would be subject to abuse by the new owners. Realistically, IP addresses don't change ownership that often these days. And using this rule puts too much faith in the response that's provided by the DNS server, which shouldn't be done. There's no reason to trust just some random DNS server on the internet. The first attack against web browser pinning was documented in 2003 by Josh Sorra, the developer on the Mozilla project. And it was pretty much ignored. The security community didn't look at it much. It didn't get much reference that I could find at least until last summer when a client made a reference to it and opposed on the web app sec mailing list. The attack was something like this. Tricked browser into going to a malicious site. Browser downloads a payload. And the attacker either waits for the user to close the browser or causes the browser to crash, which I think most of us know is usually trivial. Now this point is pretty easy, fairly straightforward. The hard part is that the attacker has to get the browser to somehow reload that payload from its local disk cache, the content cache. It's a pretty tricky thing to do. Josh had suggested using a compromised advertising service, which is a good idea, but it's still as far from simple. If the attacker manages to do this, then the payload when it's reloaded will cause the browser to send a new request to the same host. But this time the attacker will, of course, have the DNS server respond with the victim IP address. And then the rest of the attack is very similar to the simple DNS rebinding. Now on the one hand, this attack is fairly difficult to defeat with conventional browser design because you have to drop the DNS cache at some point and the browser closing is a logical time to do that. But on the other hand, it's easy to defeat by having the browser clear its content cache on exit, something that a lot of users already do automatically. It's also very difficult to launch because of the payload reloading problem. And even if the attacker manages to accomplish all of this, it is still very, very slow because every time the attacker wants to contact a new server, he has to repeat the process of loading the payload, crashing the browser, reloading the payload, which is pretty time consuming. But there are more effective techniques that are possible. Shortly after Amit Klein posted that comment on the web app sec last year, Martin Johns documented that modern browsers, namely IE and Firefox, but pretty much all of them, don't fully implement DNS pinning. It turns out that if the browser detects that a web server is unavailable, it will dump the cache and re-query DNS. Now the intent was to allow browsers to more gracefully recover from web server outages. But the result is that an attacker can coordinate a firewall rule change simulating a web server outage with a DNS change pointing it at a victim server to launch a successful attack. It looks something like this, and again this is very similar to simple DNS rebounding. The victim browser goes to a malicious site, pins the response this time in its cache, gets the attack payload. This time the firewall rule is set up, and the payload when it runs will try to reconnect to the original server. The request will time out because of the firewall rule, which causes the browser to dump its cache and re-query DNS. Of course this time it gets the IP address of the victim server back and proceeds with the attack the same way. In my demonstration of this attack, there's a few different components that deserve more explanation. As I mentioned, the victim browser is just a simple browser using JavaScript only, no plugins are required. I'll be using Firefox. The victim web server is usually on a private network, the same one that the victim browser is on. The attack server is where most of the cool stuff happens. There's two IP addresses. There's a back in mySQL server for communication between the different components on the attack server. Then on the primary IP address, there's a number of supporting functions. The authoritative DNS server for the attacker's domain is there. There's an HTTP proxy that accepts requests from the attacker's browser and forwards them to the payload running on the victim browser. There is finally a multi-function CGI script that does a number of functions. It will present an attack console to the attacker web-based console for issuing new commands. It accepts holes for new commands or new requests from the victim browser and also accepts response data from the victim browser. On the secondary IP address, the CGI script will actually serve up the payload that's being used to perform the client-side logic for the anti-DNS pinning attack. Now, it's important that there be a secondary IP address while the secondary IP address is far-walled off to simulate a web server outage. The primary IP address still needs to be available for command and control functions. These components communicate using a number of fairly well-established techniques for JavaScript malware. Now, some of these might seem a little convoluted on the surface, but keep in mind that all of the communication has to be initiated by the victim browser. It's not accepting any inbound connections. So, for requesting new commands from the control server, the attack server, it's implementing it using script requests, and I'll get into that in a bit. To send data, it uses either image requests or HTML forms, and the victim browser requests data from the victim server using XML HTTP requests. Remember that the same origin policy states that a script from origin A should not be able to access, should not be able to read or manipulate data on origin B. A glaring exception to this are other JavaScript files, and that's how the payload communicates with the attack server. Essentially, the payload will append a new script tag onto the document periodically, and the source of that tag is set to the controller script on the attack server. The attack server responds with the data in JavaScript with a predictably named variable, which is the case, just an element of an array. Now, theoretically, I can imagine some cross-site scripting filters detecting this because it is really cross-site scripting. I want to emphasize, though, that cross-site scripting is not required for any of the parts of my demonstration. It's the most elegant solution for some things, especially this. But there are other techniques available for tunneling data off-domain, essentially out-of-band communications. Two that I've experimented with are tunneling data over the image and width of the image request, and also using parameters within that can be inferred from a cross-site, excuse me, cascading style sheet. I don't really have time to go into these in detail, but the white paper associated with my presentation does. To send data from the victim browser to the attack server, there's two methods that can be used. The first one, if it's a small amount of data, an image object is created by the JavaScript payload. The source of the image is set to the controller script on the attack server, and once it's appended to the document, the browser will automatically process the request and send it to the attack server. The controller script on the attack server doesn't even need to respond with a valid image. The data is actually appended into the URL of the query of the URL string. It's a larger amount of data that can't fit into a URL, or if it's binary data that you don't want to encode for some reason, but an HTML form is used. The data is put into a text input box. The action of the form is set to the controller script on the attack server. The target is set to an iframe that's unused so that the web page won't redirect to the action destination, and of course it's submitted with post. Finally, the XML HTTP request, like I said, is used to request data by the victim browser from the victim web server. XML HTTP request is an object in the HTML document object model. It's probably best known for being the core functionality of AJAX sites like Google Maps or Yahoo Mail. Normally, it can only return text data, as the name implies it was designed for exchanging XML sheets. Fortunately, Marcus Granado documented how binary data can be retrieved by setting the character set to X user defined. I have no idea how he figured this out. It's a rather esoteric application of Unicode, but it works, and without it, you wouldn't be able to request binary files like images or PDFs, things like that. Remember, well I should say that one important thing to remember about XML HTTP request is that it can only communicate back with the origin server, because otherwise it would be a blatant violation of the same origin policy. Once the IP address has been switched in the MTDMS pinning attack, the victim server is considered origin, and the XML HTTP request can't be used to communicate back to the attack server at that point, and that's why those previous methods were required for out of bank communication. This is a representation of the demonstration environment. It's a fairly realistic scenario for most corporate networks. The internal network is using private IP space separated from the internet by firewall. The firewall allows no inbound connections from the internet. The only outbound connections are allowed for 80 and 443 for web traffic, and DNS is allowed out from the internal resolving DNS server. Of course, a lot of corporate environments use proxy servers, which doesn't necessarily break DNS pinning attacks, and in some cases can even make them more powerful. That's not going to be in this demonstration, though. There are three devices on the corporate network. There's a Linux server that's running a simple web application with the MySQL back end. There's a Windows server that has file sharing enabled and also acts as the internal resolving DNS. And then finally, there's the victim browser, victim workstation, which is running Windows XP, fully patched version to Firefox, at least as of a few weeks ago, and the user is running with non-administrative rights. I'm saying that just to reinforce this is not using any patchable vulnerabilities in software. It's not using privilege escalation as standard JavaScript browser functionality. On the internet side, there's a fictional website that has already been compromised by the attacker. Some cross-site scripting has been injected. These are a dime a dozen. Google, Yahoo! They've all had problems with cross-site scripting. The attack server we've already talked about and, of course, is the attacker's workstation. From a physical point of view, the environment is implemented on two laptops, both running multiple virtual machines connected by a firewall running DDWRT. Thank you to my colleague, Eric Dupre, for assisting in getting the firewall and several of the virtual machines set up. Now, I've already gone over into DNS pinning from a high, maybe even a medium level, but it's for at least a web-based attack. It's fairly complicated, so I'm going to go over it again in more detail, step by step. Of course, it starts off with the victim browser visiting a malicious website and loading some small piece of JavaScript malware as a result. The malicious JavaScript is pretty simple. The only thing it does is redirect the browser to a malicious web page on the attacker's web server. But on a real attack, this would probably be in maybe a pop-under window in an invisible iframe. There's a number of ways of hiding the fact that malicious JavaScript is running from the user. I'm not going to talk about any of these. In my presentation, the window will be large so that debug statements can help narrate the attack, but properly done, the user would be very unlikely to notice anything amiss. The base attack page is also pretty simple. Every second and a half, it depends a new script tag using the technologies we discussed earlier and asks the attack server for new commands. Every time it pulls, the first time, rather, it pulls, the controller script will insert a record of the session into the database so that the attacker can see it on the attack console. Every time it pulls, it asks the controller script will go out to the database and look to see if there are any new commands for it. If there are, it will return it in JavaScript format to the victim browser. At this point, the attacker can start executing arbitrary JavaScript on the victim browser to probe the network, perform reconnaissance. We're going to skip this step. We're going to assume the attacker has already performed recon and has identified a web server, in this case, the Linux box that he wants to interact with. The attacker starts up the HTTP proxy server and running on the attack server. The first time that he sends a request to the proxy server, it checks to see if it's seen any other request for that specific IP address. If it hasn't, it knows that it needs to set the base for a new anti-DNS pinning attack. The first thing it does is create a random host name and a corresponding A record on the attack domain's DNS server. Initially that record points at the secondary IP address on the attack web server. It also creates a command for the victim browser to create a new iframe and the iframe source points at this random host name and the controller script asking for a new iframe attack payload, basically the client side piece of the DNS switch. Once the iframe payload completes loading from the attack server, then it will immediately send back a message to the attack server saying, I'm done. The payloads loaded, we're ready to proceed with the DNS switch. The attack server creates a firewall rule, blocking access from the victim browser to the attack server on the secondary IP address, and then also switches that DNS record to point at the victim IP address that was provided by the attacker's proxy request. At the same time, the iframe payload retrieves the next URL that's going to be processed, the first one that was sent by the attacker, and creates an XML HTTP request object for it. The browser will start to process it, and will try to connect to the IP address that it's pinned in its cache, but it's going to fail due to the firewall rule. Eventually the browser will dump its DNS cache because it timed out and re-query DNS. Once this happens, the attack server, of course, will reply with the IP address of the victim server. Excuse me. Now, as soon as the payload sees that the new IP address has come down, sends a message back to the control server saying, okay, we're done. The victim browser has pinned the victim server's IP address in its cache. We're ready to start processing requests. You can get rid of that firewall rule. And right after that, the browser will process the XML HTTP request object, sending it this time to, of course, the victim server, which will respond with some kind of content and forward it back to the attack server. This whole time, the proxy server has been polling the database, looking for a response to that initial request that was sent by the attacker. As soon as it sees this response, it grabs it, sends it back to the attacker's browser, and, of course, it's rendered. So, I'm sure that's all clear as mud, and let's get started with the demonstration. There we go. Okay. Okay, this is the attacker's workstation, the console. There's nothing running on it right now since there's no session that's active. This is the victim's workstation starting up a new instance of Firefox. And we'll start off with the victim just going to some fictitious website. It's already been processed, attacked by the attacker with some cross-site scripting. The user clicks on a link, and is redirected to an attacker page. Now, of course, normally, none of this would be visible to the victim. If we switch back to the attacker's browser, we can refresh and see that the session has appeared in the console. We can run some arbitrary JavaScript. If we switch back, pops up, clear that. That normally would be the point that the attacker starts performing recon. We're going to just start up the HTTP proxy and confirm that the web browser is configured to use it, and it is. This is the primary IP address of the attack server. Okay, so if we switch back to the victim's side, we can see that a new iFrame has popped up. This time, it is well, it's going to a random hostname. I forgot to start up the packet earlier. Now, at this point, the DNS change has already been made. The firewall has already been created. So, if we start the packet capture, we should see that it's starting to time out. Now, I wanted to show you some other packets, and I forgot to start this earlier. We're going to have a minute to wait now. You can see that Firefox is essentially hung at this point. There's a few reasons for that. One of them is that the payload is fairly aggressive in trying to cause the browser to recognize that the web server is down. If the browser is less aggressive, it doesn't cause, or if the payload is less aggressive, it won't cause Firefox to hang. So, you can hide that. There's also some other techniques. If both addresses were on the internet, then you can actually flip it in just under a second. There was a white paper that was released by the Security Lab at Stanford that referenced some techniques on that, but they don't work at least from what I can tell. They don't work if you're using a private IP address as the victim. Okay. So, you can see that the victim browser switched over. This is the iframe that's being posted back in. Here's the HTML form. If we go back to the attack server, you can see a browser. You can see that a fairly primitive web application has been displayed. At this point, the attacker can start interacting. Well, let's see. We can just run a simple query, first of all, and get data back. The attacker can start looking for common vulnerabilities like cross-site scripting, which it's vulnerable to, and you can look for a SQL connection, give them a quality of the web page. I'm pretty sure QuickTotology will find one, and it does. And if we go back to the victim side, you can actually see the requests as they came through as they were being proxied. So, at this point, the attacker would be able to continue browsing this website or perhaps look for something more interesting. Now, those of you that were paying close attention may have noticed that I failed to mention earlier, intentionally so. Remember that the XMLHttpRequest object can only communicate with the origin server. And the origin server has to be on an attacker-controlled domain in order to perform that DNS switch, which means that when XMLHttpRequest reaches out to the victim server, it's going to be using a hostname and a domain name that that web server has never seen before. On most web servers, that means that the only the default website will respond with good data. That's led some people to suggest that validating host headers might be a valid defense against anti-DMS pinning. It's not. Host headers are not security. There's several reasons for this. One of them is that the, there's been a number of vulnerabilities in the past, both Internet Explorer and with Firefox, that allow an attacker to arbitrarily set the host headers and override it. There's no reason to believe that all browsers out there have this vulnerability fixed and there's no reason to believe that similar vulnerabilities won't be found in the future. In fact, there is a vulnerability like that with Flash. But going beyond that, there are plenty of default websites that are out there. There's tons of them on the Internet, and there's probably even more in private networks. A major web application is almost always going to have a dedicated server, which means it's usually going to be the default website as well. Even if the attacker doesn't find a default website that's of interest, he still has some recourse, though. Attacks can be launched against the web server itself instead of the website. Something that's complicated, like a chunked encoding overflow, say, or a possible hit XML HTTP request, but something simpler, say, a buffer overflow in the URL or in a header that the JavaScript is allowed to manipulate could be launched. More likely, though, those aren't that common of attacks, so the attacker would probably look for some old, rarely used, long-forgotten web application that I'm sure most people have back at work. It's probably written by junior developers, probably riddled with SQL injection flaws, and if the attacker's lucky, then the database on the back end might have a tertiary flaw, say, XP command shell, which could allow a more traditional and more flexible tunneling method to be set up. However, if the victim browser has Java installed, then some more powerful attacks become possible. To do a bit of a Java security refresher, there's two types of Java applets. There's trusted and untrusted. A trusted applet is either digitally signed, much like ActiveX controls are, or is installed locally. A trusted applet has pretty much the same level of permissions that a user does. Can interact with the file system, read, write, fully create, whatever the user can do. Can create and terminate processes, and has full socket access, either outbound to other hosts, even acting as a listening socket. On the other hand, victim, excuse me, untrusted applets have very few rights. They cannot interact with local file system. They have no process management capability, and the only socket connections they can establish are outbound to the origin host, but they can connect to any port on the origin. As I mentioned before, the first anti-DNS pending attack was documented in 96 by Princeton researchers against the JVM. The Princeton attack was, what they noticed was that if the DNS server responded with two IP addresses for the origin name, the Java would consider either of those IP addresses to be an acceptable destination for untrusted applets to create socket connections to. Sun addressed the problem pretty quickly, and said that in the future, applets would only be able to connect to the IP address that they were actually using. I don't have an 11-year-old version of Java to see whether or not they actually implemented that, but as you'll see in a little bit, that is not the behavior that the JVM exhibits today. The Princeton attack looks something like this. Again, it's very similar to a simple DNS rebinding attack. The victim browser goes somewhere to a malicious site. This time the browser could be performing perfect pinning with that IP address. The attack server comes back with some kind of HTML referencing an applet which causes the browser to fire up the JVM. The first thing the JVM does is issue its own DNS query, and this time it gets two addresses back. It's going to take that first IP address and request the applet from it, which it gets, and as soon as the applet's loaded, it establishes a socket connection to that second IP address. Because both IP addresses were pinning caches coming from the for the origin server, Java allows the connection to establish, and of course the attack proceeds much as with previous examples. That attack doesn't work anymore. There are some variants on it to do that we'll talk about in a minute, but there's another attack that's viable with LiveConnect. LiveConnect is a technology that was introduced by Netscape. Essentially it's a two-way bridge between Java and JavaScript. It allows Java applets to interact with the DOM so they can create new elements on a page, they can modify attributes, things like that, but more importantly, it allows JavaScript to instantiate standard classes that are part of the Java distribution, including socket classes. It's supported by Firefox and Opera, maybe a few other browsers, but not by Internet Explorer, so the next administration we're performing will not work with IE, but some future or some other vulnerabilities I'll be discussing do work in a similar fashion. Earlier this year, Martin Johns and Kanatoko, I was told that Kanatoko actually means anvil in Japanese, so that's a typo, but it just got documented that if JavaScript was creating socket objects, that as soon as one was created the JVM would start up and issue a DMS query for the hosting that was supplied. Now since there's no applet to download, this query was being used only for pinning purposes, which means that essentially the JVM will allow the socket object, the JavaScript, to connect back to whatever IP address it wants to, whatever is returned by the attacker. That has a lot of advantages over the previous attack. For one, there's no delay caused with the firewall and the cache timeouts that we saw earlier. The host header restriction is limited, or lifted rather, because there are, you know, you can create your own sockets and your own arbitrary HTTP request, but going well beyond that pretty much any application protocol text or binary, UDP or TCP even limited ICMP support is possible. This has huge potential, obviously. SSH, Telnet, SNMP, NIS, CIFS, database protocols, pretty much the vast majority of data that travels over a network can be tunneled through Firefox using this technique. So my demonstration of this attack is a very similar environment to the first demonstration. A few exceptions. Instead of an HTTP proxy, I'll be using a SOX proxy. For those of you who aren't familiar with it, SOX is a protocol that lets UDP or TCP be tunneled through a proxy server. Like I mentioned, there's no need for a firewall. On the attacker's workstation, there's a generic SOX client that is loaded from a Hummingbird client. It's bound to the IP stack and any request going out to the 10.address range will be redirected to, invisibly, to the proxy server, which means that pretty much any application can be tunneled over this. And finally, the reads and writes are handled asynchronously using the kind of pseudo-threading that JavaScript gives you with set time out. That gives you a little bit of performance boost. So let's do this prep. Let me just reset the environment real quick from the first demonstration. I'm not going to be doing the fakenews.com thing again. I think that the point was made the first time around. Okay. This is a victim browser. It's on the attack site. We can run some quick JavaScript to confirm that connectivity is in place, which it is. And we'll start the SOX proxy. The first thing that we're going to send through the SOX proxy is a simple Nessa scan. As you might guess, this is a fairly focused scan. It's not very interesting watching Nessus run under any circumstances. Okay. Just take a second for Nessus to initialize. All right. So if we go back to the victim side, you can see that traffic's coming in. If we go back to the attacker side, you can see that there's traffic that's coming through now. It's identifying as netbios, but if you actually look at the packet capture, I'm not doing anything fishy here. It starts off as SOX, performs the handshake. Wireshark is smart enough to identify the underlying protocol that's being tunneled by SOX. Even though it's being identified as netbiosession, it's still running over port 1080, which is the default port for SOX. Let's see here. Just a second. Let me go click and show you some more details about it. You can see the iframe that things are being posted to. Data is changing as it's being posted back to the attack server in this HTML form. These are the placeholders for the images that are requested from the attack server using that technique I mentioned earlier. Pretty close to being done here. As you can see, the administrators haven't done a very good job patching the server, which is pretty typical for an intranet site. A couple of vulnerabilities are identified with we're able to perform some reconnaissance. You can see that it's running Windows 2003. At this point, we can start launching an attack. One of the nice things about from an attacker's point of view about this method is that once you're on the inside of a network, you don't really need that sophisticated of knowledge, because most internal networks are not secured nearly as well as the network. So we'll use pretty much the hacker equivalent of off-the-shelf software. Just launch a quick RPC attack with Metasploit. For this attack, the payload that I'll be using is a straight TCP shell. In the real attack, the hacker would probably be using a reverse shell so that the victim's server connects back over the internet server that's controlled by the attacker. The reason for me doing it this way is that it's a little bit faster. You should see the attack coming through pretty soon. It's a little bit faster because you don't have to set up something like Netcat listening, but in an extended scenario, it's slow because it has to be tunneled over the SOX proxy. While it's an effective attack tool still, it's not all that speedy. You can see the first thing that Metasploit does is it tries to connect in on port 4444, which is where the shell is going to be bound. It's checking just to see if anything's already listening there. It's not, so Java's throwing this exception, which is normal. We can see traffic coming in. If we switch back to the attack server, I'm assuming that's as blurry for everyone else as it is for me. We're about to get a DOS shell there, although I'm not sure how well people, especially in the back, will be able to make it out. Okay, so now we have a shell with system lower rights since it was from RPC. We can go to the attackers, or excuse me, to the administrator's desktop and we just switch over quick to the victim's side and we'll pull up the victim's server. Let me log in real quick here. Empty desktop. And we'll just put something on the desktop here. Switch back. There it is. So, system level, root level access from the internet to private network, all totaled over Firefox. Okay. So as I mentioned before, that doesn't work on AE, but I'm going to bet the vast majority of you are using Firefox as your primary web browser. You might not have Java enabled, but there's some other attacks that will work on the internet Explorer. I documented three last month. The first one isn't really a new attack per se. It turns out that the Princeton attack will still work if both the attack server, the victim browser and the victim server are all in the same subnet. Now, there's not all that many scenarios where that's useful, but it still is telling about how DNS binding does or doesn't work on the JVM. The second attack's a little bit more useful. It's also based on Princeton. If DNS returns two IP addresses, the JVM will perform a reverse DNS lookup on both of those addresses. If the pointer records associated with those return the same host name, then the JVM will consider those to be unacceptable, both of them to be an acceptable destination for our sockets. Normally, an attacker wouldn't be able to control the resolution of a privately numbered IP space, but there are a few scenarios where he might be able to. If the attacker has compromised the authoritative DNS server for that IP address range, or has compromised the resolving DNS server for the victim browser, or if some kind of DNS cache poisoning is possible, then this attack could work. I don't see it as being a major flaw in the JVM, though, because it relies pretty heavily on the secondary vulnerabilities that are completely outside of their control. The third attack is a lot more feasible, though, especially in a corporate environment. If the JVM is configured to use an HTTP proxy server, it will download the applet file, the JAR, the class, through the proxy server, but still perform a DNS lookup for pinning purposes. Now, much like with the live connect attack, if the JVM, rather, has no way of knowing whether those two IP addresses match, the attacker is able to coordinate it so that the IP address sent to the JVM is for the victim server, and the IP address sent to the proxy server is for the attack server, then an attack becomes possible. Of course, this relies on the internal hosts on a corporate network, or a private network, to be able to resolve internet host names while still using a proxy server, but that's fairly common. There's a lot of enterprises that have their systems deployed that way. Proxy servers, well, first, Java and JavaScript aren't the only vectors for this type of attack. Proxy servers have been suspected to be vulnerable for a while. Last month, David Stutter, D.K. Portswigger, released a paper on proxy server vulnerabilities, and documented that the two most popular proxy servers, Microsoft Internet Security Acceleration and SquidCash, are both vulnerable. Microsoft enforces a minimum TTL of six minutes, which isn't bad. That's better than, say, Firefox, but it still means that anti-DNS pinning is possible, although just a little bit more inconvenient. Squid, on the other hand, completely respects the TTL, which is an importance with the RFC, but means that a simple DNS rebinding attack is trivial. A lot of people don't know this, but Flash actually supports sockets, too. It's a little squirrely with some of the restrictions on there, but it's still definitely possible to launch a DNS rebinding attack through it, because it does not use any pinning as well. It respects the TTL. Konotoko had documented this earlier this year and has a proof of concept on his website. Martin Johns may have been involved with that, too, I'm not sure. This Stanford paper that I referenced earlier has some other information on that in there. It's a great paper, and I really wish that I'd had time to incorporate some more of their findings into it, but I highly recommend that you go and take a look at it. If I did a poor job, and you still don't understand what anti-DNS pinning is or DNS rebinding, take a look at this blog posting by Christian. It's very good. It's a step-by-step explanation of how DNS or rebinding attacks work. If you do understand it, definitely take a look at the Stanford paper. It's great. It goes into more detail about defense, which, since this is DEF CON, I didn't think that was important. I did go to that at Black Hat. DNS rebinding.net is the easiest way of getting there. That will redirect to their web page with the proof of concept as well. That's all I have. If there are any questions, I think we have a few more minutes for in here, and then we can move to another room. Thank you.