 Okay, let's start. First of all, thanks for coming today. Let's appreciate it. And let's start. We're going to talk about abusing FIFO's extensions. In the app that we wrote, abusing FIFO's add-ons, but it's more, it's going to be entirely focused on the extensions. Before I would like to start, I would like to ask you, how many people here are using FIFO's extensions? Can you please raise your hand? It's pretty much, it's a lot of people. I use extensions as well, and also Nick. They are cool, but yeah, they are not so secure, and we will show you why. My name is Roberto Sugilivrani. I work for Security Assessment dot com in New Zealand, senior security consultant. I'm the office in New Zealand leader. And my website, malaration dot net, you can find some articles on my research. Beside me, that's Nick. I'm Nick Freeman. I'm also a security consultant at securityassessment.com. My personal site is up there as well, and email address is if you want to contact us after the presentation. So just brief overview of the agenda for today. We're going to give you a quick introduction to what FIFO's extensions are and what makes up the application stack for the Mozilla platform. Then cover some security threats and risks associated with the extensions. And then we're going to show you all of the bugs that we've found. We've got a disclosure summary, and then some demos and exploits. Some previously unreleased vulnerabilities as well. Okay, thanks Nick. Short introduction just to give you an insight on FIFO's extension technologies. Well, if we can see extensions just softer at the end of the day, and if you think about internet explorers like ActiveX controls, I see actually so many ends before, and I think the reason why you have FIFO extension installed is that's because you need extra functionality. You need something which is not provided by default in your FIFOX browser. And that's the reason why extensions actually exist. As I said before, according to FIFOX Mozilla terminology, they use the word add-on. But with the word add-on, they're actually indicating different things like extensions or language packs or teams, search engine plugins. For the rest of this presentation, we're going to stick to extensions just to avoid any confusion. The scheme you can see there, it's a very nice diagram, showing all different components which are used in extension and most of the Mozilla applications. But what I would like to give you an overview, it's more the technology which are really related to extensions. So you can better understand when we're going to show you some vulnerabilities and the demos at the end of the talk. Starting from the Zool, which is the XML user interface language, the one that you see read. That's basically used to provide the graphic layout of the extensions. Just to give you a sample, that's the FireFTP. I don't know if any of you use that. That's one simple page. That's a Zool page. I don't know if you can see the URL, but that's a Zool page. And that's basically defined the graphic layout, scroll bars, any buttons you might have. The other very important component is XBL, XML binding user language. That's also very important because it defines the logic and the behavior of Zool widgets. So if we come back here, anything you do in that window, like clicking one folder or moving a scroll bar, that might be defined through XBL. And then we come to XPCON component. That's very important. Just stick that for the rest of the presentation. XPCON component are the core functionality of your browser, Firefox. There are thousands of components and interfaces which are shipped with the Firefox, and these can be used by extensions. So again, if you look back here at FireFTP, it's showing your C folder in the window. When it's doing that, FireFTP is actually using an XPCON component interface to actually show the listing of your C folder. And that's one example using XPCON components. So it allows you to interact with your operating system, allows you to talk with your network libraries or access the file system. And of course, you need a middle layer to interact with the XPCON components, and that's called XPCONnet. XPCONnet is a middle layer, and as you can see on the bottom there's JavaScript. JavaScript can actually talk to XPCON components through this layer. I will see some examples later in our demo. And last but not least, it's Chrome. Don't confuse with Google Chrome. It's something totally different. Chrome in Firefox, it's a previous browser zone where the extension code runs, and it's fully trusted by Firefox. We will use this Chrome many times in this presentation. Just keep in mind for now. Security model. Well, that's a very important slide. Security model in terms of extension is not really there. So starting from the concept that when you install one extension, the extension can actually modify another extension which is already installed. And that means there are no boundaries between the extensions. Firefox has been designed for functionality to give flexibility to you for installing multiple different extensions. But it wasn't being designed to actually secure your extensions. The other thing to keep in mind is that XPCON components, as I said before, they come shipped to Firefox, but they also can be introduced with the extensions to provide new functionality. And they can be written JavaScript or can be written C++. If they're written C++, that means they're compiled, and they can be voodoo to memory corruption bugs. The other thing is that when you install an extension and it's going to talk to your file system, for example, you don't get any notification. You don't know what's happening. The extension might talk with your Windows registry or might modify some files in your ETS, et cetera, et cetera, directory. You don't know what's happening. That because there is no access control policies between your extension and your operating system. And yeah, that's why we consider non-existent. There is no security model for extensions in Firefox. Okay, just to give you some numbers and stats, that's something which is happening right now. And Firefox is getting 50% of the browser market share in some countries, like in Africa and in Asia, but globally still 20%. But the trend, as you can see there, it's actually it's increasing, and in turn it's losing a bit. And if we think in terms of extensions, the one that you can download from the add-on Mozilla org, AMO, that's increasing. The trend, it's in November 2008, it was one billion downloads. I don't know how much it's now, Nick. I think it's up to about 1.5 billion now. They actually keep it on the side all the time now. But this doesn't include any of the extra melons you can get from software packages or anything like we're going to discuss in this slide here. So you can get them from things like Skype or ABG or social networks and stuff as well. Yes, like Nick was saying, AMO is not the only place where you can get extensions. So like when you install Ubuntu, for example, you have an Ubuntu extension which is installed by default in your Firefox, the same with AVG or if you use any social bookmarks, then you may have a Facebook extension or something like that. So how do we see that from our point of view and users? Well, I think most of the people here install the extensions. And that's most probably because you trust the add-ons side. And probably you trust the extension which I recommended. You might trust the extension also because they're open source because you think people are reviewing the extensions. And there are no bugs inside, everything's fine. And yeah, that's the reason why you stole. But there's also some misconception there. So people think the extension is secure, especially if they think about non-script or a dblog plus, which are security extensions. But if we see from this point of view, these extensions do not provide any security if you stole any vulnerable extensions. To be more clear, like, non-script has got some white listing URI starting from Chrome, the one which I mentioned before. If there is any injection in Chrome, that will not be protected by non-script. But we will see that later more in details. And the other thing is with softpedia. There are portals like softpedia, which they say, oh yeah, it's 100% free. There are no spires, no viruses downloaded. So they invite you to download the extensions. But there's no security check done. And the other thing is other two figures are involved here, developers and reviewers. So extensions developers, during our research, we found a lot of bugs. And we noticed that some developers, well, a large number of developers, they're not professional, they're not involved with any company doing these kind of extensions. It's more coming from passion or hobby. And so in terms of maintenance, or if you send a security report, they're not really ready for that, or they do not provide any professional support. And that's something which I was scanning a little bit. The other one is reviewers. So they're reviewers like volunteers. Whenever you, anyone here can write an extension, submit it to Mozilla, AMO. And that is going to be reviewed by volunteers. The problem is that they don't have comprehensive security checklists to go through. They only have few guidelines, which will help them to identify any virus or any malicious content extension, but nothing which is, in terms of vulnerability or bugs. And then we do have some, of course, we do have some concerns or name on the way this process works. You submit an extension, and then it goes through this process. The problem is that when the extension is new, then it's going to be reviewed. But when the extension is not new anymore, and it's trusted, it doesn't go through the review process. As you can see from the bottom, following the bottom arrows there. And that's a problem in terms of reviewing things. You want to add something here, Nick? Also there's the sandbox at the top there. Those extensions that are in there are the ones that show up as experimental on alons.mazilla.org. So you can still actually download them. And these things haven't been reviewed at all. Someone could have all sorts of nasty crap inside there, and you'll just download it straight away. You used to have to create an account and sign up for it to do that. But now you can just tick a checkbox and go away. Also some other issues, a few extensions don't use AMO for their updating. So they can include an update.rdf, which basically tells you where to check for updates. And how often, things like that. And those will point to the install file on the developer's website or somewhere else. So these things aren't being reviewed by AMO whatsoever. So things that are recommended and available on AMO can distribute the updates their own way and bypass the review process entirely. Yeah, that's a good point. So basically there have been some cases that passed between using extension and malware at the same time with viruses or trojans. We have three cases there, starting from Forrest Spie in 2006. That basically, the ex-em trojan was installing a malicious extension to Firefox. And the malicious extension was actually a way to steal all your logins credential or bank account details and send it to some other site. And the same with Firestarter Fox in 2008. That basically was hijacking your browser and sending all your search results to another website, which was a Russian website. And slightly different was recently more recently with the Vietnamese language pack. The guy which actually was responsible for uploading the language pack was owned by, I think, an ex-Oro Trojan. Ex-Oro Trojan. And basically he was replacing all the pictures in the language packs with some advertisements. And that has been published into the Mozilla site and has been downloaded by people. So that's one way you can actually see the connection between malware and extension. And as Nick was saying last point, if there is a trusted application, let's say you have an extension which is used by millions of people, it's trusted. It doesn't go through the review process. But if the author gets owned or compromised of someone bribed the authors, then everyone can actually be owned by the update because it's not going to be reviewed. OK, and now Nick to go over this section. OK, so there's a lot of different ways to find bugs and Firefox extensions. Our approach was to basically start looking at use all the extension, click on everything, go to different websites that use its functionality, basically figure out what makes it tick. Look at the logic explos and the input and output vectors. So what is being input into the extension? What websites can it read in from? Things like that. Look at any XP common components that it might introduce. These might be code in C++, in which case it could possibly be vulnerable to memory correction vulnerabilities. And otherwise they can do some pretty dirty things themselves. And also look out for any third-party components or APIs. So there's a few sites like bookmarks and stored passwords where you can basically ship off your information somewhere else. But it doesn't always do this really well. Sometimes we've seen SQL injectable passwords, password fields. We've seen things going over HTTP or they'll basically foreign code it or something. It's all pretty bad. So keep an eye out for what's being seen out from your computer when you're looking at the extension. So our focus was basically looking on extension data flow and injection points and what we can do to basically cross-site script into the extension. So cross-site scripting into the Chrome privilege zone is real bad to you. Because it's an privileged zone, it can contact the XP-com components, which means that you can read from the file system. You can write to the file system. You can run processes. And there's no same origin policy there. So you can read from the file system and ship it off to an external website, which we will show you a little bit later on. And because this is all in the Chrome security zone, it can't be blocked by NoScript because it's in the same place. So if you look at this next little picture here, you can see Chrome is whitelisted. And cross-site scripting, often showing empty alert boxes or with one or hello world. This one's showing, et cetera, password. So just showing what the same origin policy, the lack of the same origin policy, is going to do. When you're testing for cross-site scripting in an extension, we recommend running a Firefox with minus console option and basically dumping out the result of your testing. So you can see in the two red boxes there, there's a window object, but it's in the Chrome URI. It can also just be a Chrome window. So don't rely on just one way to fight on one of those to see if you're in the Chrome zone or not. Here's a list of the ECS payloads that we ended up using. So there's actually a method there, provided by Mozilla, to sanely look after your input filtering, basically. We haven't seen it used once. People like rolling their own blacklist filters. So, ah, script tags are bad. Or angle brackets are real bad. We don't want any of that crap in there. So they'll block those. But then you can use an iframe, or you can use an image with an onload tag, or all sorts of other crazy things. So yeah, most developers just adopt the blacklist thing. And we can see when people have tried to fix some of the things we've disclosed to them, you just see extra script, iframe, image tags inside an extra four lines of code. They don't do it right. Here's a bunch of tools that we used for our testing. So Moz REPL is real good. It basically creates a JavaScript shell. So you can tell it into your browser and execute JavaScript in the Chrome zone. It also lets you export the DOM. So you can, if you build a Python script, you can export the DOM before and after enabling an extension and see what functions it brings into your browser. And also, BIRPL, another web proxy, just to see what the extension is sending out when you're using it. Cool. OK. Thanks, Nick. So we just saw multiple ways to find bugs across the system in extensions. Now let's have a look what we have found during our research. Yeah, we can disclose everything because we follow responsible disclosure, and we are just waiting some extensions to fix their bugs. But we're going to show you six extensions, vulnerable. Three of them which haven't been disclosed before. And as you can see there with the new label there. And basically, if we sum all the downloads for all the extensions we got, that's more than 30 millions. We've wrote 50 millions on the book you have on the schedule book. But that was a couple of months ago, I guess. So that's increasing the meantime. And yeah, let's start with Skype, which is one extension. When you install Skype, you get five extensions. Well, you have the choice to install it. And that was a funny bug because it's a logical floor bug. And in particular, there is a function there which is called Skype tool call function. And that is responsible for making basically the call. And I don't know if you're familiar with Skype, but if you have a phone number in an HTML page, you would see a little green button appearing. And then you can click. And then Skype would be launched by your Firefox. And that's where it's the bug. Basically, the function which is responsible for calling Skype, it's available. So you can go to any page. And JavaScript can launch that function. Well, actually, it can trigger that function. And Skype would be actually launched. Yeah, the white thing, that's the payload to do this trick. So you force the user to go to that page. There is a telephone number. And then the extension will be loaded. And then there is a document location which is doing a JavaScript URI to Skype tool call. And then you can put any phone numbers there. So basically, you force the user to call the phone numbers you want. And you can put as many phone numbers you actually desire. I'll show you a quick demo on video, which I've done here. Just a moment. Yep. I'm not sure if you can do it like that. That's easy. I was showing it. Here it is. So that's my malicious page. That's the telephone number. As long as the user goes to that page without clicking, Skype is going to be launched. Automatically, it's going to make all these phone calls. So imagine that if you call paid numbers where you have to pay, so you will lose credits or you will lose money, basically, because Skype is going to do automatically that. And the thing is that it doesn't close. So till you close the browser, the Skype one disappear, it will try to reopen and call till basically does the call. So that's why we didn't do a real demo, because it will take some time to close it down. OK, next one. OK, next extension. It's cool previews. I don't know if you heard about this one. It's almost $7 million now. It's recommended by AMO. And yeah, it's a nice extension. So you have a web page, any link. You go with a mouse over the link. It's going to show you a little pop-up window. It's going to preview the contents of that link. And the problem is when you basically, you can have a far worse list of sites you can control through this extension. And that's why it's the vulnerability. It's the add to stack function. And I just forgot that for each extension we're going to show you today, it's going to be a different exploit. In this case, I'm going to show you a remote code execution through cool previews. And I just need to put a demo here. Just a moment. Yeah. Yeah, so I got the demo working now. Just before showing the demo, I want to show you the exploit. So as I said before, you can use JavaScript to call XP components. In this case, I'm using the NIS local file, NIS process to call win.com. And win.com will call cmdx. And then we'll actually will pop up cmdx shell. And that's an example of using JavaScript to interface with the xp.com component and execute and have code execution. I can't see. What is it? Yeah. We need to make that. Go up. Yeah, sorry, we're struggling with the. Yeah, that's good. OK, thanks Nick. So that's a vulnerable page targeting cool previews. So when you add that side to your add to stack list of failure site, that's where it's about. And you can have the cross-escape into a data you write. You pass a data you write in the link and that will be executed within the Chrome window of cool previews. And that's why you can actually have code execution. So I just click here. Adjust for the demo, showing where it's the file path of win.com. And that's popping shell through just that. Where's the presentation? OK, the next one is update scanner. That's new. We didn't disclose this yet. And still a cool extension that allows you to put a list of sites. Whenever there's a change on one of these sites, then update scanner will tell you that something has changed and will notify you. The problem is that the change page is going to be shown in Chrome window. So if you're able to put any injection there, that will be rendering Chrome in the update scanner window. There is some protection there. So the developer was trying to do something, blocking script tags. So if you have any script tags, which is part of the payload change, that won't be executed. But still, if you put a picture there and you cross-execute it through an event handler like onError, that will be executed. And again, you can have any JavaScript executing Chrome as a privileged code. And today I want to show you how to compromise no script through just any vulnerability in this extension. That's just one example. That's few lines required to do that. The script we call the getService, which is basically calling your browser. It's about config. It's the configuration of your Firefox browser. And it's going to take the branch which is related to no script, and it's going to have my site into the white list of no script. So that's at the same point where an extension can actually modify another extension. Or a vulnerability of an extension can be exploited to modify another extension. Let me clean the cache. So that's the update scanner window. We have the site there. This is the page, which has been detected now. So now I'm going to go to the server side, do a change of this page, then re-scan the website, and have my injection as well with the new change. Just running this quick script. It's basically doing a CP, copy, and do a change on that page. And then I will come back to update scanner and then do the scan. Hopefully it should detect the change. OK, yes. So that's the change. But something else has been changed here. And as you can see, no script here has been changed before it was forbidden. And this page was forbidden before, and now you can have JavaScript execution. And just to give you another proof, if you go here, that's the site which has been added through the injection. OK, cool. Now I'll leave Nick to this one because he found it. All right, so FireFTP, about 10 million downloads, again recommended by the Missile community. In this case, any HTML JavaScript in the welcome message for the FTP server would be executed in the little log area at the bottom of the extension. And that was in the Chrome zone. So if you had some cross-site scripting in your welcome message, you get owned. So there's no filtering protection here for this one. So script tags, iframes, anything, go for gold. The exploit here is local file disclosure. So to do this one, basically reading the file into an iframe, and then sending it off to, using document location, to send off as a HTTP parameter to my website. And thing to note down there in the bottom is the set timeout. You need to give a little bit of time to let the data be read into the iframe. Otherwise, it won't send anything. We spent a few hours trying to figure that one out. OK, get some demo action. Just going to tail my Apache logs. So we're pre-defined the site there. I'm just going to connect to it. And here's the welcome message. And we're going to have a load box showing the contents of the file. So in this case, it's not a set of password because we're using boot.ini. So all right, it's there. And if we hop along to Linux machine, yeah. So now the boot.ini is on someone else's server. And it works real well for directory reading as well. So you can browse the entire person's hard drive through this. Next up is feed sidebar. Another recommended one by AMO. About 680,000 downloads. In this case, any JavaScript or HTML in the description tags of an RSS feed will be rendered in the Chrome context. The guy who wrote this decided that script tags were a real bad idea. So those were stripped out. So we used an iframe. And base64 encoded the payload. In this case, we're going to steal passwords. So we're going to use the nsi-login-manager, xb-com-component, and the getall-logins function. And then basically pull out the host name, the username, and the password, and send those as HTTP parameters to my website again. Sorry. Oh yeah, this one keeps on running. OK, so here's feed sidebar. Reload my feed. Going to click on the item. Here's a little no scripts disabled. I forgot. The reason that shows up five times is because it's sending to my site five times. It does work with no script enabled for the site as well. If we hop along to the other one, you can see here we've got a Google password, a Facebook password, the username and the password, eBay, and actually the FTP server as well, which we just used. So yeah, sending your passwords away somewhere else. And last but not least, we've got scribefire. This is a blogging extension. About 2.5 million downloads, again recommended. So all the ones that we're showing you today are recommended by Mozilla. In this case, any JavaScript in DOM event handlers, so like onload or on erotags and images, would be passed in the Chrome zone. So we just used an image with some nasty JavaScripts in there. And in this case, we're going to send a reverse VNC shell using an XML HTTP request to download the binary. So the important thing to note is in that first box is to use override MIME type to X user defined, because otherwise it downloads in UDF7 and your binary doesn't work. So yeah, use UDF8, and you can see where you want to download the file to and run 777 permissions. What isn't included up there is the remote code execution thing, but we're going to show you that like a few slides ago, so I'm sure we can put it together. OK, demo time. OK, so I'm just going to launch the payload handler there. It's just using the minisploit reverse VNC handler. Away. Make sure this thing is fiddled. Scribe fire. All right. So I'm going to load up Scribe Fire. And essentially dragging and dropping it into here is going to execute an onload tag. Yeah, I'll show you the code for it in a second. So grab it there, and oh, there's an hourglass. Something's happening. If you look here, it's downloaded these winzip.exe's. And if you hop along to the other one, to the Linux box, we've got a VNC shell. And if you just have a, I'll just show you the, so you can see it's just in the onload there. It just has all of this JavaScript, which calls xbcon components and does all the good work. Yeah. OK, and that's it for our demos today. So security disclosure is a pretty new process to extension developers and vendors. It's not really understood by them. It's all fairly new. Aren't really many posts about on full disclosure or anything like that. And we have talked to Mozilla, and they've said that there is a place to actually securely lodge bugs in extensions, because previously we couldn't find where you put the secure flag. And some places don't publish contact details for themselves. So if you find a bug in it, you don't have a way to contact them. You have to go through their online help desk thing and ask them to contact you privately or whatever. Pain in the arse. So we've got a few recommendations for developers of extensions. Follow the OWAS developers guide and look at code of similar extensions for avoiding common bugs. But read it and don't use it blindly. For dirty hacksaws and security professionals, use the OWAS testing guide and our presentation when you test them. And look for any publications to be released. We're working on a strong methodology for this, which will be published in a while. And for end users, don't trust extensions. No scripts are right that we can compromise it. If you're going to use an extension, look for the change log of security issues or the bugs of the history. If it has six security issues in the last year or something, you probably don't want to install it. And if you're updating ALONS, again, check all of the change logs. And consider using Safe Mode, which is basically disabled extensions or links. That's about it for us, I think.