On Evaluating and Securing Firefox for Android Browser Extensions Josh Marston
Komminist Weldemariam
Mohammad Zulkernine
School of Computing Queen’s University Kingston ON, Canada
IBM Research | Africa Langata Road Nairobi 00100, Kenya
School of Computing Queen’s University Kingston ON, Canada
[email protected]
[email protected]
[email protected]
ABSTRACT
1.
Unsafely or maliciously coded extensions allow an attacker to run their own code in the victim’s browser with elevated privileges. This gives the attacker a large amount of control over not only the browser but the underlying machine as well. The topic of securing desktop browsers from such threats has been well studied but mitigating the same danger on mobile devices has seen little attention. Similarly, mobile device use continues to grow world-wide at a rapid pace along with their capability and ability to perform sensitive actions. In an effort to mitigate the risks inherent with these actions, this paper details the dangers of JavaScript injection on the mobile browser. We further present a defense technique that was developed by extending from the desktop environment to work in the mobile space. Our prototype implementation is a combination of extensions on the Firefox for Android and a slightly modified browser of Firefox for Android. When the user attempts to install a new extension or update an existing one, the modified browser is called a priori. The overall extension logic, code transformation, and static analyzer components were implemented in JavaScript and SQLLite database. Our preliminary evaluation shows that our prototype implementation can effectively prevent real-world attacks against extensions on Firefox for Android without affecting users’ browsing experience.
JavaScript has become the language of choice for the logic that drives web browser extensions. Web browser extensions enhance the underlying capabilities of the browser itself. For example, the LastPass Password Manager extension [10] allows a user with an account to not only store all of their passwords in one place but offers secure password generation and automatic online form filling as well. Another popular extension, NoScript [14], automatically blocks JavaScript from executing in a user’s browser unless it is given explicit permission to do so. This allows a user to block malicious or unknown origins from executing code while allowing known origins to execute freely. The Android platform consists of an OS, middleware, and basic applications for mobile devices [2]. It has proven to be a popular choice among users with Android taking over almost 80% of the global market share for smartphone shipments in the 2013 fiscal year [29]. It is also estimated that by the end of 2018 there will be more than 1 billion just employed-owned mobile devices [13]. This large install base has made Android a target for malicious actors [30, 41]. The dangers posed by malicious attacks against mobile devices is growing, along with the power and adoption of mobile devices themselves. For example, for the first quarter of 2013 the McAfee threat report found that mobile malware grew by 30% and almost all of it targeted Android [31, 33]. A manual analysis of malware samples in [41] revealed that 36.7% leverage root-level exploits, 90% turn devices into bots, 45.3% dial/text premium numbers in background, and 51.1% harvest user information. This is because vulnerabilities exist in every layer of the Android OS from the applications and framework down to the kernel layer. The Android security policy extends from the application level down to the kernel level, with user data and interprocess communication closely guarded and application signatures for applications hosted in the Play Store [3]. This means, for example, that users must explicitly grant permission to install an application from a non Google source or to let an application access their call history. This is accomplished by running each application in a sandbox that prevents it from accessing data outside of the sandbox or any of the underlying phone hardware. In order for applications to perform actions outside of their sandboxed environment the permission to perform that action must be granted at install time. These install time permissions are explicitly declared by an application author in the Android manifest file. This list is then presented to the user at install time to be accepted or rejected. If the
Categories and Subject Descriptors D.4.6 [Operating Systems]: Security and Protection
General Terms Security
Keywords Mobile Security; Firefox for Android; Browser Extensions; Information Flow; Static Analysis; JavaScript.
Permission to make digital or hard copies of all or part of this work for personal or classroom usetois make granteddigital withoutorfeehard provided thatofcopies not made or work distributed Permission copies all orarepart of this for for profit or commercial advantage and that copies bear this notice and the full citation personal or classroom use is granted without fee provided that copies are on the first page. Copyrights for components of this work owned by others than ACM not made or distributed forwith profit or iscommercial and that copies must be honored. Abstracting credit permitted. Toadvantage copy otherwise, or republish, to postthis on notice servers and or tothe redistribute to lists, specific permission and/ortoa bear full citation onrequires the firstprior page. To copy otherwise, fee. Requesttopermissions from
[email protected]. republish, post on servers or to redistribute to lists, requires prior specific
permission and/orJune a fee. MOBILESoft’14, 2–3, 2014, Hyderabad, India ˘ S3, MOBILESoft ’14, June978-1-4503-2878-4/14/06...$15.00 2âA ¸ 2014, Hyderabad, India Copyright 2014 ACM http://dx.doi.org/10.1145/2593902.2593909 Copyright 2014 ACM 978-1-4503-2878-4/14/06 ...$15.00.
27
INTRODUCTION
permissions are rejected then the application is not installed. Otherwise, the application is granted every permission listed and installed on the device. An application’s permission list is therefore a good way to gauge an author’s intent versus the advertised intent. By defining an application’s capabilities, it also provides the capabilities of an attacker, should they subvert the application. As noted above, the dangers posed by malicious attacks against mobile devices is growing, along with the power and adoption of mobile devices themselves. Almost all websites that expect to attract and keep users coming back have implemented a version of their website tailored for mobile devices. JavaScript is a major enabling factor for these initiatives. The mobile browsers in turn need to support JavaScript and for a large part they do. This paper defines what exactly are the dangers posed by browser extensions in the mobile space and the efficacy of already used desktop techniques to mitigate them. In particular, the Firefox for Android browser is selected due to its open source nature —allowing source code examination and many instances of prior work to refer to. The browser of Firefox for Android also offers the unique chance to compare and contrast the dangers posed by malicious JavaScript injection to a browser’s desktop and mobile versions. Other mobile browsers (such as Chrome and Safari) disable extension functionality completely. While this design decision removes the danger posed by privileged script injection, this choice limits the user experience and developer options when designing for mobile devices. Software providers who have created extensions for desktop browsers are forced to create entirely separate applications on mobile devices if they wish to provide the same functionality to their mobile users. The contribution of this paper can be summarized as follows: i) We defined the Android security permissions that Firefox for Android requests on installation. These permissions put a hard limit on what the browser extensions can and cannot do. It was found that many permissions are requested which in turn can allow an extension to perform dangerous actions. These actions were formalized into an extension that clearly demonstrated each action. ii) We experimentally validated existing injection attacks on mobile browser extensions. With the ability of malicious actors established, an extension was created that contained common JavaScript vulnerabilities that would enable those abilities to be exercised, consequently, underscoring the need for a defense against them. iii) We developed a tool to defend those injection attacks by adapting from the desktop to mobile environment. We also evaluated our tool using real-world extension’s samples. Section 2 provides a brief overview of the Android OS permission system and examples of vulnerabilities and attacks that target extensions. In Section 3, we present the motivation for this work by detailing vulnerable and malicious extensions we created and found in the wild. Section 4 presents our proposed approach to defend extensions on Firefox for Android against vulnerable and malicious extensions. While Section 5 discusses the related work on desktop and mobile extensions security, conclusion and future work are discussed in Section 6.
Table 1: Selected Firefox for Android Permissions. android.permission.ACCESS_FINE_LOCATION org.mozilla.firefox_sync.permission.PER_ACCOUNT_TYPE android.permission.ACCESS_NETWORK_STATE org.mozilla.firefox.permissions.BROWSER_PROVIDER android.hardware.camera org.mozilla.firefox.permissions.FORMHISTORY_PROVIDER android.hardware.camera.autofocus org.mozilla.firefox.permissions.PASSWORD_PROVIDER android.hardware.location android.permission.READ_SYNC_STATS android.hardware.location.gps android.permission.RECEIVE_BOOT_COMPLETED android.hardware.touchscreen android.permission.USE_CREDENTIALS android.permission.AUTHENTICATE_ACCOUNTS android.permission.VIBRATE android.permission.CAMERA android.permission.WAKE_LOCK com.android.browser.permission.READ_HISTORY_BOOKMARKS android.permission.WRITE_EXTERNAL_STORAGE com.android.launcher.permission.INSTALL_SHORTCUT android.permission.WRITE_SETTINGS com.android.launcher.permission.UNINSTALL_SHORTCUT android.permission.WRITE_SYNC_SETTINGS android.permission.GET_ACCOUNTS android.permission.READ_EXTERNAL_STORAGE android.permission.INTERNET android.permission.READ_PHONE_STATE android.permission.MANAGE_ACCOUNTS
2.
BACKGROUND
Firefox for Android is the Mozilla foundation’s mobile version of its popular Firefox browser for desktop. As a browser, it needs a lot of permissions in order to support the features users expect. For example, it requests permission to access the internet, browser history, and the ability to save files to the device. Version 21 of the Firefox for Android browser lists a total number of 31 API and device permissions. Table 1 shows selected Firefox permissions (e.g., android.permission.ACCESS_ FINE_LOCATION, org.mozilla.firefox_sync.permission.PER_ACCOUNT_TYPE). Browser extensions can modify the appearance and functionality of the browser. On the desktop, browser extensions can consist of XUL, CSS, HTML, and JavaScript files [5]. Mobile Firefox extensions are restricted to CSS, HTML, and JavaScript, as Mozilla elected to remove XUL support on mobile browsers and instead provided access to the native Android UI [9]. These technologies allow extension developers to create relatively simple to extremely complex extensions. On both platforms the extra functionality provided by extensions has proven very popular with users. The most popular desktop extension, Adblock Plus, has over 11 million Windows users and over 200 thousand Android users as of August 22, 2013 [15]. Furthermore, Mozilla reports that 85% of Firefox users have at least one add-on installed and that on average Firefox users have 5 add-ons installed [36]. Permissions give insight into the application’s purpose and abilities. The browser can import bookmarks from the Android device (via com.android.browser.permission.READ_H ISTORY _BOOKMARKS) and has access to the SD card (via android.permiss ion.READ/ WRITE_EXTERNAL_STORAGE). Of especial interest are the permissions that give access to a few the unique features of a mobile device, the GPS and camera. The android. permission.ACCESS _FINE_LOCATION permission allows the browser to request the current GPS coordinates of the device. Camera access is granted via the android.permission.CAMERA permission. These permissions not only allow web site developers to create more functional-
28
ity for users of Firefox for Android but also allows extension developers to utilize these functions as well. The password manager program, LastPass [10], offers an extension for desktop Firefox which allows for automatic form filling and context sensitive secure password generation while browsing. Since most mobile browsers do not support extensions, LastPass has created its own separate mobile application to offer the same functionality to its mobile users. If a user wishes to browse with mobile Chrome and needs a password from the extension, s/he must manually copy and paste their information from this application into the login window of Chrome. This is a very laborious process compared to the automatic method offered by the extension. Firefox for Android on the other hand supports the LastPass mobile extension so that the mobile browsing experience is both convenient and secure (in a unique password sense at any rate). To support the broad range of features needed by extensions, Firefox allows the JavaScript powering extensions to interact with any object in the browser and allows it access to the powerful XPCOM interfaces [32]. Interfaces defined in XPCOM can work across platforms so that developers do not have to worry about a given user’s underlying hardware as long as the user can run a Mozilla application. These interfaces expose a lot of functionality of the underlying hardware from local file access to HTTP request creation. The combination of full access to a given web session, through the relaxing of the Same Origin Policy (SOP), and platform agnostic hardware functions, give extension developers the ability to grant users a host of powerful features to enhance their browsing experience. This also provides malicious users a powerful attack vector. Mozilla maintains an official extension repository where it offers extension developers a centralized place to advertise their software (see [1]). This gives users a safe place to obtain extensions as Mozilla reviews every extension that is submitted. This process is not perfect however and Mozilla’s own blocked extension list underlines that fact [4]. While many extensions are rejected due to violations of the AddOn Guidelines which tend to not be malicious in nature, the extensions labeled explicitly “malware” contain dangerous functionality. For example, the “Social Networks” extension utilizes code from the popular Greasemonkey extension to monitor a user’s web session [12]. When the user opens a Facebook session, the extension highjacks their web session in order to spam Facebook “likes” to hard coded groups. It also reports the results of these activities and identifying information to remotely located malicious server.
For instance, Listing 1 shows a piece of code that relies heavily on the XPCOM interface XMLHttpRequest to create the HTTP request with the user’s information. Earlier in the code it obtains one of the user’s unique Facebook id’s (user id) by searching the browser’s cookies. Another malicious extension Video Player 2013 also hijacks a user’s Facebook session [11]. On top of spamming a user’s Facebook page with attempts to spread itself to others, it also modifies the user’s preferences to store its settings in a preference branch called adobeflashplayer. In this way, it attempts to hide its previous actions by pretending to be affiliated with a legitimate piece of software. A sample of this preference logic is shown in Listing 2. It should be noted that these actions are not possible without the elevated privileges that executing in the extension context provides. Moreover, many permissions have been requested allow an extension to perform malicious actions.
// l i n e s removed f o r b r e v i t y v a r xmlhttp = new XMLHttpRequest ( ) ; xmlhttp . o n r e a d y s t a t e c h a n g e = f u n c t i o n ( ) { v a r params = ‘ ‘ c h a r s e t t e s t= , ’ , , ’ , ? , ? , ? ’ ’ ; params += ”&f b d t s g=” + document . getElementsByName ( ’ f b d t s g ’ ) . v a l u e ; params += ”& u s e r=” + u s e r i d ; xmlhttp . open ( ‘ ‘POST ’ ’ , ‘ ‘ / a j a x / u f i / modify . php ? a =1 ’ ’ , true ) ; xmlhttp . s e t R e q u e s t H e a d e r ( ‘ ‘ Content−Type ’ ’ , ‘ ‘ a p p l i c a t i o n /x−www−form−u r l e n c o d e d ’ ’ ) ; xmlhttp . send ( params ) ; }
In this section, we present the mobile extensions created and the testing environments used for validating the danger of vulnerable and malicious extensions on a mobile device.
function adobeflashplayer PrefManager () { v a r s t a r t P o i n t=” a d o b e f l a s h p l a y e r . ” ; v a r p r e f=Components . c l a s s e s [ ”@ m o z i l l a . o r g / p r e f e r e n c e s −s e r v i c e ; 1 ” ] . g e t S e r v i c e ( Components . i n t e r f a c e s . n s I P r e f S e r v i c e ) . getBranch ( s t a r t P o i n t ) ; //Code o m i t t e d f o r b r e v i t y
Listing 2: The Adobe Flash Player preference branch. Code from the “Video Player 2013” malicious extension that gets a preference branch. The Firefox for Android extension environment provides the same access to XPCOM and relents the restrictions of the SOP just like the desktop environment. This has cleared the path for a vibrant mobile extension environment but also for the same dangers that affect the desktop browser to affect the mobile browser. The next section (Section 3) details some of these dangers and how they could be used in an attack. There are no techniques to mitigate the dangers posed to the mobile browser at this time. Many solutions have been proposed for the desktop environment (e.g., [22, 25, 26, 35]) with varying degrees of success and could theoretically be applied to the mobile browser. However, any solution implemented needs to adhere to the unique resource constraints of mobile devices: less CPU power than available on desktop machines, limited battery life, and smaller screen size to name a few.
3.
3.1
VULNERABLE AND MALICIOUS EXTENSIONS ON MOBILE BROWSER
Overview
We developed a number of vulnerable and malicious extensions for Firefox for Android. The vulnerable extension was created to demonstrate how a legitimate extension might be compromised by an attacker. For the malicious extensions, the design goals are twofolds: (i) to probe the functions available to the extension and to compare these abilities to the functions available to their desktop counterparts, and (ii) to check for dangers that are unique to mobile devices. The mobile extensions created are what as known as “restartless” due to the fact that they can be installed in the browser
Listing 1: An extension that sends user information to a malicious server.
29
ibility to do things like take user input or other after initial run time factors into account for code execution, it also provides a clear opportunity for malicious subversion. The second extension and a specially crafted website was made to demonstrate this vulnerability.
Table 2: Functions attempting to access the functionality they were trying to use. Function
Ability
takePicture
Take a picture using the device’s camera
passwordSlurper
access Firefox’s password manager
modifyPreference
modify the browser’s
launchProgram
launch programs
writeToSDCard
write to SD card
readAndLogFineLocation
access the current GPS coordinates
f u n c t i o n e v a l V u l n e r a b i l i t y ( window ) { v a r tab = window . BrowserApp . s e l e c t e d T a b ; window . c o n s o l e . l o g ( ”VulnerableApp@JoshMarston . o r g : Eval v u l n e r a b i l i t y ” ) ; v a r s c r i p t = tab . window . document . getElementsByTagName ( ” s c r i p t ” ) [ 0 ] . innerHTML ; eval ( script ) ; }
Listing 3: The vulnerable function.
readAndLogDownloadedApps access certain sys level folders logHTTPRequest
extension’s
Listing 3 shows the vulnerable code. The vulnerability lies in Lines 5 and 6. In Line 5, the web page’s DOM is queried for the first script element on a web page. The HTML element is used to define scripts that will be executed on the client-side. When a web page is loaded all code in the elements is automatically executed. This code executes with restricted privileges as noted earlier. These restrictions would normally protect a user visiting a page with malicious JavaScript but this function would allow that same code to execute normally. This vulnerability seems obvious however it was modeled after a real vulnerability found in the official Wikipedia Firefox extension Versions 0.5.7 and 0.5.9 [34]. Another avenue for injection attack is posed by the JS protocol. This protocol allows developers to specify JavaScript to be executed when opening a new browser tab or session. An extension opening new windows or tabs based on user input or DOM information needs to take care to clean it before opening the new artifact. For example, an extension could find an the href tag on an
element to open a new page. This href tag could be coded as follows: aLink Opening a new window with that href tag would cause the maliciousCode to be executed and subvert the SOP. This attack is further complicated by protocol nesting —that is, the line “view-source:javascript:” also needs to be protected against. Extension authors do not just need to worry about opening explicit vectors for attackers but also the implicit ones sometimes left open by JavaScript itself. As detailed in [26], in Firefox 1.0 until Firefox 3.0 a combination of JavaScript definition flexibility and another compilation function posed a significant security risk. Listing 4 shows sample exploit code for this vulnerability.
open and listen for HTTP connections preferences
while the browser is running and then used immediately. This is due to the fact that Mozilla has reimplemented support for the native Android UI [7]. This means that “restartless” extensions do not need to use XUL files and can be implemented with as few as two files. The first is the install manifest file which defines metadata about the extension for the Firefox installer. The second is the bootstrap.js file which contains startup and shutdown functions needed by the installer. This file can also be used to implement extension logic and to define the extension UI. The extensions are entirely implemented using bootstrap.js file so that the two extension types (i.e., vulnerable and malicious) consist of install.rdf and bootstrap.js files. We tested the extensions using emulated devices and a physical device. The emulations were created using the Android Developer Tools [6] and the latest Android platform available (at the time of creation Version 4.3). Both phones and tablet devices were emulated. A single physical device was also used for testing which was running Android Version 2.3.3. All devices used the latest version of Firefox for Android (Version 22 at the time of testing).
3.2
VulnerableApp
Validating Vulnerable Extensions on Firefox for Mobile Browser
A vulnerable extension is an extension that is not inherently malicious but is vulnerable to attack. Since extensions are distributed with their source code still in a human readable form, they must take great care to not practice unsafe coding practices. Code obfuscation practices can provide some protection in this regard. Even with such a protection in place, they only delay the inevitable discovery by a determined attacker. It is worthwhile to note what currently known coding practices are unsafe and what vulnerabilities existed in past versions of Firefox. The first point of demonstrating unsafe coding practices in extensions was demonstrated with the extensions that were developed. One of the most common vectors for JavaScript injection attacks is to supply malicious code to an eval() or “eval-like” extension. Both kinds of functions allows the compilation and execution of JavaScript code that is not known at run time. While this allows a developer the flex-
f u n c t i o n m a l i c i o u s G e t ( window ) { v a r m a l i c i o u s C o d e = ‘ ‘ m a l i c i o u s code ’ ’ ; window . document . body . d e f i n e G e t t e r ( ‘ ‘ tagName ’ ’ , S c r i p t ( maliciousCode ) ) ; }
Listing 4: Firefox.
An early JavaScript vulnerability for
The vulnerability lies in Lines 3 and 4. In particular, in Line 3 a malicious piece of code is defined. In Line 4, instead a new get function is declared for the body of the web page that uses an early compilation and execution function called Script. When an extension attempted to access
30
the window.document.body.tagName property, it executed the the Script function with elevated privileges. In Firefox 3.0, the Script function was deprecated and safety wrappers were implemented so that privileged code can work with DOM properties without accessing any modifications made by page scripts.
3.3
Table 3: Comparison results: P and X indicate partial and completely present on platform, respectively. Threat Direct DOM Access Browser Component Access Arbitrary File Access Network Access Launching Process Dynamic Code Execution Listening to input Events Indirect threats to web sessions
Validating Malicious Extension on Firefox for Mobile Browser
The malicious extension implemented several functions in order to demonstrate the use of various permissions the Firefox for Android browser is granted at install time. These permissions put a hard limit on what the browser extensions can and cannot do. It was found that many permissions are requested which in turn allowed an extension to perform many dangerous actions. These actions were formalized into an extension that clearly demonstrated each action. These functions can be used in combination to steal a user’s private information, open HTTP connections, and can open files on behalf of the browser. These actions are available to the extension through the XPCOM interface. Due to the haphazard nature of development for the XPCOM interfaces, their functionality is not necessarily guaranteed on a given platform. This means that these extensions also test the current functionality for these interfaces on Android devices. Table 2 summarizes the functions that were successful in their attempts to access the functionality they were trying to use. Other functions were implemented but failed to access the functionality they were designed to obtain. In some of these instances, the Android security policy worked as intended by blocking access to the resource and some of them had the required API but not the required permission (contactSlurper, monitorPhoneCalls, and sendSMS).
3.4
X X X X X X X X
X X P X X X X X
Table 4: Comparison results: F and X indicate a possible future vulnerability and present on Android platform, respectively. Threat
Android Android App OS
Battery drain (Resource DOS) Camera/Voice Misuse of phone ID’s Exposure of Physical location Abuse of Telephony Services Eavesdropping audio/video Botnet characteristics Harvesting installed applications
X X X X X X X X
X X F X F X X X
system. For example, in our experiment, mobile extensions have “read” access to the //proc/net folder allowing them to read virtual files that hold a wealth of metadata of the device’s current network connection.
Comparison
3.4.2
In what follows, we discuss our experimental findings to confirm the possibility of dangerous extensions on mobile platform.
3.4.1
Desktop Mobile
Malicious Android App & Mobile Browser Extension
Along with sharing dangerous characteristics with extensions on the desktop browser, mobile extensions by virtue of operating in a mobile environment have access to the unique functionality of mobile platforms. With this added functionality comes more opportunities for misuse and abuse. We compared the dangerous functionality available to Android applications with the functionality available to extensions on Firefox for Android (see Table 4). We found that mobile extensions were able to access most of the dangerous functionality unique to the Android mobile platform. An attacker that gains access to a mobile device is presented with more opportunities to invade the personal live’s of their victims than one who attacks a desktop device.
Malicious Mobile and Desktop Browser Extension
As described in detail in the previous section, the mobile malicious extension implemented several “dangerous” functions. Dangerous functions are functions that access critical system resources or have the ability to manipulate a user’s browser session. This list of functionality was based on Firefox specific dangers and Android specific dangers as discussed in [39] and [24], respectively. Table 3 shows the comparison of the dangerous functionality available to desktop extensions with the functionality available to Firefox for Android extensions. As shown in Table 3, mobile extensions share all of the dangerous behaviors that desktop extensions exhibit, saving arbitrary access to the entire mobile file system. We also found that mobile extensions could read a good deal of the system but that the Android security policy prevents extensions from accessing the file system in its entirety. With respect to the file system access, desktop extensions proved to be more dangerous than their mobile counterparts, as they are bestowed access to all the files a browser is while mobile extensions are restricted by the security policy. The safeguard provided by the security policy only goes so far as mobile extensions still have access to a good deal of the file
New/Updated Extension
Static Taint Analyzer
Sensitive Info Manager User Decision to Install
Repackager
XPInstall
Code Transformer
Figure 1: Overview of our tool from the user’s perspective.
31
For example, extensions were found to be able to poll the GPS at regular intervals which can paint a detailed map of a user’s daily life [40]. The camera was also found to be accessible with the aid of a specially crafted website. Notice however that not all dangerous functionality that was tested for was accessible to the extension. For example, we confirmed that mobile extensions cannot send and receive SMS messages. As detailed before, this was due to a combination of Android security policy and the current lack of suitable API’s. While the security policy remains a reliable safeguard, Firefox for Android does not request the required permission — the lack of APIs to the functionality only awaits the API’s implementation. An especially determined attacker could even provide their own. Furthermore, while the APIs do not exist on the Android platform they do exist in the Firefox OS [16, 17]. This means that potentially Firefox OS devices could support more dangerous extensions than Android platforms do. In summary, we confirmed that extensions on the Firefox for Android browser have access to more dangerous functionality than (desktop) Firefox extensions and most Android applications. This is due to two factors. The first being that the Firefox for Android application requests several high risk permissions on the Android platform. These are needed in order for the browser to function. The second factor is the heightened functionality and relaxing of the SOP for the JavaScript code that runs extensions. Effectively, extensions on mobile platform (in this case, on Android platform through extensions of Firefox for Android ) are given full access to a user’s browsing session and a lot of underlying functionality of the device itself. The dangers are obvious when an extension is designed to be malicious but are still present in extensions that are vulnerable to attack.
4.
analysis tool report. More specifically, if the static analysis reports any dangerous functionality, the second component transforms potentially dangerous code in the extension into an equivalent and safer form. In this way, the tool protects legitimate extensions that contain vulnerable functionality. The third component will present the user with the option to “fake” sensitive information if an extension contains suspicious information flows. This fake information will be sent to the extension every time it attempts to access it. For example, an extension that requires location data to function could be supplied with a false location thereby enabling functionality and protecting the user’s privacy. Once the extension has been transformed it is repackaged and handed over to the normal Firefox for Android installation process.
4.2
SECURING EXTENSIONS ON FIREFOX FOR ANDROID PLATFORM
This section describes our proposed protection package for the Firefox for Android extension framework from JavaScript injection attacks. Our approach is inspired by code transformation and static analysis approaches adapted from the desktop environment.
4.1
Static Taint Analysis
This component performs static information flow analysis on the JavaScript code found in an extension. After intercepting the xpi file from the XPInstall process, this component decompresses and extracts the JavaScript files from it. The tool then scans the files for requests to download JavaScript files. Malware authors seeking to sneak their malware into the official Firefox repository often places explicitly malicious code outside of the extension. The extension can then pass inspection and be placed in the official repository. To protect against this, any requests to download JavaScript files are downloaded for inspection. All of the JavaScript files are analyzed one by one by constructing an information flow graph for each file, such as the graphs generated by the dfatool [8], for eval-like functions (dynamical code generation functions), and for requests for sensitive data. The information flow graphs are analyzed for suspicious source to sink flows. Sensitive sources are hardware or browser resources that could contain user information that they would like to be protected. Potentially, malicious sources and sinks are hardware or browser resources that could be used to obtain unsafe code or send sensitive information to a location of an attacker’s choosing. Any suspicious activity identified is summarized for the user, along with options to see technical details on the flows discovered and whether or not to continue installation. The summary is for less technically inclined users who may not understand the danger presented by an extension, e.g., accessing their password manager and sending their logins out to the Internet via an XMLHTTPRequest object. The technical details are meant for more technically adept users and extension authors to understand why the activity was flagged as suspicious. The option to whether or not to continue installation gives users a chance to stop the installation of an extension that has functionality they are not comfortable with.
System Overview
Our tool consists of three components: static taint analysis, code transformation, and sensitive information manager. As can be seen in Figure 1, the tool runs immediately before the normal Mozilla Cross Platform Installer process (XPInstall) [18]. By integrating into the normal installation process, the tool can intercept both new extension installations and updates to old extensions. The static analysis component checks the extension for suspicious information flows from sensitive sources to potentially malicious sinks and for any “benign-but-vulnerable” functions. It reports any suspicious activity to the user in both a layperson friendly summary and a more in depth technical report. It then presents the user with a choice of whether or not to continue with the installation. Keeping with the overall Android security policy, the user can then decide whether or not to continue installing the extension. If suspicious activities are found and the user elects to install the extension despite the warnings, the second and third components are given the extension code and the static
4.3
Code Transformation
If the user elects to install an extension that has been found to have dangerous functionality, the code transformation component will be used. This component deals with the dangers presented by the eval() function and other evallike functions. As mentioned previously, these functions ˘ are a potential avenue for code injection attacks. a ˆAIJThis danger will be mitigated by replacing direct calls to the eval functions by wrapping them with a call to Mozilla’s evanInSandbox() function. This function offers the same
32
code compilation and execution benefits that eval-like functions do but executes them in a developer specified sandbox. In this way, code can still be run from potentially dangerous sources but that code cannot execute with elevated privileges. The entire functions are wrapped rather than just the code they are attempting to compile because some of the eval-like functions offer functionality not present in the evanInSandbox function. The setInterval function, for example, executes a piece of code over and over at set time intervals. Thus, the timing functionality is preserved and the safeguard of restricted execution privilege is added.
4.4
The sensitive information management component was implemented as a combination of JavaScript logic and a SqlLite database. It contains functions that mimic the functionality of native browser components that return personally identifying information. These functions return the same kind of data that their equivalents do but of the installer’s choosing, rather than ID information directly from the browser. Upon installation, the user is given the option to specify their own anonymous data or to use randomized data. This information is stored in an SQLLite database. A reference to the sensitive information management component library is inserted into a given extension file in the code transformation stage if calls to sensitive data sources were found. Then the calls to those sources were replaced with their anonymous counterparts. This way when the extension ran it would function normally to the user while being prevented from identifying them.
Sensitive Information Management
While installing if the user elects to install an extension that has requested access to sensitive information, the option to create a “fake” profile will be presented to them. This fake profile’s information will be used rather than the user’s real information. Similar functionality has been proposed by Beresford [23] in the MockDroid solution. This component also protects against accesses to sensitive information unique to the browser’s DOM, such as the appname property. This component will replace calls to sensitive resources, like window.navigator.geolocation, and with calls to location information of the user’s choosing. This profile information is stored in a database that is accessible only by the protection tool and be modifiable by the user. By being able to fake this sensitive data, a user can use an extension that requests this information without fear of the extension using it maliciously.
4.5 4.5.1
4.5.2
Evaluation
The solution was tested against the malicious and vulnerable extensions that were created. Against the malicious extension, our protection mechanism successfully flagged a suspicious flow from each function of the extension. It even reported flows from the three functions that cannot work due to a lack of Android permissions and APIs that can access the required resource. When the install was granted in spite of the warning, a fake profile provided false information to the GPS function for protecting the real device location. Since the other malicious functionality did not deal with personal information, it was not protected by this component. Similarly, our tool was successfully protected the vulnerable extensions discussed before. The static analyzer discovered the dangerous flow to the eval function. If the warning was ignored by the user, then the eval function was correctly wrapped. When malicious code was executed, it failed due to a lack of permissions. Note that JavaScript is robust enough to deal with runtime exceptions when the dangerous web page loaded as normal without interfering with the user’s browsing experience. While our tool succeeded in protecting the vulnerable and malicious extensions, it (mostly the static analysis component) was found to have some performance impact. The sensitive information manager also added a delay of two to three seconds. Finally, some choices made for the design of our tool proved particularly effective. Among which we mention: i) Use existing Firefox for Android technologies: The solution needs to fit into the existing Firefox for Android ecosystem in order to lessen the complexity of implementation and to support backwards compatibility. ii) Require a minimum amount of overhead. Mobile devices have more limited resources than desktops do in almost every category — CPU power, RAM, and screen size. The solution needs to place performance at a premium or else it will risk tainting the browsing experience; iii) Warn against malicious extensions: Once malicious extensions are installed the only way to get rid of them is to uninstall them. A solution that tried to protect a user from an explicitly malicious extension and provide a normal browsing experience would be doomed to failure. Therefore what is needed is a solution that can identify and warn a user against malicious extensions; iv) Protect vulnerable extensions: It cannot reasonably be expected
Implementation and Evaluation Implementation
We have implemented our solution as a combination of extensions on Firefox for Android and a slightly modified browser of Firefox for Android. The modified browser calls our tool when the user attempts to install a new extension or update an existing one. The overall extension logic, code transformation, and static analyzer components were implemented in JavaScript. More specifically, for the static taint analysis we developed a JavaScript module which utilizes the Mozilla’s Parser API, the Esprima, and Escodegen based on dfatool [8]. First the extension’s files were analyzed for any reference to Javascript files that are not included in the .xpi file. If any of these are found, then they are downloaded for analysis. Then a search is made for any ”eval-like” functions or calls to browser functions which return personally identifying information. These uses are marked and saved for use by the next phases of the project. A static call graph was then made for each file. These graphs are then trimmed of flows that did not contain a sensitive source or a malicious sink. The remaining graphs were then processed to find any that contained a source to sink flow. Any flow found was recorded in the database in XML format. We implemented the code transformation as a JavaScript library (EvalWrap.js) which receives the locations of ”evallike” functions from the static taint analysis component. We do that first by creating a sandbox object with a unique and restricted principal in the file. Then calls to the dangerous functions are simply wrapped in the Firefox’s evalInSandbox() component.
33
that every extension created will contain zero vulnerabilities. The solution should help protect “benign but buggy” extensions to provide a safeguard to users and to provide time for extension developers to fix them. We further made the following mobile device design considerations respect to screen size, CPU and Memory Limitation and Battery limitations. More specifically, for the small screens in the extension’s warning phase, dense details are omitted in favor of simple decisions. When one or more dangerous pieces of functionality was discovered these were not detailed to the user immediately. First the user is told ”Dangerous functionality found. Continue installation?” and given the option to ”Cancel”, ”Continue”, or ”Details”. The ”Cancel” and ”Continue” options canceled the installation process or continued it respectively. The ”Details” option presents the user with a new tab detailing the category of dangerous functionality found and a link to an XML report of the exact functionality. By presenting the user with the important decision first in a clear manner and then progressively detailed screens for those users who desire it, the small screen space is effectively utilized. Second, while modern high end mobile devices are approaching their desktop counterparts in terms of hardware ability, the average mobile device contains a fraction of the processing ability that their desktop counterparts contain. Since this project was created in Javascript, efforts were made to make the code as efficient as possible. Specifically, the static taint analysis portion of the project was identified to be the most likely to cause a performance impact to the large amount of text it needs to process. Finally, limited battery life is a unique constraint of mobile devices. Where in the desktop environment a developer can safely assume a given device has unlimited power to use, mobile devices have a very real limitation in terms of available power. To address this, our implementation was made as efficient as possible and the power expensive task of Internet access (via the radio) was limited as much as possible.
5.
attack detectors at the interpreter level as well as using an XPCOM string-tainting solution originally proposed in [38]. These solutions are implemented by altering existing Firefox technologies. As these solutions are implemented by modifying existing Firefox technologies, they could be ported to and tested in the mobile environment would not be overly difficult. However, these solutions impose a fairly significant memory overhead which while negligible in the desktop space could prove to be too great in the mobile space. In fact, when evaluating and comparing their overhead with our proposed solution qualitatively, our preliminary prototype implementation showed a better result. SENTINEL [35] is a policy manager that allows Firefox users to specify policies for extensions and offers run time enforcement of those policies. A user could specify that extensions are allowed to read from the file system and password manager but not allowed to write to either. Additionally, the user can use pre-defined policies or specify a policy per extension, giving a great deal of control up to the user. Since SENTINEL is implemented by modifying the JavaScript interpreter and Firefox browser it could also be ported and tested in the mobile environment without extensive modification. JSPoint and JSRand offer a comprehensive defense to code injection attacks [22]. The JSRand component processes extension code by first parsing then randomizing the code based on an encryption key. The JSPoint component statically analyzes the code for dangerous information flows. If any such flows are found, then the entire flow is not randomized. This is done because during extension execution, code is sent back to JSRand to be derandomized before being executed. Legitimate code from the extension will be derandomized and executed correctly. Any unsafe code from suspicious information flow will be derandomized into a scrambled state and fail when being executed by the browser. If this solution’s performance overhead could be optimized, it would be an effective solution for mobile environment. A specific class of JavaScript attacks, called Cross-Origin capability leaks, are defined by Barth, et al. [21] and a robust defense is proposed and evaluated. Cross-Origin capability leaks are a class of implementation vulnerabilities that occur when a browser leaks the pointer of JavaScript object from one security origin to another. Their proposed defense works by adding access control checks throughout the JavaScript engine. This approach allows a robust access control system with a minimal performance impact. The negligible performance combined with the JavaScript engine implementation makes this an ideal solution to test in the mobile space. For our implementation, we have borrowed and extended some concepts from this work for the information flow analysis. The VEX framework [20] employs static analysis to find flow patterns that could lead to privilege escalation attacks. By evaluating these flows, VEX is able to simultaneously check for malicious and vulnerable extensions before they are installed to the browser. As this solution is implemented in Java and using the ANTLR parser, it would be a significant effort to transform it into a solution suitable for mobile use.
RELATED WORK
The topics of securing browser extensions in desktop environments and securing applications on the Android platform have each received a good deal of researcher attention in recent years. Each branch of research provides possible solutions to secure Firefox for Android extensions. In this section, a review of these solutions is offered, with a focus on solutions that could either be transformed to work in the mobile space or that offer sufficient flexibility to secure extensions on Firefox for Android without compromising functionality.
5.1
Securing Firefox Extensions
SABRE [25] employs a dynamic taint analysis technique to monitor JavaScript execution in extensions. It uses security labels to monitor sensitive objects by labeling the sensitive objects and controlling how labeled objects are accessed by the extensions. If SABRE detects a labeled object being sent over the network, it will raise an alert to the user of this attempted action. Similarly, another taint analysis system concerned with preventing privilege escalation attacks is presented in [26]. Privilege escalation attacks are attacks in which unprivileged code tricks the interpreter into giving it more rights than it should. The taint system is implemented by adding a taint tag to JavaScript objects and
5.2
Securing Android Applications
A security architecture for Linux based smartphones that provides a runtime integrity measurement system proposed in [37]. The proposed architecture relies on a Mobile Trusted Module (MTM) which would only allow applications to run
34
on the smartphone which have been signed by the MTM and would check pre-exisisting applications for modification. If such a modification is detected and was not authorized by the MTM, it would not be allowed to run. If the signature verification system could be extended to include browser extensions, it could prove to be a viable technique to securing known safe extensions from modification by an attacker. TaintDroid [27] provides a dynamic taint tracking system that provides taint tracking at the variable, message, method and file levels. By performing system wide tracking, it offers users the ability to track their sensitive information wherever it may flow to their system. The solution is focused on efficiency and offers only a 14% overhead to normal operation. As this solution relies on dynamic tainting only, it could miss more complex flows introduced by explicitly malicious applications. The solution is already implemented on Android devices and could easily be tested to catch suspicious flows in Firefox for Android applications. MockDroid [23] allows users to “mock” sensitive information required by certain applications that users feel the applications do not need. As mentioned previously, the Android security policy requires all of an application’s permissions to be granted in order to be installed or all of them denied. By mocking sensitive data, MockDroid gives users more flexibility in their permission granting. By configuring “mock permissions” a user can tell MockDroid to return blank contact data, SMS information, and fake locations. This solution applies directly to Firefox for Android users worried about extension’s accessing their sensitive data from their hardware. However, it does not provide any protection for information revealed by the browser. A detailed look at of the degradation of security standards present in the mobile version of popular browsers is presented in [19]. Desktop browsers use various security indicators to inform users about the security of their connections. For example, most desktop browsers allow a user to see the details of a security certificate and never obfuscate this information. It was found that mobile browsers consistently failed to implement the standards set out by the World Wide Web Consortium and did not meet the standards set by their desktop counterparts. This research underlines another branch of security trade offs made for the mobile space and the dangers those trade offs represent. However, we were unable to find technical details of this work thereby unable to make comparison. The MAST architecture [24] proposes a triage system that provides a quick and accurate report on applications most likely to pose a threat to a mobile device. By analyzing several attributes from the application package with statistic analysis, the framework can help users and administrators get an idea of how dangerous a given application could be. While this solution is Android application specific, the general idea of a triage system that can aid in the identification of dangerous functionality could be adapted to work for extensions. Such a system could be used to help prevent malicious and vulnerable extensions from being released in Mozilla’s official repository. The Kirin security service is a lightweight certification system aimed at mitigating the danger of malicious applications from being installed [28]. The service compares new application’s attributes against a set of security rules built from principles of security requirements engineering. If violations of the rules are found they are displayed to the user so instal-
lation can be stopped. Like MAST, the idea of a lightweight security service could beapplied to browser extensions.
6.
CONCLUSION
Globally, it is estimated that by the year 2018 there will be more than 1 billion employee-owned mobile devices. In growth market (e.g., in Africa), the number is enjoying an average of 4.2 percent annual growth. This attracted a number of app developers who often have little knowledge about software engineering and secure development techniques such as security by design, program analysis, and anomaly detection to make their apps secure and reliable. As a result, they mostly rely on the underlying platform and environment. Like the desktop environment, for instance, extensions on Firefox for Android environment provides the same access to XPCOM and relents the restrictions of the SOP. As a result, malicious mobile extensions, or unsafely designed extension code with vulnerability may clear the path for a vibrant mobile extension environment but also for the same dangers that affect the desktop browser to affect the mobile browser. Moreover, vulnerabilities present in every layer of the Android OS from the applications and framework down to the kernel layer. This paper studied the dangers posed by extensions on Firefox for Android framework were explored and detailed. Previous work on dangerous behaviors found in Firefox extensions and Android applications were compared to the behaviors present in extensions on Firefox for Android platform. It was found that these extensions contain many of the same dangerous functionality present in the Firefox and Android applications. A prototype tool was implemented and tested against the extensions that were created. More specifically, to defend against the range of attacks that could occur, three main components were implemented to defend against JavaScript injection attacks and to safeguard user information. The solution successfully warned the user about the malicious extension and protected the vulnerable extension. Future work will focus on improving the performance of the solution and making it more general in scope so that it can be applied to other mobile applications.
7.
REFERENCES
[1] Add Ons Extensions. https: //addons.mozilla.org/en-US/firefox/extensions/, August 23 2013. [2] Android Overview. http: //www.openhandsetalliance.com/android_overview.html, August 15 2013. [3] Android Security Overview. https://source.android.com/ devices/tech/security/index.html, July 1 2013. [4] Blocked Add Ons. https://addons.mozilla.org/en-US/firefox/blocked/, August 23 2013. [5] Chapter 2: Technologies Used in Developing Extensions. http://goo.gl/mpIA1j, August 22 2013. [6] Developer Tools | Android Developers. http://developer.android.com/tools/index.html, Retrieved, August 29 2013. [7] Developing for Firefox Mobile - Add-on SDK Documentation. https://addons.mozilla.org/en-US/developers/docs/ sdk/latest/dev-guide/tutorials/mobile.html, August 26 2013.
35
[8] DFATool. https://github.com/pissang/dfatool, Retrieved July 24 2013. [9] Firefox for Android. https://developer.mozilla.org/ en-US/docs/Mozilla/Firefox_for_Android, Retrieved August 22 2013. [10] LastPass - Password Manager, Form Filler, Password Management. https://lastpass.com/, Retrieved August 20 2013. [11] Malicious Browser Plugin - Spreading Spam on Facebook. https://bugzilla.mozilla.org/show_bug.cgi?id=899178, August 23 2013. [12] Malicious The Social Networks Add-On. https://bugzilla.mozilla.org/show_bug.cgi?id=857847, August 23 2013. [13] More than one billion BYOD users predicted by 2018. http://goo.gl/qr0PyX, Published on November 21 2013. [14] NoScript - Extension for Mozilla Firefox, SeaMonkey, and other Mozilla-based web browsers. http://noscript.net/, Retrieved August 20 2013. [15] Statistics for Adblock Plus. https://addons.mozilla.org/en-US/android/addon/ adblock-plus/statistics/?last=30, August 22 2013. [16] window.navigator.mozSMS. https://developer.mozilla. org/en-US/docs/Web/API/window.navigator.mozSms, Published July 27 and Retrieved August 31 2013. [17] window.navigator.mozTelephony. https://developer.mozilla.org/en-US/docs/Web/API/ window.navigator.mozTelephony, Published June 23 and Retrieved August 31 2013. [18] XPInstall. https://developer.mozilla.org/en-US/docs/XPInstall, Retrieved September 5 2013. [19] C. Amrutkar, P. Traynor, and P. C. van Oorschot. Isc’12. pages 86–103, 2012. [20] S. Bandhakavi, N. Tiku, W. Pittman, S. T. King, P. Madhusudan, and M. Winslett. Vetting browser extensions for security vulnerabilities with vex. Commun. ACM, 54:91–99, Sept. 2011. [21] A. Barth, J. Weinberger, and D. Song. Cross-origin javascript capability leaks: detection, exploitation, and defense. In SSYM’09, pages 187–198, 2009. [22] A. Barua, M. Zulkernine, and K. Weldemariam. Protecting web browser extensions from javascript injection attacks. In ICECCS, pages 188–197. IEEE, 2013. [23] A. R. Beresford, A. Rice, N. Skehin, and R. Sohan. Mockdroid: trading privacy for application functionality on smartphones. In HotMobile ’11, pages 49–54. ACM, 2011. [24] S. Chakradeo, B. Reaves, P. Traynor, and W. Enck. Mast: triage for market-scale mobile malware analysis. In WiSec ’13, pages 13–24. ACM, 2013. [25] M. Dhawan and V. Ganapathy. Analyzing information flow in javascript-based browser extensions. In ACSAC ’09, pages 382–391, 2009.
[26] V. Djeric and A. Goel. Securing script-based extensibility in web browsers. In USENIX Security’10. USENIX Association, 2010. [27] W. Enck, P. Gilbert, B.-G. Chun, L. P. Cox, J. Jung, P. McDaniel, and A. N. Sheth. Taintdroid: an information-flow tracking system for realtime privacy monitoring on smartphones. In OSDI’10. USENIX Association, 2010. [28] W. Enck, M. Ongtang, and P. McDaniel. On lightweight mobile phone application certification. In CCS ’09, pages 235–245. ACM, 2009. [29] D. Etherington. Android Nears 80% Market Share In Global Smartphone Shipments, As iOS And BlackBerry Shares Slide, Per IDC, Retrieved August 20 2013. [30] F. Maggi, A. Valdi, and S. Zanero. Andrototal: A flexible, scalable toolbox and service for testing mobile malware detectors. In SPSM ’13, pages 49–54, New York, NY, USA, 2013. ACM. [31] McAfee Labs. McAfee Threats Report: First Quarter 2013, Retrieved August 31 2013. [32] Mozilla. XPCOM. https://developer.mozilla.org/en-US/docs/XPCOM, Retrieved August 23 2013. [33] C. Mulliner, J. Oberheide, W. Robertson, and E. Kirda. PatchDroid: Scalable Third-Party Patches for Android Devices. In ACSAC. [34] National Vulnerability Database (NVD) National Vulnerability Database. Vulnerability Summary for CVE-2009-4127. http://web.nvd.nist.gov/view/vuln/ detail?vulnId=CVE-2009-4127, Retrieved July 20 2013. [35] K. Onarlioglu, M. Battal, W. K. Robertson, and E. Kirda. Securing Legacy Firefox Extensions with SENTINEL. In DIMVA, pages 122–138. Springer, 2013. [36] J. Scott. How many Firefox users have add-ons installed? 85%! http://blog.mozilla.org/addons/2011/06/21/ firefox-4-add-on-users/, June 21 2011. [37] O. Ugus, M. Landsmann, D. Gessner, and D. Westhoff. A smartphone security architecture for app verification and process authentication. In ICCCN, pages 1–9, 2012. [38] P. Vogt, F. Nentwich, N. Jovanovic, E. Kirda, C. Kr¨ ugel, and G. Vigna. Cross site scripting prevention with dynamic data tainting and static analysis. In Annual Network & Distributed System Security Symposium, 2007. [39] J. Wang, X. Li, X. Liu, X. Dong, J. Wang, Z. Liang, and Z. Feng. An empirical study of dangerous behaviors in firefox extensions. In ISC, pages 188–203. Springer, 2012. [40] M. V. Yves-Alexandre de Montjoye, Cesar A. Hidalgo and V. D. Blondel. Unique in the crowd: The privacy bounds of human mobility. SCIENTIFIC REPORTS, (3), 2012. [41] Y. Zhou and X. Jiang. Dissecting android malware: Characterization and evolution. In SP ’12, pages 95–109, 2012.
36
