 Hi, and welcome to my talk on malicious proxies. So let me tell you a little bit about myself. My name is Ed Zeborowski, and I've been in security for about 12 years. Through those 12 years, I've moved back and forth through the various disciplines of malicious logic, incident response, intrusion detection, and pentesting. During this moving back and forth, I've found that I really enjoy the pentesting the most because it gives me the ability to tackle problems and evolving challenges that I normally wouldn't encounter. So one thing I want to get away out of the way talking about proxies. When I use the term proxy, I'm focusing only on web proxies. And there's also plenty of reasons why you'd want to deploy proxy legitimately, but who really cares? I'm not here to spouse on the benefits of a proxy. So why would I come up with malicious proxy anyways? I wanted to come up with as many ways as I could to screw with a user's web browsing session anytime I could. And also as a pen tester, it gave me the ability to gather information that I might not have accessibility to. So a quick simplistic rundown of how proxies work. You have the client that requests a page through a proxy, and that proxy then requests it from the server. The server passes that page back to the proxy and from the proxy to the client, rendering the page. A malicious proxy isn't much different because it still sends the request through the proxy to the server and back to the proxy. The only difference here is the proxy now has a chance to modify this data. And here's a screenshot of an excerpt of slash dot before and after it modifies it. Now what you see here is on the bottom screen are a couple elements being added onto the page there inserting some JavaScript. That JavaScript or page as it's been modified by the proxy is then passed right back onto the client where it's now rendered with the modifications you made to it. So as I mentioned, a malicious proxy isn't much different from a standard proxy, but it can modify and change the HTTP responses and requests, and it can also add and remove data. So there are a couple ways you would want to go about modifying the content. One way is via modifying the static HTML. Now it takes a lot of customization on a per page basis and it's just really kind of difficult to do for every single page that you would possibly want to modify. Another way to do it is via injecting JavaScript directly into the page. And that's a lot easier because we only need to find one thing that all pages should have in common like a head tag and add that JavaScript to that element. This way it allows the client to render the page for us and do it in a consistent way, modifying the DOM. So there are some potential issues you might encounter when deploying malicious proxy. One is that insert JavaScript may be blocked by extensions like NoScript. There are ways around this though because if you can inject JavaScript as it's traveling through the proxy you can just directly inject the JavaScript making it look like it's from whatever trusted site that the user is going to. Also I've encountered that some Ajax heavy sites don't play very well, especially in the area of forms. If a site sends the form request off in an Ajax request it might not get picked up, but if it's sent via a form post to a separate handler it will get picked up. Another issue is compressed pages because everything uses the HTTP 1.1 standard these days. Excuse me. Because everything uses the HTTP 1.1 standard these days pages will come by in a binary format making it hard for us to make our changes. So we have a couple options there. We can either decompress and modify the page when it comes to the proxy or we can just strip out the header request as it's going out from the client. Also modifying the page itself slows down delivery so if you're doing this on a large scale you might run into more issues and that's another reason why to use JavaScript to let it do the lifting and the clients do the processing for you. So backing up now, how would you go about assigning a proxy? Well, an append test statically is not really the best way to do it and it's kind of like cheating. You can also do it via dynamically via DNS or DHCP. DNS has this functionality called the WPAD record and what that does is any browser set up to use auto proxy detection will look for a domain name with a WPAD host appended to it or prepended to it. If it finds it, it'll look for a file on a web host at that URL and that file contains the proxy configuration file of where it should proxy through. The same thing with the DHCP option 252. The only difference is you get more flexible about the URL and again that only works for browsers using auto proxy detection. And of course there are the other ways you can do it via like ARP spoofing as well. So I'm going to start talking about Topple Ganger, the tool I wrote to do this kind of stuff. When I started writing it, I wrote it as a kind of personal exercise learning Ruby. So the code isn't pretty and the documentation is sparse but that's a work in progress. I also wrote it as a proof of concept so some things might not always work but if you find yourself wanting to download it and you do and you find something wrong with it, feel free to let me know about it. I won't mind you make improvements. Now for the tool itself, I wanted it to be able to set down on the network and just go immediately. I didn't want to have to configure it a whole lot and I wanted it to target all sites out of the box. So Topple Ganger itself can create that WPAD record for us and I found that if you can manage to get on a network, usually the networks trust internal DNS updates so therefore you can become the proxy for the internal networks. And if any of you are familiar with GreaseMonkey, this is kind of like GreaseMonkey for entire network. Additionally, you can use Google APIs for part of the JavaScript so that way you don't need to have the clients pinging your local machine to get them. You can go to an already trusted site and let them download them from there. So Doppelganger, as I mentioned, uses Ruby. And the core and heart and soul of Doppelganger is Webbrick. It uses that as the HTTP server, serving up any files like the WPAD file or any other images that might be sent to the client. It also uses RubyGems, DNS Ruby for updating the DNS packer for packing JavaScript and injecting it directly into the page. And the bottom two, Windows PR and Win32 Process for Windows Interoperability, but I haven't had any success with it binding to a port on Windows yet, so I won't count on that working. So as I mentioned, Doppelganger generically works as a malicious proxy and can operate on both the headers and the content of the page. Specifically, it has these abilities and these can be customized or added to or whatnot, but this is out of the boxes. I've written it. And you only need to create a JavaScript file containing the directives you want it to do. So I can insert a calling card, and calling card is a pretty obvious attack. Not always useful for a pen test, but it has its uses at times. Also injecting flash applets. I can also scrape and decode the basic authentication of any user authenticating to a site because that basic auth is only base 64 encoded. I can use it to steal form data and other header data such as cookies. So inserting a calling card simply just removes all the children tag and the body tag and it adds new image to display on the page prominently. Header capturing works just as it sounds. As the header is coming in or out, you can grab it. Like I said, this works for HTTP basic authentication and it can decode it for us on the fly so that way we don't need to bother putting it through our base 64 decoder. And we can also grab cookies to steal other people's sessions. For injecting flash, we can just append that onto the end of the body of the page. And this allows us to gather more information about hosts and potentially even exploit flash vulnerabilities. In capturing form data, the way this works is it binds to the submit event on all forms. And when the user clicks on the submit button, it serializes that data, sends it back to the proxy to a non-existent URL where it's then logged by Doppelganger. And this is pretty useful too, especially for those pages that are HTTP only, but then post the data to the form, excuse me, to a secure page. So an example of what you might see is here a tragic event happening on June 23, the separation of a couple, because that never happens. But if you were running Doppelganger and you had to call in card functionality, they might see something more like this. Stealing form data, here's an excerpt from the slash.login box. And I have my username and my password in there. And at the bottom in the red is the form data that's serialized and posted back to Doppelganger that contains all the information that the user put into that form. So Doppelganger has some other uses, potentially. You could use it in phishing attacks. You could also use in C-Surf attacks or exploiting other things like Dolby Flash or the O-Day Firefox vulnerabilities that just recently came out. And where I'd like to take it in the future is add more addition or more control over what pages that you could manipulate. Right now, as I mentioned, it just kind of gets everything out of the box. You might want to be able to filter out some of those pages and only get the ones that might be of interest to you. Also, a little more interactivity because there's chances are you might want to add more JavaScript to it via Google APIs, in which case you had to stop Doppelganger, start it back up and run it. And during that time, you might miss something or if somebody's looking at you as a proxy and you're not running, you could effectively denial service the network. And additionally, I'd also like to add some functionality for the SSL strip and SSL sniff that Moxie's been working on. That's some pretty good work right there. So now some curious findings about when I was creating this tool. One of the things I found out when I started with the WPAD was that when I first updated that DNS record, I had about 320 hosts pinging my laptop as their proxy in about an hour's worth of time. But in our environment, we don't use... Our environment uses a GPO to push out proxy as well as baseline image, so we were getting about 320 hosts that were looking at my laptop to be their proxy. Also additionally, not on the slides, is I found that big surprise, i.e. it was the biggest offender of using the WPAD, the auto proxy detection. But there were still some other browsers in there that were using it as well, such as Firefox and Opera, which was a little bit of a surprise to me. So there are some things you can do about the WPAD attack. One of the things is you can serve out the DHCP option 252 yourself or the DNS option. Although browsers look at the DHCP option first, so that would be the better way to go. Also, you could ensure that the browsers aren't set to use auto proxy detection. And as I mentioned, this only protects against the WPAD and not the ARP spoofing type of attacks. So below is the URL for the code, and it's hosted at Google. And it has the fine seal of works on my machine approval. So you might get a... Your mileage may vary, but again, let me know and I'll always look to fix in it. So that's it, thanks. I have time for questions if anyone has any questions. Yes? No, I'm not just decrypting SSL. I had actually added functionality originally to create self-sign certificates on the fly, and I had that partially working, but then I figured I'd just back off of that and use Moxie's SSL SNF and SSL stripping, which I intend on putting in there to do that kind of functionality. Okay, well, thank you.