 Hello everybody. During the following portion of this presentation, we experienced technical difficulties. The problem does get resolved and the quality will improve shortly. Thank you for your patience. My name is Gregory Pleischer. This is a tacking tour at the application player. We'll get started with some kind of a brief overview of what this talk is going to be about. We're focused on here identifying tour web trapping kind of as a group of users than fingerprinting individual users looking at things in the web browser that may be used to unmask them. And then looking at constructing a tax at the application player in terms of web browsers, client-side script, and other client jobs. This talk is not about passive monitoring and exit nodes, networking tax against past selection, or using applications to improve existing networking tax. It's not about breaking it itself. Although all of those things have been discussed in the past, I'm not going to be talking about this. I'm strictly looking at applications there. So here's the software that I use. I look at the Tour Browser Bundle, look at the Daily Bundle for Windows, look at the Daily Bundle for Apples, and Firefox 2, Firefox 3, and Google 5, as well as Tour Button, and other business companies. So does your browser look like this? What do you see there? Some people say, oh, I see WikiLeaks. Why see? You've got the Google 2 more, you've got NoScript, and you've got Tour Button. Or maybe it looks like this. Some people say, oh, that's cross-site scripting. Well, I'm looking at you have security testing, add-ons installed, local rodeo, foxy proxy, and all this other stuff that remote sites can detect that you have these add-ons installed. So let's go to a little background information. If you're here earlier for Rogers Talk, most of this may be for you, but Tour is free software developed by the Tour Project. It's a volunteer effort on the internet, so anybody can participate, which is important because it's not some specific group of people, some specific club you have to join. Anybody out there can set up an exit node and start exiting traffic, which we're going to get to quite a bit. But people might have to use Tour. It's used to circumvent local ISP surveillance and blocking, as well as hiding your address. So here's a very traditional view of what the Port Network looks like. You have analysis browser, a set of three nodes that you're going to transit through, and getting to Bob's server. So what is the application stack as far as Tour web surfing? You have the web browser, which is probably Firefox. You have a local HTTP proxy. You have the Tour client as a SOX proxy. And then you have a Tour exit node that is actually doing the proxy request on your behalf. And then you have the local web server. So if we revisit our previous diagram, here's kind of the application stack. You can see the browser, the local HTTP proxy, your SOX client going through your exit to your exit node, and then onto the server. So let's talk a little bit about the adversary problem you're using, Tour. There are certain points in the Tour network where you're kind of at risk at an application there. That's at the remote server, any exit nodes, remote servers, ISP, as well as the exit nodes, ISP, any of those points, you're at risk for malicious activity. So it's important to understand that exit nodes can be attack points. Some people always think that, oh, it's just this place where you can monitor traffic, where you can look at stuff passively, but you can actually eject content into both requests and responses. So exit nodes can be used to attack you very easily, and this has been done in the past, and I'm sure it will continue to be done in the future. And why do people do this? The Tour users make an attractive testbed for man and middle attendants. We've all heard that people will come up with some thesis and test it on Tour users. It's like, oh yeah, we are able to break SSL and use this number of Tour users or something else, and Tour users are self-selecting. So only people that are using the Tour network are going to be affected by your attack. Let's talk a little bit about DNS requests. The DNS queries are resolved by your remote Tour node. They're not resolved locally. The idea is if somebody can cause you to make a DNS request, then you will be leaking information about where you're located. Perhaps your local ISP or if you're running a recursive resolver yourself, your own local network. And this makes traditional DNS rebinding attacks difficult because since Tourists slow in resolving these DNS requests, they're cashed for a minimum of 60 seconds, regardless of what the remote server's TTL is. But we've been able to see that it's not impossible to do DNS rebinding through other techniques such as the document.domain bypass. Applications in Tour. So only specific applications that are aware of Tour, either through the HTTP proxy or the SOX proxy, you're going to be able to use it without leaking information about you either through your IP address or through DNS requests. So we've modified our diagram here now and added in a couple additional attack points, which is DNS and external programs. So let's move on to the identifying stage. How do we go about detecting Tour users as a group? The group of Tour users, when you go to visit a site using Tour, you kind of stand out. I mean, sure, there are a lot of people using Tour, but in the global scope of the Internet, you're a very small group of people. So it's pretty easy to get a list of IP addresses of all the known Tour exit nodes. I mean, this is by design. You have to know what these IP addresses are to construct your path through the network. So something like the Tour bulk exit list can be used to retrieve a large exit list of all the nodes, all their IP addresses. But there are a few other alternative methods. You can run your own Tour client and collect the information yourself kind of in a very passive, simple manner. And now you're not going out and requesting this big bunch of data. Maybe you don't want people to know that you're looking up to see, oh, I'm trying to identify Tour users when they visit my site. There are some limitations to this, though, because not all the exit IP addresses are actually published. Some exit nodes accept requests on one IP address, but then send traffic out on another. So this kind of limits your ability to get, like, the global picture. So then there is a project called Tour DNS EL, which is an active testing exit list tool. And this is going to go through and actually actively test to try and determine what are the real exit node IP addresses that are being used to send out the traffic. And if you use the Tour browser bundle, when you load it up, it goes to check.Tourproject.org. This is using Tour DNS EL. Another approach at more of a higher level at the application layer, we can request specific content through HTML, you know, iframes, images, links, whatever, using some special syntaxes that Tour supports internally to get to hidden services you use .onion, to use a request through a specific exit node, you use the fingerprint .exit. So by doing this, if a user is not using Tour, then they're not going to be able to retrieve these resources and you can test for this, you know, using, like, onload events on image tags, on iframes. But there are some kind of significant problems with doing this. One is speed, you know, these requests are slow, especially for hidden services. Your onion request is going to take a long time. It also, you're depending on resources that are outside of your control. So, you know, these may come, these may go. So you never get a true picture of, am I actually identifying these Tour users properly? So there's another internal special syntax that Tour uses, which is .noconnect. And you can use this to test the speed at which you resolve DNS names that end in .noconnect. .noconnect is essentially a no-op operation. As soon as you request an address ending in .noconnect, Tour immediately closes it. Now, if you're actually requesting host names over DNS, even those host names you're going to a local DNS resolver are still going to take more time than it takes for Tour to close your socket. So you can use these timing discrepancies to actually identify somebody if they're using Tour. And what's attractive about this is it's entirely on the client side, entirely in JavaScript. So let's talk a little bit about fingerprinting. And we're going to focus on browser fingerprinting here through active testing of browser characteristics. And I primarily focused on Firefox and Tor button because these are recommended by the Tor project. And Tor button, what it does is it attempts to modify your user agent information to, you know, keep you from being, you know, easily identified. So Tor button picks a specific user agent string and uses this for all your requests. And I didn't test any other browsers on this stuff. I'm sure there are similar techniques that can be used. So let's talk about some anonymity set reductions in Firefox. Internally, Firefox has certain behavioral changes that vary between platforms and versions. And we can go ahead and enumerate all this information and test for it. One of the best ways to go about this is there's an internal components.interfaces that exposes internal Firefox information about what interfaces are available for xp.com. So for example, there's a NSI accessible Win32 object, an NSI Windows Reg Key that are only available on Windows. There's a NSI Mac shell service, an NSI local file Mac. These are only available on Mac OS 10. There's this NSI script security manager 190 branch that was added in 3.0.12. So you can test for these and identify what platform a user is on and what Firefox version they're running simply based on the existence of these values. They could be returned bogus information, but simply having them be present, we can enumerate them and test on it. So this allows us to unmask the real user information. I don't know how you well you can see this, but this is looking at Mac OS 10 and Firefox is claiming that this is Windows 2.0.0.16, but it's actually 3.0.10 on Mac OS 10. So using this we can very easily and very quickly identify specific user agent strings, even if you've attempted to hide them. We can also look for installed and enabled Firefox add-ons. In the old days, in Firefox 2, components exposed themselves via Chrome. Chrome content could be very easily retrieved. Some sawing extensions still choose to do this by setting this content accessible equals yes in their manifest file. So we could pull information from resources in Chrome. Now Tor button blocks this, so I had to come up with a different approach and that's to look at components that expose their own XP-COM interfaces. So like Google Toolbar, for example, exposes this GTBI bookmark helper. And GreaseMonkey exposes GI browser window. By testing for these, we can say, oh, you have this specific extension or add-on installed. And as we start to do this, you can start to see, oh, we can start to slice people up. Certain people have certain add-ons installed and other people don't. Like if you're using Tor button, you toggle this on and off. If you visit the site today using Tor, but visit it later not using Tor, we can start to come up with these anonymity set reductions and intersection attacks. We can also scan for custom protocol handlers. SMB SFTP or it's installed by the GNOME support package. There's a relative file protocol handler installed by Foxy Proxy and so on. Normally these generate these really annoying browser pop-ups. These modal windows that say, oh, I don't know how to handle this, but by wrapping these requests in a specific jar protocol, we can actually suppress those so this can be done completely silently. We can also generate and examine browser exceptions. These are internal exceptions thrown from the browser. These error messages from JavaScript are localized, and this doesn't depend on what your user agent setting is or what language you have enabled. You can actually then build a list of all the possible error messages and all their possible localized values to determine which locale the user has enabled and installed. Additionally, we can look for internal exceptions. Generate errors in the Firefox code. Here's a pretty good example. A browser feedwriter has a problem where if you create it without calling a method and then close it, it generates this exception message and it actually leaks your installation location. Normally that's probably no big deal if you have it just installed in the normal location, but if you have Tor Browser Bundle installed and you put that underneath your desktop, this will reveal your username. This can happen in Linux and Mac OS X as well. We can also enumerate Windows com objects. Normally this would seem like it's impossible. Firefox doesn't support com and ActiveX, but there was this old kind of Netscape thing in there called Gecko ActiveX object. You can create and instantiate ActiveX objects, but the problem is you have to have a white list. This white list is, I don't think it's really documented very well and it doesn't work. What's interesting is when you request a com object, there's a difference in the error messages that are returned if the com objects exist on your local machine versus if it doesn't exist. You can't actually create it, you can't call methods, but simply by testing for this existence, you can start to look at different plugins and add-ons that are installed. You can look for specific versions of programs because some versions of programs differ, like Microsoft Word varies their com object, prog IDs based on what version you have, so it could be Microsoft Word.A, that kind of thing. Let's talk a little bit about local proxies. Local proxies are kind of a blessing and a curse as far as Tor is concerned because although it allows you to actually use Tor because Firefox has some problems if you try and directly use the SOX proxies your port to surf through sometimes, they also then start to expose this other part, other application, the attack point. The Vidalha bundle ships with the PrivOxy as its proxy. Tor browser bundles use as Polapo, and PrivOxy is a fairly old proxy that's been around for a while, was originally used to try and limit web browser bugs, that kind of stuff that we're trying to break down your privacy. Polapo is much newer, it's based on HTTP 1.1, it's caching, and it has a different set of problems. So we can look at these behaviors and content and start to come up with a way to identify which proxy you're using. Our snake demonstrated attacking PrivOxy using its built-in CSS like in 2006, and it still works to this day, this hasn't ever been addressed. But it could be, it could be very simply addressed if the remote config.privoxy.org site simply hosted the same content, but nobody's ever done that. But there's also a shortcut method in PrivOxy, which is p.p, and so there's no way that some website's ever going to be able to host p.p, so we can just modify our detection routines and use p.p instead. These proxies also exhibit locally detectable behaviors, such as the set of filters on headers that the Tor browser bundle uses in Polapo are from Accept Language, XPad, and Link. So we can generate XML HTTP requests and actively test for this. Generate a list, add these headers to our request, send it out to the site, see if they made it. If they didn't make it, oh, we can tell you're using Polapo. And we can also then move on to looking at when we cause these proxies to have errors. If we can read those error messages back, we start to get information about what versions they are and perhaps other information that can be used to reduce your anonymity and privacy. Because some of these error responses include the proxy version, your host name, the local time and time zone, and as long as we can maintain the same origin, we can read these error messages back. Here's a Windows PrivOxy error. You can see the version and what host it's listening on. Here's a Windows Polapo error. We can actually see then the local time zone of where this is. Here's one from Linux that this is Ubuntu and it would stall via AppKit. You can see the actual host name of the machine. So how do we go about generating some of this information? And we can use browser defects and educations to get to this, like generating a post request without a length, using an IPv6 host name. We can use malform authorities, bogus HTTP methods, and the most successful one so far I've discerned is the IPv6 host name, both PrivOxy and Polapo and other proxies fail miserably when attempting to parse that. But even if the client side is fixed, we can still cause errors from the server side. We can generate requests but then drop and want to connect or we can return just completely non-sensical HTTP headers. So anything in RFC 2016 is probably fair game for these types of attacks. So let's talk about active attacking of Tor clients. So here are some historical attacks of note. The first was a paper, a white paper put out by Fortonsault called Practical Onion Hacking. And they went through and they really, in my opinion for the first time, proved out the fact that by generating active malicious content at exit nodes, you could work to unmask people. What they did is they ran a modified exit node server and looped back through a local proxy and used Perl to just like dump in client script. And this client script would then try and load Java code and make image requests and try and do other tricks to bypass the local proxy. HDMorrick did a similar thing. He was trying to filter out BitTorrent users for torment and that kind of got all taken out of context and blown up. But he also has a site called decloak.net, which is the Metasploit decloaking engine. And this goes through and does another set of similar attacks and works to defeat your browser protections and launch external programs such as Word and iTunes. And then let's talk a little bit about control port exploitation. This was a very big topic in the summer of 2007. During the time of Defconn and Black Hat, Kyle Williams discovered a very interesting cross-particle attack against the local control port. Basically, what was happening was TOR was allowing multiple attempts at sending the authenticate request. And if you didn't have a password set, the authenticate request could be sent multiple times over and over and over again. So what would happen is you would create a form, an HTML form and post data. And this was set with multi-part form data, which meant that each line was on its own line. So it would see an HTTP, this, that, headers, whatever. And then it would finally get to the authenticate request. And once it got there, then you were authenticated and you could send whatever you wanted. So this was fixed by only allowing a single attempt at sending authenticate. But there was something else that was really big in summer of 2007. And that was DNS rebinding. And I mentioned before that the traditional DNS rebinding attacks against TOR didn't work too well. But we could use the document domain bypass to create, use Java to create raw socket connections. And at the time, TOR to button didn't block Java. So this was an extremely effective attack. So we moved on and then we said, okay, well, the protection is to set a control port password. Don't allow empty passwords. And we'll get back to that in a little while. So TOR button does offer some protection against scripts. It attempts to fill out some dangerous protocols like resource, Chrome, file, masquer identifying properties. And some of these are implemented in JavaScript. It's through hooking of the browser properties. But kind of what can be done in JavaScript can also be undone in JavaScript. So let's talk a little bit about defeating TOR button protections. We can use the delete operator to access prototypes of the original objects. And this has been mostly addressed and it's pretty much not a concern anymore. One that still works quite well is the XPC native wrapper. For anybody who's ever written a Firefox extension or add-on, you know that XPC native wrappers are intrinsically created when you're accessing code, client script that's running in a sandbox. So the idea is that by using this XPC native wrapper, you know that you're actually getting the real code, the real interface, the real property, real method. And it hasn't been modified anyway. Well, we can flip this all around and use this from our code to defeat the hooks that the add-on have done. So by using this XPC native wrapper, we can be assured that we're getting back the original objects. So things like the history object or the screen object can then be read their original values out. Another method that I discovered is using the components.lookup method. And this returns internally intrinsically-wrapped native function objects. And you can then call those to construct objects that are themselves XPC natively wrapped and use those to retrieve original methods as well. So let's talk a little bit about active content and plugins. Now, it's pretty well accepted that active content and plugins are universally viewed as dangerous to your anonymity, and nobody would use them and all this. But let's think back a little bit. Times have changed. We're no longer just...people aren't using Tor. Not strictly based on wanting to remain anonymous. There are a lot of people that are using it to circumvent local restrictions in their ISPs. The Iranian elections is a pretty good example. And these people want to use Flash. They want to view YouTube. They want to have Java enabled to do stuff. So there's going to be this kind of maybe a tipping point where it starts to be like, well, maybe it's not so bad. Maybe it's not so dangerous. And that should be a real concern because even when you have your plugins disabled, there's been discoveries that show that you can directly load content because internally Firefox has mime detection and file extension sniffing that kicks in. So this can be then used to really get after you. So let's talk a little bit about a Firefox 2 exploit that was pretty interesting. Tor Button behaves differently if it's launched from a disabled state versus if it's launched from an enabled state. And there were some approaches that you could use then to load the active content. In this case, it was Flash by wrapping it in multiple protocol handlers. And Tor Button was attempting to say, oh, you're trying to directly load something. And it would fire, but it would fire too late because by the time it had actually loaded, it was already too late. The Flash was running. So the way this was constructed was by using the jar protocol, sticking it then view source in there and loading it from a jar file, an attack file. And this jar file contained an attack.html and an attack swift file. And these two things then would be loaded, and the attack.html would directly load the attack swift file via an iframe. So let's talk a little bit about multiple browser attacks. One of the items on the Tor project website suggests using two browsers, one for Tor and one for other unsafe browsing. And it's important to remember that the unsafe browser doesn't have many of the restrictions or protections that your existing Tor button in Firefox is going to provide you. So you could be browsing content out there on the web, and this content could be trying to actively detect or attack your Tor button, your installed Tor client, directly through port 9050 or 9051, and you would have no protection. So that's something to be concerned about if you're using two different browser instances because by default Firefox isn't going to block attempts to access port 9050 or 9051. So these unsafe browsers can use vulnerabilities in plugins that you may have installed in these other ones, and there's been numerous discoveries of Java same origin bypasses, and using this you can attempt to create raw socket connections. Let's say for example that you have a same origin bypass in your IE Explorer, and it creates a socket connection and says, oh, well I'm going to make a request through your Tor client. You have a Tor running. It says I'm going to make a SOX request through your Tor client and go out to a server to see if that's successful, because if it's successful I know that you're using Tor. And maybe there's some other information that it can infer from that. Who knows, maybe if you're using a Polapo, maybe there's cached content that's being stored locally instead of going directly to your Tor client, it makes a request to Polapo and says, oh, is there cached content? Have you visited my site? There's all sorts of interesting and emergent attacks that become available when you have these multiple browsers that are all going at the same time. Something else that's very interesting and this is kind of covered by dcloak.net is that external protocol handlers can automatically launch applications that aren't proxy aware. So for example the Windows Telnet and LDP protocol handlers, these are installed by default, they're enabled but they're set to ask. The current Tor button doesn't change your preference when it's toggled and not toggled. So let's say you're using Firefox and something pops up and says oh, do you want to use Telnet? Probably you're not going to say yes, but maybe you did, maybe you said remember this. And then sometime later you have Tor button enabled and somebody says, oh, well here let me make a Telnet request. If it's set, not set to always ask, it's going to automatically launch Telnet and go out and automatically connect. And this is going to completely bypass your proxy settings and you're going to be just, they're going to be able to detect your real IP address which is really bad for some people. And the LDAP protocol handler is very interesting because it doesn't say this big long 132 DLL thing, it says address book. That sounds pretty innocuous, maybe you would be tempted. Let's say you're visiting a web mail site and it says this link needs to use your address book. That seems reasonable, it's your address book, it's a web mail site. Very easy to make a mistake like that and what this does is it actually goes out and makes an LDAP request. But once again it launches an external program and this external program is going to bypass your Tor proxy settings and it's going to connect directly to their site. Let's talk a little bit about running JavaScript in your browser. Something that a lot of people suggest is don't run JavaScript. Don't run JavaScript, you'll be safe. Don't run it. But there's this interesting problem that your add-ons that you install in Firefox are running JavaScript under the scenes and if they're doing stuff that's maybe making DNS requests or maybe launching external programs you're going to have a significant problem because you may think you're not running any JavaScript but internally your browser is running JavaScript. Here are some ones and I just focused on security type add-ons like perspectives which goes out in attempts to discern whether SSL certificates are valid and it does this by querying multiple sources. But in doing this it's using DNS and these DNS requests are bypassing your local proxy settings and this is especially bad in Firefox 3.5, I don't know if there was some change that was made or what I haven't been able to determine but it appears that any sort of synchronous DNS requests that are originating from your add-ons are bypassing your local proxy settings. Local Rodeo, that's another interesting one. Local Rodeo is an add-on that attempts to implement remote sites from connecting to your local network or local host and it does this by using DNS because it says oh, are you trying to connect? Oh, you're trying to connect locally. Where are you coming from? Well, I'll use DNS to figure that out. The NetCraft Coolbar, people install this because it has anti-fishing capabilities but once again it's using DNS internally bypassing your proxy settings. Now I thought this was pretty funny and I use it too but it added a new feature called ABE and ABE re-implements a lot of the local Rodeo functionality but when it does this, if you make requests to these local host, other alternative local host ones you know this D word one and this hex one it's going to go out and perform a direct DNS lookup based on the page that you're currently on. So all you need to do is add an image tag that requests a bogus image from one of these sites and it'll say oh, you're trying to go to local host stop, no, bad, where are you coming from and it goes out and does a DNS lookup. So right there it's leaking your DNS information and this appears to be like I mentioned, Firefox 3.5 seems to have problems with all extensions that I could tell but this is actually still effective in Firefox 3 so I'm not sure what the deal is there but that's something to be concerned about. Now add-ons may also launch external programs and this is a pretty good one Microsoft in their .NET framework installs this framework assistant and this gets installed as a global extension and if you've been paying any attention to tech news over the last several months this like blew up in the Washington Post Brian Krebs had a whole big thing and you know it just got all out of control and it released a patch and this patch then would instead of being installed globally it would get installed to your local profile. So what ends up happening here is this plug-in is kind of misbehaving it's no I shouldn't say plug-in it's an add-on it's kind of misbehaving because it doesn't register itself as a plug-in and it doesn't register itself as an application. Internally it's looking for application and when it sees that mime type returned in a response it goes ahead and launches an external program called presentation host and this presentation host then re-requests your original requesting URL using this external program and it does this all automatically. There's an option that says ask me before I launch this but they have it set to true and there was an older Firefox extension called once I believe and it had the same behavior the same kind of properties but its default was ask me before you launch this external network program so you know it's kind of some questionable stuff there so even though Microsoft released this fix this fix doesn't actually do anything if you still have it installed and you haven't uninstalled it so that's a big concern and here's kind of what it looks like the top one it's installed globally and can't be uninstalled and later the second version it's installed in the user profile and you know you finally can now uninstall it but there's a problem with the Microsoft fix as well they install this under your user profile and you know maybe they figure everybody's like most people and they just install Firefox and they see hard drive location and are done but some people run portable versions of Firefox and these portable versions your extension your local profile is installed beneath the data directory so what happens is like Tor Browser bundle when this plugin runs automatically it takes its existing self and reinstalls a version of it underneath your profile so let's say you had this on a USB token you ran this on a machine that had this extension installed it would get installed on your USB token and if you took that to a machine that you know you would remove this extension it would still have the same behavior the same effect somebody could still send this to you and because it's installed under your local profile on a USB key it would still launch it and you would still be in big trouble so let's talk a little bit about attacking saved content via Tor now I think everybody's probably pretty much aware that a malicious exit node or a remote server for example could go ahead and modify content that is returning to you especially if it's you know first identified that you're using Tor you know through some of those identifying characteristics I talked about or if it's done some finger printing it's looked for what extensions you have installed you know maybe it could target one specifically so I think that's all pretty pretty clear in people's mind that if you download like an executable over Tor and then run it that's just looking for big trouble so this troging content may wait to phone home even if you have your machine set up in such a way that you know all of your traffic is being transparently proxied and it's not going to leak any of your DNS information but sometimes even save content may not be so safe let's talk a little bit about locally saved HTML content this content you can force any HTML to be saved locally by specifying content disposition of attachment and you know people have known about this for years when you do this you know you get this pop-up box that says do you want to open or save this and you know there are sites out there that do this legitimately you know download sites web mail sites whatever you know they want to have HTML content but they want to make you save it so if you do this and you do save it later and this may vary a little bit depending on what operating system you're using if you click on that it's going to launch as an HTML file launch in your web browser so if this content had been trojan in some way you know this is all of a sudden locally active content running on your machine now web browsers have sandboxes that they run this code in but there are some interesting problems like in Firefox 2 local HTML could read any file any directory on your machine so simple as just you know clicking on a website a pop-up that says do you want to open or save this and you say save and then run it later it could just read any file on your machine and send it off now this has been fixed in Firefox 3 and beyond HTML locally saved HTML content is limited to reading itself and existing sub-directories that it knows about it can no longer enumerate every single file on your machine so let's look at what this looks like because there's something important to note here when you choose open in Firefox you're not actually opening a remote web page you're opening a locally saved version of that web page that's automatically getting downloaded in the background and being saved you can see this I'm choosing to open this HTML document and it's getting saved with this random name so you can't like reference it or anything but then later when as soon as I click OK it opens it from my temp directory that's running on my local machine we're kind of back to that same problem when you say oh well what can we do with this in Vidalha bundles with Vidalha version 0.0.16 and earlier the control password was saved even for random values in clear text in the Vidalha configuration file so locally saved HTML could read this they could go through figure out where your Vidalha installation is enumerating the directory structure of your machine open that file, read out the value so now if we had Java enabled we talked a little bit before about this is kind of in the bad old days if we had Java enabled and we just happened to have the same origin bypass we could then construct a request open a socket and directly connect to the Tor control port and send the password through so this could all be done fairly transparently to the user opening a file that came up and said do you want to open or save this so there are some additional blended threats that are possible and this is kind of some stuff that's been around for a while and you know it's kind of well known in the web application security realm but these the web browser and plugin content have different security models they run in different kind of sandboxed ideas so like flash has a different security model for locally open flash files what it says is it says oh you can read any file on the local machine but you can't connect to the network without the user saying yes you can connect to the network you know Java has similar restrictions it says older versions said oh you can only connect to the local host we can go ahead and then you know like this content can be set up in such a way that it it the remote server can choose to accept this request because a lot of time in web application security we're talking about oh you know how do I break the same origin policy whatever you know it's like but in this case you know the remote server can choose oh I want to do something I want to do something mean to this person so what you can do is you can use a couple of techniques you can use you can load locally saved HTML as a zip file basically using the jar protocol and this is kind of interesting because flash has some interesting properties you know as I just talked about flash its security mile says you can read any file any directory on the local machine so there's actually a couple ways to do this kind of the older way was to just combine this with an HTML into an HTML document it says you know combine local read with loader.html into HTML document serve that up if a user says oh open it it gets saved locally opens and then what's it do well what it can do is it can say I can load flash I can load myself and then flash says oh you can load other local files so it can reload your loader file as a local HTML file and at that point then you've read any file off your local directory and you can connect back out to the web and transmit it so here's the new technique that I came up with which is to use a temporary you know use a zip file but instead of storing content in there you know people think oh zip files are all compressed so there's no way to load it well what you do is you use the store method you know store it no compression and then when your browser loads this browsers are great they ignore like invalid garbage content embedded and all those whatever it says oh can I find some HTML oh I found some HTML let me parse it and load it and run script and do whatever so then this file can reload itself using the jar protocol to pull out specific pieces and once you're doing that then we're back to oh I can use direct iframe content and load it so let's talk a little bit about toggle button toggle attacks on tour button and these have always been pretty interesting but I don't think they've really been fully fleshed out you know tour button currently does a pretty good job of trying to prevent you from transitioning from one state to another and leaking information you know it handles cookies it handles cash content you know all sorts of other interesting stuff but here are a couple methods that you can use that attempt to defeat these protections the first is using a timer using set interval to create a timer and what this timer does is when you're on a specific site and you click you know let's say you have tour button disabled and you start this timer you visit the site start the timer in a new page you open it up and you say well enable tour button you start surfing now in that previous page that timer was stopped you know it stops all the JavaScript now you do you go on do whatever disabled tour button okay well that stops but the new page starts running again and that timer can detect the timing difference between when it was started and then stopped and when it was restarted so you know you can use that then to kind of time how long somebody has been using tour and had it enabled you can also remotely detect tour button banned ports tour button banned some ports it adds it to the the list of banned ports in Firefox port 9050, 9051 8118 and 8123 those are the 8118 and 8123 are the the HTTP proxy ports for pre-voxing and pull-up home another another interesting one is the show modal dialogue the return value can be set using window.returnvalue and when the dialogue pops up if you would do something like toggle your tour button state the existing state is maintained back there and it gets transferred back when you close that pop-up window and the JavaScript that's currently present waiting to be run is rerun now I'd hope to have some demos do some live demos up here but one it's kind of tricky with tour running over the web especially on a hostile network like Defcon and as I was preparing for this I was thinking about I'll maybe I'll record some movies and I got this pop-up one day it said er ready and I clicked okay it was an alert box from Firefox and Firefox crashed and I was running this in a virtual machine the virtual machine hard drive started grinding away and I'm like oh I think maybe I should kill this virtual machine off and revert it to a known good state and what had happened is somebody had launched an exploit and I'm pretty sure that this was some sort of exit node it injected an exploit into Firefox and had basically owned me so I wasn't particularly ready to get up here and get owned on stage so we're going to skip the demos but the demos this is a temporary location the real locational this will redirect to it but I just put this up there so everything I've covered here it's live on the web you can try it out something else I'm hoping to do is to go through and you know this stuff all kind of you know if you look at the code it all looks like a magic trick but what I'm going to do is you know post about how I actually went through and got like component information out of these Firefox versions and add on so that you can actually reproduce this yourself so what are some conclusions to draw from this there's a huge application attack surface here I mean just gigantic and you know all of the you know web application attacks that people know and love you can repurpose a lot of these to attack tour and what's interesting is you can actually take some of these things that I've come up with here there's nothing specific about tour and use it to you know just do normal attack normal web traffic you know fingerprint normal users I mean there are other add-ons out there in Firefox that say oh I want to hide my user agent oh I want to hide what language I'm using you can repurpose this stuff and you know use some of the stuff I wrote specifically to kind of get around some of the tour button restrictions but there's nothing you know really groundbreaking about some of this stuff so what can you do you know consider using an isolated environment you know I'm pretty paranoid with this I always run torn VM especially when I'm doing research on this stuff because like I said you know it's very easy to just get owned you know only installed the software you need run a regressive you know like egress restrictive egress firewall you know limit your traffic and you know consider transparently sending the traffic out everything over tour kind of from an isolated environment and and you know definitely remember your safe web browsing habits consider using isolated identities don't mix your identities you know come up with a specific identity when you're using tour and only use that identity you know come up with a different identity when you're not using tour you know only post under a certain count you know be very cognizant of not mixing accounts and definitely don't ever trust anything that was downloaded over an unencrypted channel and I guess really don't trust anything that was downloaded over an encrypted channel now either so that whole SSL thing is pretty funny so here's some references and that's about it so