 All right. Well, good morning, everybody. Thanks for coming. Wow. Sunday morning on DEF CON. We're here. Yeah. That's all I have to say about that, I guess. So if I haven't met you yet, please stop by and say hi sometime or grab me in the hallway. I'm James Shoemaker. I do some instant handling and penetration testing stuff. The past year I've been doing a lot of research on some of the tactical-based stuff. It's been my emphasis. And this is kind of a result of some of that experimentation. Some of what we're covering today is, well, defense is hard in general. So some of the stuff we're covering today is a start on making, closing that gap, making up for some of the deficiencies we have in our browser-based environments. So that's what we're going to talk about today. So just to kind of wake us up, maybe get us all started on the same foot here. Browsers aren't good enough in the way they are right now. Generally speaking, why they have extensions to fill in those gaps, right? We've got flash players. We've got all these other rich content extensions in our browsers. And between the two, they're incomplete and quirky because of the incompleteness makes them even more quirkier, right? We have all these plug-in variety versions. Things get complicated. And it really gets even quirkier because all the web content we have is so customized, right? We have the HTML itself is all written maybe by hand, maybe by a broken editor. And then we have all the media on top of that that gets delivered. So today we're going to be focused on two types of those problems that manifest because of that. Some of the attacks, at least some of the attack components, we'll look at some techniques to do that. And then also, how can we regain some of that anonymity? We'll look at a few examples of some things that maybe are steps in the right direction to reanonymize ourselves after some of the work that's been done in the past year or so roughly. And then we'll introduce X06D, which is a pre-alpha version of a suite of browser-based defenses that we've been working on. But the goal of the project is to get as close to, well, maybe we'll be okay. There's that six-day window where we might have some issues. But within six days of knowing that there's an issue, we'll be reasonably safe. That's kind of the goal. We had to pick a goal, so that sounded like a good one, roughly a week. So overall, this stuff we'll be covering takes, let's say, four phases, right? To defend yourself against attacks, we want to sanitize the input to the browser. Say you actually were duped into clicking on something or browsing somewhere you shouldn't. Well, that input to the browser, the browser being half of the application, typically, is going to be a large portion of that attack surface, right? And you don't have much control of that from the server's aspect, right? You have no idea if it's a public site, who's coming, what they're going to come with, how nicely configured their browser is, what it's vulnerable to, and all those sorts of things. So to defend yourself in a browser on a public site, you might want to first identify what interesting code is showing up in the browser, because, well, there's so many different combinations and encodings and complicated things that need to be renormalized down to something you can detect. This is why we can't take the classic antivirus signature technique and lean on it as heavily as we have on the host level inside of the web applications, because there's so much custom things that we can't detect. Now, some of the things we can do, we've seen some progress, right? No script is a very cool tool, lets us do a lot of awesome granular control of what comes into that browser, you know, rejecting tags, rejecting certain scripts from certain sites, even whitelisting sites. But it is somewhat limited, right? Because it is still not available for every browser, of course, and it's more, well, because it's so granular, it is more tailored to those of us who care to go in and manually do all these settings, right? We can't just set it and forget it. Not that I ever think that's a great idea for security concerns, but it's still something that would be nice for all those sheep that want to come to our sites, right? Or the ones we have to protect to be able to give them something that will protect them without a whole lot of foot shooting, you know? Another portion is if we can anonymize the browser. Now, I want to separate out a couple of things, that's why we have anonymized and randomized separately here. Sometimes people confuse the two in our application here, but if we make the browser look more or less unidentifiable, at least indistinguishable from other browsers, then it's going to be less likely the point of the attack, right? There's not going to be a specific weakness in that specific version of the browser or the enhancement to the browser like the Flash Player is going to be less likely to be targeted. So being anonymous there would be great. Now, we could look like clones of each other and that would be sufficient, but maybe it would be more interesting to fake being somebody else, right? Using a browser fingerprint that somebody else had. You know, back in the earlier days of the internet where we had, I don't know about the whole internet, but when we had the web, right, and Netscape went public and we had a few browsers out there, if you can call them that, there was a, you know, an interesting thing as sites try to detect, you know, hey, do we need to put this in a way Internet Explorer can display it for you? Try to detect your user agent usually to display it in an Internet Explorer friendly way versus, you know, the Netscape way. Well, that was an earlier way to try and identify things. Of course, there's easy ways to spoof that. The user agent string being controlled by the client, real easy to just fake that and that's what they did to make our browser look like every other browser. There was the user agent forgers. One of the first reasons many people used opera was because of that feature. You know, they can make it look like Internet Explorer, so they got the Internet Explorer version of the site. Another great thing now is to make your web browser look like a mobile device because now you don't get the flash version of the site. You get the leaner version of the site, right? Because the iPhone won't support flash. So there's a lot of reasons to make yourself look like everybody else, but it's much harder than just changing the user agent string. But hopefully you see the benefit in that as well as just, it would be nice to not just look like everybody else, but to look like that iPhone to get that iPhone version of the site. Then when we come to randomizing stuff and applying this as a technique to defend ourselves, this is more of a strict privacy kind of concerns, right? Where we don't want to either reveal our behavior or we don't want to be singled out for anything in particular. There's a couple of ways that we can do that in general. We can groom our history so that it looks like everybody else. It's kind of similar to the anonymizing, but here it's more for the behavior. So we, in the background, go to those top 500 sites from Alexia in the background so that if someone's watching on the wire, they see normal traffic to Facebook and all these top 500 sites. A little harder to fingerprint that, oh, this IP address is very specific and unique because, wow, you've got to wade through all this other traffic that is typical. Creating that, raising that noise level, creating that line noise. And then, of course, the other thing to come full circle is to sanitize output to the server, right? So sanitizing input to the browser that we have at the top of this slide, what I mean by that is if you're duped into injecting into yourself, right, you're going to catch it there. Like a classic cross-site scripting attack or maybe you clicked on a phishing link and you're sending something into your own browser. Sanitizing output to the server, you know, maybe your browser is vulnerable as it displays things, as it renders the HTML is where the problem happens. So it's nice to be able to deal with both the input and output in that way. Now the ways we can defend against that is, of course, we might be able to do a signature detection, but again, that's complicated and hard because we have to renormalize the code, right? If it's a script tag that's modified, we have to detect it in an unmodified version. So we have to renormalize it. And the trick is really different browsers normalize it differently. And I'll take different priorities in recombining code. So the other way really than detecting it is to try and neuter what looks interesting by just translating it, just kind of munging it a little bit so that it is less likely to work precisely how the attack was constructed. Somehow converting it. All right. So to try and deal into it a little bit deeper, if we're sanitizing the browser, we've got no script, but it's hard, right? You still have to go in there and do that granular check. You've either got a whitelist, what you know you're going to trust, and then you might get caught with something dangerous there. What are some other options? Well, maybe we could actually vote on what is allowable or not, right? Have more of a peer-based evaluation of what is good content. In concept, that sounds pretty scary. I don't know about you, but when I look out and see my peers, I don't know if I would trust them to dictate what I put in my browser. But maybe that works for all those sheep out there. Maybe. I don't know if I want the next Farmville plugin to be whitelisted, but, you know, it's an interesting idea that maybe in certain organizations, it's okay. Especially if you make the voting system a little more... Well, you engineer the voting system to take advantage of it. For example, the vote is prompted to be should you or should your coworkers be wasting your band with watching these videos on the site? Yes, no. If you engineer in that way, maybe people will then vote a little more harsher. But it's an interesting idea. There's been some examples of people trying to do that for spam. And there's the dance guardian squid voting mechanism that people have experimented with a little bit for the web filtering. So it can't be any worse than what we've already got, I guess, is what I come down to. But maybe we introduce more complexity. So I'm not going to lean real heavy on that. But it's an interesting idea. We can at least do a public blacklist. But it's a hard problem. All right. So again, we've got the applications kind of split, right? Half of the problem could be on the client side. Half of it could be on the server side. We've got all these different layers though, right? We don't just have to attack the application. We can attack HTTP. We can attack TCP. We can attack IP. We can attack DNS that gets us to IP. And we still got ARP. We go down the stack for DNS as well. I mean, we can attack any one of those layers. It's going to be a problem. And then there's all the contextual problems that are kind of manifested. If you haven't seen Arsenic and Jabra's de-anonymizing you last year at DEF CON, you really should go and review that, especially if you haven't seen it for a while. It's good stuff. One of the goals I had for this talk was to see if we could at least start addressing the issues they talked about. And we're close to getting at least proof of concept type to address each issue now. And then if you saw, it was a Friday, Peter's talk on the PanoptiClick from EFF. How many people saw it? Yeah? Awesome. Yeah, so that was good. You can go to panopticlick.ef.org and look at the paper or you can go back and buy the video or find it somewhere and see him explain some of the details of the anonymization. We'll be looking at a couple of things that are very similar. But for those of you who haven't seen it, the idea is that there's all these different bits of information that can identify your behavior or your browser. There are some things in headers. There are the header sequence. There is your history in the browser. The system fonts. The unique combination of plugins you have. There are many ways to go through and detect you. And that's the idea of the PanoptiClick experiment. It's a good start in trying to work out some of these issues. So a couple of things about the fonts, for example, fonts and plugins are the hardest part to de-anonymize. Or excuse me, to re-anonymize. They're the easiest thing to de-anonymize. But we can go through and there are flash calls to pull in the system fonts as a feature. Very simple. There's some other examples, too, where via changing or comparing two different div tags that use different fonts, the width and the height of the font, I will tell you if that person has which particular font installed or if the browser had to go grab something else in that family to display it. So it's not as precise detection, but it's still enough to maybe track you as you. The plugin stuff add-ons extensions depending upon what you read are even harder, though, because well, that's more of an internal browser thing. It's not something we can look at on the system very precisely, anyway. There are things you can look at on the system, but it's harder. We can go through and look and see how the browser handles different types of content. Ask how it can handle it. We can even use the DOM, the document object model, and ask navigators.plugins how to do that. And that is another way. So since these are ways we can identify it, we're going to have to come up with ways to lie to every one of these, basically, or to defeat every one of these combinations. So the easiest thing is to just, if someone is going to single you out for some reason, just look like not a random person, but maybe you want to look like somebody else, then they can't tell you the difference between you. So everybody doesn't have to look the same, but if you look the same as a few other people that are fairly unique, maybe that's good enough, right? Because if they're unique enough, then how are they going to, and you're really good at mimicking them, it's going to be really hard to tell the two of you apart. The real problem there is then you're really trusting in how good that person is, and you're giving up a little control, right? Now you're going to have to mimic that person whenever they do. So it's like when your sibling or whoever would start mimicking you and you start punching yourself so that they punch themselves. I mean, you've given up control of some of your behavior. So I don't know how I feel about giving up control, but it's an interesting idea that I don't have to be entirely random, I can only just mimic somebody else. And if there's enough people mimicking other people, but not all mimicking the same person, maybe that's still good enough to anonymize us collectively, all right? Now, of course, to do that, we want to sanitize input and output, we want to anonymize and randomize our behavior as well, all right? We either fake it, whatever they're looking for, they're identifying bits, or maybe we can engineer it ahead of time. So defeating the header detection, we could generalize request headers at URL and host. This is fairly easy, proxies can handle this for us, they do an okay job of that currently, right? If we really wanted to mix it up though and really ratchet up the anonymization here, if you redo your proxies so that they jumble as much of the headers as they can get away with, of course, there's certain requirements, the host header, you have the get request and the host header can't be too randomized because of your destination, right? If you randomize it, you're not going to where you want it to, and so that's pretty much our limitation there, but we could do that, maybe add some benign headers, maybe some benign parameters just to kind of jumble things up and make it look a little bit more random, increase that noise level, and then maybe what we want to do for the cookie stuff to detect you is we want to take control back of our cookies, right? Don't let the browser decide when to send them, when to clear them, and do everything else. An easy way to get started is to make a browser helper object, for example, or extension clear all the cookies on browser open. What if your browser crashed and you're used to just clearing things when you close? Well, when you pop it back up now, there's that leak. I also think it's kind of neat to be able to groom your cookies, stash them somewhere outside the browser, and if you do want them back, then you can actually dictate when they go back in your browser and can be sent to the server. So the components are there, but I haven't seen a plug-in that really lets you automate that nicely, and so that was one of the things we wanted to add into the suite, which we still have a lot of work to do. History enumeration, go everywhere, at least the top 500 sites. Now, you don't have to manually go there. You can have a plug-in do it for you, right? Have it go to the top 500, and then go through and delete your history so that any extra things you go to that aren't in the top 500 aren't there. Now, that itself is a pattern that can identify you, but if we all did that, now it's normal, right? Somebody might be able to identify as that, gee, that's somebody with that tool, or that's somebody who was at DEF CON who heard about the technique, but not necessarily who it was. And if we do enough of these randomization things, as we keep building this up, maybe that's enough to keep us fairly, fairly safe as far as anonymizing our privacy concerns. But it's probably not good enough just to hit the sides. We probably want to do a little bit of crawling, make it look kind of real, maybe mistype a request once in a while to really make it look like both from the wire and from a media analysis standpoint that maybe one might even call it anti-forensics, that it wouldn't look that weird on the drive, right? A font detection is tough, though. Basically, because of the wonderful things that Flash lets you do, it asks for fonts, and, or it's easy to ask for fonts, I should say. Now, we can take something and make our own Flash engine, use the JavaScript Flash interpreter that exists and throw out that, but it's harder, now at least we can fingerprint, that people have done something to try and block the Flash, call the fonts. So we could do that. I actually prefer the idea of just changing your environment. So if you start with a virtual machine that has a clean install, then you have less font moving you have to do, but with no extra supplemental fonts installed that come with your third-party plugins, there's not gonna be much to fingerprint. You look like a generic XP Service Pack 2 or whatever that never got any plugins, never got any third-party Acrobat installed or something like that. There's a huge cost, though, that takes us time. If we're downloading these randomly from an archive and uninstalling them randomly, that's going to take time, but it is possible to randomize those system fonts even locally with just a outside the browser tool, right? But I like the idea of being able to create a snapshot. So let's make a snapshot of Acrobat 6 and InterExplore 8 and whatever, and then that'll be a signature and then you can groom your browser to look like that. I think that would be the way to go. But the problem is we've got a lot of work to do. We've got to collect a lot of different signatures that way. So that's one of the reasons we want to start the project is to start collecting those signatures so that people can pick and say, I want to look like this combination of fonts. Some technical details on it. We can use a couple of ways here to detect some fonts. Defeating it, well, we can munge those calls. We can go through and just break the call so that it doesn't answer correctly, doesn't even call it correctly, or we could even catch the response and make it lie. And there's actually example at the end in a screenshot of how we can do that. The JavaScript way in the same way, right? We can catch it or maybe it's better to create benign fake fonts. I wouldn't say it's better. It actually slows down your machine greatly having tried this. But if I have a font that's every single possible realistic combination of width and height, then you can't really distinguish me from another me that has the same benign fonts. The problem is the system really slows down when you put a lot of fonts on. And so that's not as realistic, but maybe we can at least fake the common ones. So a couple of ways to do that. We can just move things in and out. That's okay. We have little registry shenanigans we got to perform, but it's possible, especially if you really are concerned with your privacy, maybe in your situation that works for you. It would be nice to have the option is what I'm saying. And then there's some similarities between the font and the plugin detection that we have to use to try and get around things. It all comes down to if we can either create a normal fingerprint or throw out what we have to become normal, that's probably good enough to get around the bulk of the identifying information that tools like PanoptiClick have proven it's easy to do. Now if we're jumbling these things around as we're doing it, that creates a lot of complications. So it's a concern and it gets even harder as browser things change, right? As plugins change and as Adobe writes a new function for the next version of Flash that does the same thing the other ones did in a differently broken way. Now you've got to do that one. So it's problematic. Now specifically with those plugins, what's problem, I mentioned A, if everybody else normal becomes bad, right? I don't want to now look bad necessarily. But maybe I can do fake plugins and it's actually not that hard. And not as hard as I thought anyway. We can register CLS IDs in the registry for Windows folks and then we can do mind types and redirect them to benign plugins that do nothing just to make it look like we have those. Again, creates a new pattern though because if you have a page that does the fingerprinting that tries to actually use those plugins like, hey, do you have Windows Media video streaming? And you say you do, but when you run the Windows Media video that has a JavaScript call, an embedded script that goes and does something else and that behavior never happens, obviously you don't really have that. But again, if enough of us do it, there's enough people that have that fingerprint then we all look the same as that set of fingerprints. And that has less of a performance impact than the font things. It can be tough to fake, but it is possible. The real problem is in the plugins always updating and changing. So now we have to fake every plugin version that comes out. So that's a little tough, which means we basically have to brute force and enter into the registry every combination of possible CSL ID in Windows, for example. And maybe we can just not do everything because of that problem. Maybe we do the top 100 of those plugins, top 100 common ones. And maybe that's good enough. And of course Safari and Opera don't have that many extensions and plugins. At the time I wrote this slide, there wasn't that many, but we can at least make it look like you have that many. And maybe that's good enough to remove some of those bits of identified information. Other things, now with exploiting, like a classic pivoting, I say classic, like one of those beautiful pivoting attacks where you make the web browser scripting language do the port scanning for you, or some other enumeration, like making an image link to the UNC path on the network where Windows networking goes out, tries to look for an image, if there's not an image at that IP address locally, then that machine might not be up depending upon how it errors, is how some of that works. But these are problematic because proxies that are out there that are available to us only capture HTTP, HTTPS, FTP. They don't catch these extra things that Internet Explorer added in, like Windows networking, the res call to pull in different resources from DLLs. So we have to think outside of a proxy. We have to either hijack the system or the browser itself. Hijacking the system's kind of tough because we need visibility into what the browser's doing turns out that the browser helper objects are perfectly positioned anyway to deal with this. We can hijack the scheme that call to the resource. But true anonymity's gonna be tough. We're not trying to do that. We're just trying to get a little bit of privacy. It's like the privacy a bathroom stall door gives you. It's enough privacy to get your business taken care of. Well, for most of us. So I'm trying not to let my imagination run wild. Sorry, a little too much caffeine. So in our defense, if we can hijack everything the browser's doing instead of just those schemes with a proxy, which we can do, then maybe we'll make a check. For example, this at the bottom is one thing you can try. It happened to work on my Windows 7 box, so it still works on IE8. But you can go through and at least tell a little bit about the system, you know, what version you have. Here it's local, but I can still maybe try to do that over the network. Well, defeating stuff over the network isn't terrible. It actually is a little easier than I thought. If you've never used proxy chains or Proxifier, you should try it. It's a little weird to wrap your mind around sometimes because the documentation's a little bit limited. But the whole idea is we can take something in any TCP or any network traffic it does, send through a proxy, even though it's not proxy aware. We're wrapping the application in something that is proxy aware. That actually works pretty well for catching other things the browser does against your network. All right, an example here that I have is actually a little code snippet from the project, from the X06D inside of JScript. We match on RFC 1918 private IP addresses or the loopback start, and if that's there, we override it. But we don't just deny it, we send it somewhere. We send it to a null-routed IP that this is actually the one that Code Red used to denial of service the whitehouse.gov site, but it didn't use the DNS entry, it used that IP address, so everybody just null-routed it. Well, we can all, I hope that's not reissued to anybody, but we can all just send it somewhere. And then the time-out stuff that the Ajax calls or whatever happens is still going to time-out, it'll all time-out the same. All time-out the same, we're removing that pattern. So we're kind of neutering the payload, we're not not running the payload. So we don't have to catch the whole payload, we're just making it go somewhere else. Again, this does lean heavily on normalizing that IP address, this is only the normal IPv4 format, what about the octo format or decimal format of the IP address? So we want to catch those two. But it's a start, you know, this is, I can only fit so much on one slide. So that helps some of those payloads, we can catch it outside, even if somehow somebody figures out how to make our browser not go through the proxy, we can have the proxifying process capture and send it through there anyway, right? That does, if we're black-holing the IP address, that takes care of that. Now the real problem though turns out that, well, stuff back to yourself is still problematic. If it goes back to local host, a lot of things don't get captured. Like in an Explorer, it doesn't necessarily, even though you can tell it what host to go to and it does put local host in there when you're accepting proxies, when you just set it manually, still a lot of things still work, even if you remove that. So we still want to be able to hijack the browser itself, not just surround it in a proxifying thing, all right? But this actually takes care of a lot of our problems with at least the payload stuff and some of the identification of your internal network, not just your own local machine, all right? But if there's port scanning or the beef, the browser exploitation framework stuff is mostly defeated by just doing this internally. I mean, yeah, your browser's still zombified, they can make you do stuff like go hit ads, but they're not gonna find out more about against your internal network. Now as far as payloads like cross-site scripting and classic stuff, that's tough. Again, it's been tough, it's been tough for everybody. Everybody gets bit by cross-site scripting eventually. It's one of those kind of things. So it's tough to do it reliably, but maybe we can, maybe that's a good, a good voting system for us, right? We have the no script way to do granular, allow this object or this function, but people vote on what's good or we rate on how dangerous that script might be. And then you go through and add that up through the page and then you've got a rating system like spam assassin that says this page looks a little more dangerous because of these types of scripts that are going. And you wait to the JavaScript body that was between two script tags, it's all encoded and not clear text. Well that might be worth a point. If it talks to the navigator.plugins object, well maybe that's three points because just use the plugin, don't ask me for my plugins, just use it. That's not something I want you to do. Maybe we can add that up and aggregate it to know if that is a dangerous thing to block or not. Of course that's gonna require a lot of work and a lot of ongoing work, but I'd like to add that in with this project that we've started. Part of the problem is too, like Peter was saying with PanoptiClick, there's not a lot of good data out there about things like this, but we have to start collecting it. We gotta start somewhere and then decide how realistic that is before we know where to go with it. So I think really the way to solve some of the problems that are introduced with extensions and browsers that are less than desirable, vendors are taking too long to deal with things. There's a lot of finger pointing at certain organizations and, well, some of the finger pointing is deserved. Don't get me wrong. Certain people are more fault than others, that's for sure. But until then, it's nice to be able to defend yourself. So between a browser extension or a browser helper object and a proxy, we can really increase a little bit of safety. We can't take care of everything, but we can really take back control of our desktop a little better. So the suite we're doing, we're hosting a source forge, it has some, everything we can is actually done in JavaScript to make it injectable. Wouldn't that be great if you injected in your proxy to protect your innocent sheep workstation guys, the stuff that would defeat things? So they browse somewhere and your proxy injects it instead of then figuring out how to disable their browser or using an unapproved browser on the network or something like that. So we try to do everything we can in JavaScript. To supplement it, there are browser helper objects that give you the visibility into the browser itself. We've had a few of those now that we've built and we've leaned real heavy on those third-party tools. That's why we just call it a suite. So we have tools that do good stuff for us. Like NoScript is pretty good. And if you saw the talk last night on Blitzer Blider, sorry, German in the morning, not so good. Awesome stuff, but we need them all. So we're trying to try and get things all integrated. All right? If we combine that with a repository of signatures, then we can now, we don't have to be completely anonymous. We can just look like everybody else is that, all right? Definitely looking for contributors though. Contact me if you feel like you've got some resources you can put towards it, both contributing signatures and we have a lot of work to do on code. So what we've leaned heavily on so far to kind of test things out was Fiddler. If you haven't seen it before, you probably should. Maybe you've heard of it and said, yeah, it's just another proxy. It's actually pretty slick because it has several cool components. Of course, it's portable enough in .NET 2.0 as far as being able to run it on Mono. It also works with ProxyFire, big plus. There's not a problem with that. Even though it only naturally looks at HTTP and HTTPS, we can still make everything the browser does. Everything Fiddler does go through a proxy, which is pretty awesome. And it has Fiddler Core, not just a GUI that lets you control stuff. We can actually consume its library by another .NET application and leverage the hijacking of our own browser, both as a proxy and as a hook into the browser. So it is written for Windows, but it can be used for other things and it can be, because it is a full-fledged proxy, you can send it traffic from other places. One of the coolest extensions they have for Fiddler is a DHCP spoofing proxy detection hijack. It's an extension for Fiddler that will hijack DHCP and tell people where the proxy is for the automatic detection, pretty slick. But you can get it, you can get the source code. Lots of cool things happening. 2.3.0 was released on what was it Wednesday, maybe Tuesday. Pretty cool stuff with Fiddler. What are we looking at doing? Well, switching from the classic anti-virus signature detection stuff, more towards fixing what the browser should be doing anyway, defanging the stuff that's non-compliant and rebuilding it. The Blitzoblider style from last night, hey, we don't have to match the bad flash because they're so bad at writing it, we just have to break it apart, look at it, find out why this is non-conforming, and then that's probably enough reason to know it's bad. Not just for detection, but what if we rebuild it? Is the emphasis on defanging it, right? Go through and fix the code so that it's realigned. If it was a payload that was written to get around some filtering or written poorly, it breaks it often. Clean up the bad guys code, sometimes it doesn't work. Even if it doesn't work, well at least now it's easier to do signature detection on once it's cleaned up. So that's the idea there. All right, some other things that might be interesting that we're starting to experiment with a little bit but we haven't got that far in the project is using basically copying into a temporary file how the browser rendered the page. So using the document object model to print what it says to a file and then faking the user agent string to a different user agent or maybe grabbing another browser instant specifically and then basically hitting the page three or four times with different configurations, to see how the page is different and then diffing them to see how different they are. Now just the fact they're different isn't good enough but if there's just some subtle differences maybe that's interesting to us. So that's something we're starting to look at. I don't know if we can get anything out of it but it would be kind of neat to see if, wow, this is only exploiting Internet Explorer 8 and the Firefox and the Opera version of the page both seem to render okay and are very similar. They're not trying to exploit you or if you come in as Googlebot, what do you see? You know, those kind of things. Could be, you know, especially we do the waiting the spam assassin style of how dangerous it is we could pick the least dangerous version to display to the browser. Significant overhead but I'm kind of liking the idea of being able to look at things in four different ways at the same time. Using alternative browser to render that. All right, so demos I'm not done enough to try and show you something, see how it doesn't work, it breaks it. I learned last time showing you something that's supposed to be not working is not very helpful in a demo because see it didn't work. But I've got some screenshots. So for example, here's just a simple JavaScript enumeration it uses the navigator.agent pulls it in. Now if you fake your user agent string this still says the real user agent string or the real browser agent because it asks via JavaScript what it is. So you spoof your agent string not good enough. The HTML source code shows you there it's just the navigator.agent object. Although I just realized I mistyped it in the left hand side of the equal sign navigator.useragent is correct on the right hand side. Once we've injected our custom JavaScript Cluj which it is I'll admit not perfect but hey it's good enough it's better than what we have. It sees that fakes it. Now the cool thing about Fiddler is even though HTTP is sessionless itself right you have request response and that's it. The application depends on things like cookies or session IDs to tie them together. Fiddler does its own session mapping to request and response. It says this is the response for the request I just sent. And that gives it visibility to what request it sent. So it grabs what user agent you spoofed and responds and just directly inserts the string there. Again not perfect and it's easy to break this. If I put in a window.navigator.agent then in the resulting source code here at the bottom of the slide it will actually window. And then the double quote in the string which JavaScript is not gonna like it wants it to be concatenated with a plus sign right. But guess what? Hey if we broke the script great I'm all for that. I'm perfectly fine with breaking the script that probably is just enumerating my navigator agent. I don't care, client side? My agent knows what it is, right? I mean what use is that? You're telling me to ask myself who I am. So what I mean an application that does that is only either written silly or up to no good. So if it breaks it great it happens to work out great for that. Now the actual Fiddler code that changes that code all looks like this, all right? Where first we just to try and minimize the signature detection against every kind of content we flip, we only look at the HTML. We go through and normalize it to UTF-8 as best we can which actually works fairly well. And then if there's a navigator.something anywhere in the page which even would be JavaScript it's going to go through and replace it. There's a couple of ways to do it. One is to actually change the length and that's actually for the plugins that if you ask navigator.plugins what plugins you have and you can actually set the length equal to zero and then it won't show up as navigator.plugins in Firefox right now. I don't know how long that's been. I haven't regressed tested that the whole way but it's kind of cool if I inject navigator.plugins.length equals zero into something that's new running in my plugins it shows up with no plugins. Of course, they can still try to use the plugin and know it's there. That's the easy way. But this is one way. Your system can have these fingerprints in any different combination. You have to be able to feed all of them. So that's what the first one does but there's user registry at the bottom is the one that replaces it on the request. Sorry, it replaces it on the response but from the request. Which is why having both a browser helper object and a proxy together is the way to go. Because we can now track the session real. All right. Here's the navigator.plugins enumerating. This is the result of what it looks like when it works. This is just a proof of concept here. Was this from, I think I leaned on a browser spy for this one. And of course, once it's working see it doesn't work. No plugins. And all we really did was we injected a equals zero, prepended it to whatever was there. Turns out that's good enough. It breaks it. That's fine with me. If it didn't break it, depending on if they just didn't set it to this variable L, then they would still be able to use it. If they weren't set it to a variable just use the inline, it would still replace it with something that would break it. So good enough. Good enough. All right. So it's tough and we have a lot of ground to cover. But it's not as hard as we've kind of let it get. We've let it get out of control. As far as the anonymizing stuff, there's a lot of things we can do to try and increase a little bit of privacy. Give us a little bit of an edge when it comes to being fingerprinted. And then that'll also kind of neuter some of the attacks because they often need to know what browser you have to own you, right? So there's a couple things we can do there. Normally I don't want to be one of the herd, but when you're running around with people you can consider your peers, maybe that's not so bad. So the more of us that contribute signatures, the more interesting things might get as far as privacy. So I have a few extra minutes. Does anybody have any questions? What about Zeus? That's not me. That's always my fear, but I can prove that's not what my laptop has on it, okay? Ah, what about Zeus? Well, what about it? What do you mean? We're redirecting the stuff. Yeah, we can totally hijack redirects. The problem as experimenting with it, hijacking redirects is there's a lot of them in a lot of applications. The way that it could help, which I don't have it specifically yet, but if we manipulate the redirects slightly and see the nice thing about having the proxy too, especially when you're talking about a whole network of machines that you're doing this for, once you've scanned it, or at least waited how dangerous it is, or okayed or whitelisted, you can cache it, right? So the bait and switch stuff, as far as redirects, like it's clean there, you'll save that. Redirecting fine, oh, from, yeah. Especially the cookie, what do you call it? Cookie escrow. And anything that would be a cross-site request forgery as well as redirects, if you're controlling the stuff that's used to keep track of your transactions, to keep track of your sessions, instead of the browser automatically following the cookie HTTP only expires stuff, you get control of that, that could help. I'd have to look at it again, though, to see, because we've done a lot of weird things in the last month. I'd have to look at it a little more closer, because, you know, Zeus changes every couple of months. Yeah, yeah, using other signatures would be good. I didn't like any of the ones I looked at. Oh, sorry, yeah. The question was, what about some of the, if I'm gonna rephrase it slightly, what about some of the other projects out there that do weight the dynamic aspect of a script and how, you know, it may be even potentially damaged, dangerous as it is. Is that close enough rephrase, or? Sure. Sure. There are other metrics we can use to help us rate how dangerous it might be, besides just people voting on if it's dangerous or using very granular things. The ones that were out there, personally, I didn't get a good feel for. I don't know if it was just, I woke up on the wrong side of the bed, but the ones I looked at other work that had done that didn't really look that good to me, but I don't know. Maybe I just looked at it on the wrong day. Yeah? Right, yeah, the question was, is it designed so that we can have it portable enough to have on random machines to build up the pool? You said, in fact, I don't know, I would use the word, in fact, but to supplement the collection of signatures and to help us increase and protect other people, yeah, it is definitely possible. Some of the browser helper object stuff isn't that portable as far as it wants to be able to see something it can talk to, so that would be something to work on in the future, definitely something that had more of a web service model to go and deal with signatures and update and things like that, but that's a lot of work left to do. We wanna work out the mechanics and see if it's worth deploying an infrastructure to do it, to support it. All right, I'm pretty much out of time, but we're gonna go to 1.13 if anybody else has any questions. Feel free to send me an email, it's easy enough to find me, but thanks for coming here on a Sunday morning, appreciate it. Thanks guys.