Hulk: Eliciting Malicious Behavior in Browser Extensions Alexandros Kapravelos, University of California, Santa Barbara; Chris Grier, University of California, Berkeley, and International Computer Science Institute; Neha Chachra, University of California, San Diego; Christopher Kruegel and Giovanni Vigna, University of California, Santa Barbara; Vern Paxson, University of California, Berkeley, and International Computer Science Institute https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/kapravelos
This paper is included in the Proceedings of the 23rd USENIX Security Symposium. August 20–22, 2014 • San Diego, CA ISBN 978-1-931971-15-7
Open access to the Proceedings of the 23rd USENIX Security Symposium is sponsored by USENIX Hulk: Eliciting Malicious Behavior in Browser Extensions
† ‡ Alexandros Kapravelos Chris Grier ∗ Neha Chachra Christopher Kruegel † Giovanni Vigna Vern Paxson ∗ † ‡ UC Santa Barbara UC Berkeley UC San Diego
∗International Computer Science Institute kapravel, chris, vigna @cs.ucsb.edu grier, vern @cs.berkeley.edu [email protected] { } { }
Abstract to monetize a victim’s web browsing session and readily access web-related content and private data. We present Hulk, a dynamic analysis system that de- Our work examines extensions for Google Chrome tects malicious behavior in browser extensions by mon- that are designed with malicious intent—a threat dis- itoring their execution and corresponding network activ- tinct from that posed by attackers exploiting bugs in be- ity. Hulk elicits malicious behavior in extensions in two nign extensions, which has seen prior study [6, 5]. Ex- ways. First, Hulk leverages HoneyPages, which are dy- tensions for Google Chrome are primarily distributed namic pages that adapt to an extension’s expectations in through the Chrome Web Store.1 Like app stores for web page structure and content. Second, Hulk employs other platforms, such as Android or iOS, inherent risks a fuzzer to drive the numerous event handlers that mod- arise when downloading and executing programs from ern extensions heavily rely upon. We analyzed 48K ex- untrusted sources. Reports have documented not only tensions from the Chrome Web store, driving each with malicious extensions [27], but miscreants purchasing ex- over 1M URLs. We identify a number of malicious ex- tensions (and thereby access to their userbases via update tensions, including one with 5.5 million affected users, mechanisms) to add malicious functionality [2, 25]. In stressing the risks that extensions pose for today’s web addition to the web store, extensions can also be directly security ecosystem, and the need to further strengthen installed by users and other programs. Installed by a pro- browser security to protect user data and privacy. cess called sideloading, these extensions pose a recog- nized risk that browser vendors have attempted to prevent 1 Introduction through modifications to the browser [22]. Sideloaded extensions are especially problematic since they can be All major web browsers today support broad extension installed without user knowledge, and are not subject to ecosystems that allow third parties to install a wide range review by a web store. Despite efforts to stifle sideloaded of modified behavior or additional functionality. Inter- extensions, they remain a significant problem [12]. net Explorer has binary add-ons (Browser Helper Ob- In this paper we present Hulk, a tool for detecting ma- jects), while Firefox, Chrome, Opera, and Safari support licious behavior in Google Chrome extensions. Hulk re- JavaScript-based extensions. Some browsers have online lies on dynamic execution of extensions and uses several web stores to distribute extensions to users. For exam- techniques to trigger malicious functionality during exe- ple, the most popular extension in Chrome’s Web Store, cution. One technique we developed to elicit malicious AdBlock, has over 10 million users. Other popular ex- behavior is the use of HoneyPages: specially-crafted web tensions serve a variety of functions, such as preserving pages designed to satisfy the structural conditions that privacy, changing the aesthetics of the browser’s UI, or trigger a given extension. We interpose on all queries and integrating with web services such as Google Translate. modifications to the DOM tree of the HoneyPage to au- The amount of critical and private data that web tomatically create elements and mimic DOM tree struc- browsers mediate continues to increase, and naturally tures for extensions on the fly. Using this technique, we this data has become a target for criminals. In addition, can readily observe malicious behavior that inserts new the web’s advertising ecosystem offers opportunities to iframe or div elements. profit by manipulating a user’s everyday browsing be- In addition, we built a fuzzer to drive the execution havior. As a result, malicious browser extensions have become a new threat, as criminals realize the potential 1https://chrome.google.com/webstore/category/extensions
USENIX Association 23rd USENIX Security Symposium 641 of event handlers registered by extensions. In our ex- performing other actions. The permission system deter- periments, we use the fuzzer to trigger all event handlers mines which sites an extension can access, the allowed associated with web requests, exercising each with 1 mil- API calls, and the use of binary plugins. We describe lion URLs. Although we undertook extensive efforts to relevant parts of the permission system later in this sec- trigger malicious behavior, the possibility remains that tion. See Barth et al. for a more detailed description of Hulk lacks the mechanisms to satisfy all of the conditions Chrome’s extension architecture [5]. necessary for eliciting an extension’s malicious behavior. Our analysis of 48,332 Chrome extensions found that 2.2 Installing Extensions malicious extensions pose a serious threat to users. By developing a set of rules that label execution logs from The Chrome Web Store is the official means for users Hulk, we identified 130 malicious extensions and 4,712 to find and install extensions. The web store is similar “suspicious” extensions, most of which appear in the to other app stores, such as those for iOS and Android, Chrome Web Store. Several large classes of malicious in that developers create extensions and upload them to behavior appear within our set of extensions: affiliate the store for users to download. Extension developers fraud, credential theft, ad injection or replacement, and can also push out updates without requiring any action social network abuse. In one case, an extension perform- by the end-user. ing ad replacement had nearly 2 million users, similar in In addition to the Chrome Web Store, extensions can size to some of the largest botnets. also be installed manually by a user or an external pro- In summary, we frame our contributions as follows: gram. We refer to the installation of extensions out- side the web store as sideloading. Chrome version 25 We present Hulk, a system to perform dynamic • (released February, 2013) included changes to prevent analysis for Chrome extensions. silent installation of Chrome extensions and require that We demonstrate the effectiveness of HoneyPages the user indicate consent for installation [22]. In May, • and event handler fuzzing to elicit malicious behav- 2014, Chrome took further steps to prevent sideload- ior in browser extensions. ing by requiring all installed extensions to be hosted in the Chrome Web Store [18]. While these changes in- We perform the first broad study of malicious • crease the difficulty of sideloading, it is still possible Chrome extensions. for programs to force silent installation of extensions, We characterize several classes of malicious since the attacker already has control of the machine. For • Chrome extensions, some with very large footprints our study we obtained a set of extensions that are side- (up to 5.5M installations) and propose solutions to loaded into Chrome by other Windows programs, many eliminate entire classes of malicious behavior. of which are known malware.
2 Background 2.3 Extension Permissions
We begin by reviewing the Google Chrome extension Permissions. Chrome requires extensions to list the model and the opportunities this model provides to mali- permissions needed to access the different parts of the cious extensions. extension API. For example, Figure 1 shows a portion of a manifest file requesting permission to access the webRequest and cookies API. The webRequest per- 2.1 Chrome Extension Composition mission allows the extension to “observe and analyze Google Chrome supports extensions written in traffic and to intercept, block, or modify requests in- JavaScript and HTML (distributed as a single zip flight” by allowing the extension to register callbacks file). A small number of extensions also include binary associated with different parts of the HTTP stack [15]. code plugins, although these are subject to a manual Similarly, the cookies API allows the extension to get, security review process [15]. Each extension contains a set, and be notified of changes to cookies. (mandatory) manifest that, along with other extension The extension API permissions operate in con- parameters, describes the permissions the extension uses junction with the optional host permissions, which and the list of resources that the browser should load. limit the API permissions to access resources only The permission system is designed in the spirit of least for the specified URLs. For example, in Fig- privilege, with the goal of limiting the resources avail- ure 1 the extension requests host permissions for able to an extension in case it has exploitable vulnera- https://www.google.com/, which allows it to ac- bilities [5]. The threat model does not attempt to ad- cess cookies and webRequest APIs for the specified dress malicious extensions accessing sensitive content or domains. Host permissions also support wildcarding
2 642 23rd USENIX Security Symposium USENIX Association ... "permissions": [ The ability to run in the context of a page is a powerful "cookies", feature. Once a content script executes, any resulting ac- "webRequest", tions become indistinguishable from actions performed "*://*.facebook.com/", by JavaScript provided by the web server. Not only can "https://www.google.com/" the scripts modify the DOM tree or other scripts, but they ], can also issue authenticated web requests (such as POST ... with proper cookies). "content_scripts": [ Background Pages. Besides the content scripts that { allow an extension to interact with a given page, "matches": ["http://www.yahoo.com/*"], Chrome also allows extensions to run scripts in a "js": ["jquery.js", "myscript.js"] “background page”. Figure 1 shows an example man- } ifest file that specifies background.js as a back- ], ground page. Background pages often contain the ... logic and state an extension needs for the entirety "background": { of the browser session and do not have any visibil- "scripts": ["background.js"] ity to the user. For example, an extension request- }, ing webRequest permissions may use the background ... script to attach a listener to read outgoing requests "content_security_policy": "script-src 'self' using the chrome.webRequest.onBeforeRequest. http://www.foo.com 'unsafe-eval';" addListener() call. After filtering on the host permis- ... sions, Chrome will send the extension a notification for every outgoing request. We detail further examples in the context of the extensions in the following sections. Figure 1: Example of a manifest that shows API permis- sions for two hosts, followed by content scripts that run Content Security Policy. In general, servers can specify on http://www.yahoo.com, followed by a background a Content Security Policy (CSP) header that the browser script that runs on all pages. Finally, the CSP specifies uses to determine the sources from which it can include the ability to include and eval scripts in the extension objects on the page. CSP can also specify other options, from foo.com. such as whether to allow the page to perform an eval or to embed inline JavaScript [29]. Extensions can use the same syntax to express their CSP in the manifest file. URLs. In Figure 1, the extension requests access to For example, an extension that wishes to include source *://*.facebook.com. This permission allows for ac- from foo.com and to execute eval can specify its CSP cess to all subdomains of facebook.com requested via as shown in Figure 1. any URL scheme. In addition to wildcards, the special
3 USENIX Association 23rd USENIX Security Symposium 643 from multiple vantage points within Hulk as it visits web 3.2 Event-Based Execution pages and triggers a range of extension behavior. The Chrome browser offers to extensions an event- based model to register callbacks that respond to certain URL Extraction. Before we dynamically analyze an ex- browser-level events. For example, extensions use the tension we need to ensure that we can trigger the exten- chrome.webRequest.onBeforeRequest callback to sion’s functionality. Most extensions interact with the intercept all outgoing HTTP requests from the browser. content of web pages, so we need to choose which URLs HoneyPages will not trigger callbacks for network events to load for our analysis. To this end, we use three sources that require special properties, such as a specific URL of URLs: the manifest, the source code, and a list of pop- or HTTP header. Therefore, we complement Honey- ular sites. First, using the manifest file of the extension Pages with event handler fuzzing. Specifically, we in- we construct valid URLs that match the permissions and voke all event callbacks that an extension registers in the content scripts specified. In some cases, the host per- chrome.webRequest API with mock event objects. We missions of an extension are restrictive—for example, point to a HoneyPage loaded in the active tab while in- https://*.facebook.com—so we can generate URLs voking the callbacks, enabling us to monitor the changes that will match the pattern. It is more difficult to pick that the extension attempts to make on that page. Our URLs to visit in cases where the extension requests host approach allows us to test for every extension the exten- permissions on all URLs (Section 2.3), because the ma- sion’s callbacks on the top 1 million Alexa domains in licious behavior may only trigger on a small subset of under 10 seconds on average. sites. Therefore, we search the source code for any static URLs and visit those as well. Finally, for every extension we also visit a set of popular sites targeted by malicious 3.2.1 Monitoring Hooks extensions. We constantly strive to improve this list as Depending on the permissions we detect malicious extensions attacking particular do- Browser Extension API. included in the manifest (Section 2.3), an extension can mains. We however note that although we use multiple use the Chrome extension API to perform actions not sources of URLs to determine the appropriate pages to available to JavaScript running in a web page. As such, visit, our approach is not complete; we discuss the limi- monitoring the extension API captures a subset of the tations further in Section 7. total JavaScript activity that results from an extension, but gives us a detailed picture of what the extension at- HoneyPages. Some extensions activate based on the tempts to do. For example, we monitor the extension API content of a web page instead of the URL. To analyze and log if the extension registers a callback to intercept such extensions we use specially crafted pages that at- all HTTP requests performed by the browser, and then tempt to satisfy the conditions that an extension looks track the changes that the extension makes to the HTTP for on a page before performing an action. We call these requests. To do this, we leverage the current logging in- HoneyPages. HoneyPages contain JavaScript functions frastructure offered by Chrome for monitoring the activ- that overload built-in functions that query the DOM tree ity of extensions. We build upon the JavaScript func- of the web page. As a result, when an extension queries tion call logging provided by the browser to identify ma- for the presence of a specific element we can automati- licious behavior, such as tampering of security-related cally create it and insert it into the page. For example, if HTTP headers. the extension queries an iframe DOM element with the Content Scripts. We intercept and log all additional intention to alter it, then our HoneyPage will create an code introduced by the extension in the context of the iframe element, inject it in the DOM tree, and return it visited page. Doing so provides a more complete picture to the extension. of the extension’s functionality, since it can include re- mote scripts from arbitrary locations and inject them into HoneyPages enable us to supplement the URL extrac- the page. Remote scripts can compromise the page’s se- tion phase and dynamically create an environment for the curity similar to third-party JavaScript libraries [23], and extension to perform as many actions as it needs. The on- make the analysis of the extension more difficult. Using demand nature of a HoneyPage does not restrict us to a remote scripts gives miscreants the ability to blacklist IP specific DOM tree structure, but enables us to determine addresses of our analysis system (i.e., cloaking [17, 28]) what an extension looks for in a page during execution, or return code without the malicious components. Re- since we can record all interactions within a HoneyPage. mote JavaScript inclusion also renders static analysis By using HoneyPages we can better understand how the on the extension’s code fundamentally incomplete since extension will behave on arbitrary pages that are other- parts of the extension’s codebase are not available until wise difficult to generate prior to analysis. execution.
4 644 23rd USENIX Security Symposium USENIX Association Network Logging. We use a transparent proxy that in- ful extensions on its blacklist.2 We detect this behavior tercepts all browser HTTP and DNS traffic to log the re- by monitoring the chrome.management.uninstall quests made during extension execution. A browser ex- API calls. To avoid false positives, we can differentiate tension has a set of files available as resources loaded by cleaners from malicious extensions because, to the best the browser, and it can also download and execute con- of our knowledge, cleaners operate in a different fashion tent from the web. Since the URLs retrieved can be com- than Antivirus does: they clean up malicious extensions puted at runtime, monitoring the network activity of the and then remove themselves from the browser. This dif- extension is critical for a complete analysis of its source fers from the behavior of malicious extensions, which code and included components. In addition to identifying remain persistent on the system. remote content, we log all domains contacted by moni- Besides attempting to uninstall other extensions, mali- toring the DNS requests generated by the browser. Do- cious extensions often prevent the user from uninstalling ing so enables us to identify extensions that contact non- the extension itself. More specifically, we found exten- existent domains, which can occur because the extension sions that prevent the user from opening Chrome’s exten- is no longer operational or up-to-date. In these cases, our sion configuration page where a user can conveniently analysis was necessarily incomplete, since when the do- uninstall any extension. To prevent uninstallation, ma- main was active the extension could have fetched more licious extensions interfere with tabs that point to the remote code from it. extension configuration page, chrome://extensions, either by replacing the URL with a different one, or by removing the tab completely. For analysis, we load a tab 3.3 Detecting Malicious Behavior with chrome://extensions in the browser during our dynamic analysis and monitor any interactions to iden- As described in the previous section, our dynamic anal- tify such behavior. ysis system can provide detailed information about all Lastly, using callbacks in the webRequest API, browser and extension activity performed while visiting a malicious extension can manipulate HTTP headers. web pages. We combine this data to label the extension Extensions can use the webRequest API to effec- as either benign, suspicious, or malicious by applying a tively perform a man-in-the-middle attack on HTTP set of labeling heuristics based on the behavior. Labeling requests and responses before they are handled by an extension as malicious indicates we identified behav- the browser. This behavior is often malicious (or at ior harmful to the user. Suspicious indicates the presence least dangerous) since we found extensions that re- of potentially harmful actions or exposing the user to new move security-related headers, such as Content-Security- risks, but without certainty that these represent malicious Policy or X-Frame-Options, through the use of call- actions. Finally, when we do not find any suspicious ac- backs such as webRequest.onHeadersReceived and tivity, we label the extension as benign. webRequestInterval.eventHandled. By monitor- ing the use of this API, we can log events that reveal state of HTTP headers before and after the request. Upon ma- 3.3.1 JavaScript Attributes nipulation of any security-related headers, we label the extension as malicious. We use our monitoring modules described in Sec- Interaction with visited pages. In addition to the exten- tion 3.2.1 to identify malicious JavaScript execution. Be- sion API, we also monitor an extension’s use of content low we detail actions that we consider malicious or sus- scripts to modify web content loaded in the browser. In picious in our post-processing analysis. our analysis, we flag two kinds of interaction: sensitive Extension API. As described earlier, Chrome’s exten- information theft as malicious and injection of remote sion API offers privileged access to additional function- JavaScript content as suspicious. ality of the browser besides native JavaScript, using per- There are many ways an extension can steal per- missions specified in the manifest file. While there are sonal information from the user. For example, it can benign uses for every permission, we found several ex- act as a JavaScript-based keylogger by intercepting all tensions that abuse the API. Specifically, for reasons de- keystrokes on a page. Extensions can also access form scribed below, we consider the following actions avail- data, such as a password field, before it is encrypted able only through the extension API as malicious: unin- and sent over the network. Finally, extensions can also stalling other extensions, preventing uninstallation of the steal sensitive information from third parties by access- current extension, and manipulating HTTP headers. ing sites with which the user has a valid session, and ei- We consider uninstalling other extensions as malicious 2https://chrome.google.com/webstore/ because some extensions uninstall cleaner extensions, detail/facebook-malicious-extens/ such as the extension Facebook created to remove harm- mhkafblddkepdhhjpmedkngigkjjknoa
5 USENIX Association 23rd USENIX Security Symposium 645 ther issuing requests to exfiltrate data, or simply stealing Analysis result Count valid authentication tokens. Malicious 130 We label any extension that injects remote JavaScript Suspicious 4,712 content into a web page as suspicious. We define this ac- Benign 43,490 tivity as adding a script element with a src attribute pointing to a domain that is different from the one of Total 48,332 the web page. Including these scripts complicates anal- ysis since the JavaScript content can change without any corresponding change in the extension. We have ob- Table 1: Classification distribution of extensions. served changes to JavaScript files that substantially alter the functionality of an extension, possibly due to a server Detection class Count compromise. [s] Injects dynamic JavaScript 2,672 [s] Produces HTTP 4xx errors 2,322 3.3.2 Network Level [s] Evals with input >128 chars long 451 [m] Prevents extension uninstall 56 By monitoring network requests, including DNS lookups [m] Steals password from form 39 and HTTP requests, we identify other types of suspi- [s] Performs requests to non-existent domain 26 cious/malicious behavior. Using a manual analysis of [m] Contains keylogging functionality 23 network logs we have identified two attributes that indi- [m] Injects security-related HTTP header 11 cate malicious or suspicious behavior: request errors and [m] Steals email address from form 10 modification of HTTP requests. To detect HTTP mod- [m] Uninstalls extensions 8 ifications, we examine if the network response that we observe on the wire differs from the network response finally processed by the browser. Table 2: Distribution of detected suspicious/malicious As we discussed earlier, the extension API offers call- behavior from analyzed extensions. Notice that an ex- backs to give extensions the ability to intercept and ma- tension might have more than one detections and that we nipulate web requests. Not only can extensions drop mark with [m] detections classified as malicious and with security-related headers, but extensions can change or [s] detections classified as suspicious. add parameters in URLs before the HTTP request is sent. We find such suspicious behavior common, especially among extensions that request permissions on shopping- ture of JavaScript, can prove difficult to analyze stati- related sites such as Amazon, EBay, and others. In these cally. The use of HoneyPages enables us to understand cases, the extension adds parameters to the URL that in- the injected code’s full intentions. Instead of trying to dicate that the site should credit a particular affiliate for infer what the code will do, we actually run it to observe any resulting sales. We discuss this behavior in more de- its effects on the DOM tree and classify it accordingly. tail in Section 5. At the network level, we have the com- For example, if the injected code looks for a form field plete view of how the requests originally appeared. We with the name “password,” we classify it as malicious, combine that knowledge with our chrome.* API moni- since it can potentially hijack the user’s credentials on toring to identify the exact changes made to the request. the page. Another example concerns injecting additional We also look for errors during domain name resolution code, where the injected code is part of a two-stage pro- to identify extensions that contact domains since taken cess that fetches yet more code from the web and dynam- down. As with drive-by downloads, we expect that ma- ically executes it in the context of the visited page. By licious code dynamically loaded into an extension will relying on HoneyPages to understand the code’s inten- eventually become blacklisted. In such cases, the exten- tions by the effect that the code has on a given page, we sion will fail to introduce more code during its execution. obtain a more precise view of what the code attempts do We detect this behavior and mark it as suspicious. than we can using only static analysis.
3.4 Injected Content Analysis 4 Results A Chrome extension can also manipulate the visited To evaluate Hulk we use two sources of extensions: the pages of the browser by injecting a content script. The official Chrome Web Store (totaling 47,940 extensions), injected script runs in the context of the visited page and extensions sideloaded by binaries. We obtained the and thus has full access to its DOM tree. The injected latter based on binaries executed in Anubis [1], which, code can vary significantly, and, with the dynamic na- after removing a large number of duplicates, resulted in
6 646 23rd USENIX Security Symposium USENIX Association Rank Top 10 types of permissions # ext. Rank Top 25 hosts in permissions # ext. 1 tabs 16,787 1 http://*/* 7,319 2 notifications 12,011 2 https://*/* 6,395 3 unlimitedStorage 9,424 3
7 USENIX Association 23rd USENIX Security Symposium 647 Rank Top 25 hosts in content scripts # ext. Rank Top 15 chrome.* APIs called # calls 1 http://*/* 12,472 1 runtime.onInstalled 182,476 2 https://*/* 10,864 2 webRequestInternal.eventHandled 57,466 3
8 648 23rd USENIX Security Symposium USENIX Association 4.4 Code Injection "content_scripts": [{ "matches": ["http://*/*", "https://*/*"], Code injection was the most commonly detected “sus- "js": ["js/content.js"] picious” feature in our dataset. In principle injection }], need not occur at all, since Chrome extensions can come "permissions": ["http://*/*", packaged with all the code needed to operate. In to- "https://*/*", "tabs"], tal, we found more than 3,000 extensions that dynam- ically introduced remotely-retrieved code either through script injections or by evoking eval. As we noted earlier, Figure 2: Permission-related JSON from the manifest using remote code renders static analysis on the exten- file of an extension performing ad replacement. sion’s code fundamentally incomplete. However, Hulk can identify code injections and pinpoint the remote lo- content. Each instance aims to profit from impressions cations from which an extension fetches code. Although or clicks on the substituted advertisements. not necessarily malicious, we found many cases of dan- As one striking example of ad manipulation we gerous code injection. For example, our system identi- found an extension on the Chrome Web Store that had fied an extension named “Bang5TaoShopping assistant” 1.8M users at the time we detected it. The exten- from the Chrome Web Store that has been installed in sion, named “SimilarSites Pro” used primarily unobfus- 5.6 million (!) browsers and injects code into every vis- cated JS to perform benign functionality as advertised ited page. Several extensions perform this same activity, on the Chrome Web Store; however, it also inserted a while others insert tracking pixels for similar purposes. script element into the content of web pages that down- One instance sends cleartext HTTP request to a server loads another, fully-obfuscated script (using eval and controlled by the extension that encodes the URL visited unescape) from a web server. At the time of analysis, by the user along with a unique identifier, leaking users this script contained a large conditional block that looked browsing behavior and thus compromising their privacy. for iframe elements of particular sizes, such as 728x90 pixels, and replaced them with new banners of the same 5 Profiting from Maliciousness size. Since our first analysis, we have seen several new versions of the script available from the same URL. In In this section, we discuss five categories of malicious addition, the extension contains a blacklist of sites and behavior in extensions, and describe their characteris- meta keywords where it should not change the banners, tics and the methods they employ to carry out their which appears due to many ad networks prohibiting the goals. We base each of these categories on examples we display of their ads on porn sites. found in our feeds. When the extension is available on We find the same JavaScript included in five other ex- the Chrome Web Store, we also when possible include tensions from the Chrome Web Store, as well as one the number of users prior to reporting the extension to sideloaded extension. Based on manual analysis, these Google for review. extensions are primarily produced by a single company We have reported to Google any extension that per- called “SimilarGroup” that engages in dubious behavior forms behavior that is clearly abusive or malicious, and through the Chrome Web Store. several of our reports have lead to removals of extensions To perform banner replacement, the extension requests from the web store. the permissions shown in Figure 2. Such exception- ally wide permissions are not uncommon [6]. There- fore, their presence alone provides little insight into the 5.1 Ad Manipulation functionality of the extension. The most significant per- Advertisement manipulation falls in a grey area in that it mission in Figure 2 is the broad use of content scripts does not subvert the user, but rather manipulates an ex- that allow the extension to inject dynamic JavaScript files ternal ecosystem. Replacing ads might appear benign to from a remote location. Following injection, execution end users, but removes the potential for monetary credit continues as though the page had included it. Such con- for website owners (publishers) and instead fraudulently tent scripts provide an exceptionally powerful feature to credits the extension owner. We include in this category enable a variety of malicious behaviors, as further dis- the addition of new ads as well as the replacement of ex- cussed in this Section. isting ads or identifiers. We find a range of behaviors in extensions, such as replacing banner ads with differ- 5.2 Affiliate Fraud ent identically-sized banners; inserting banners and text ads into well-known sites (such as Wikipedia); changing Many major merchant web sites such as amazon.com, affiliate IDs for ads; or simply overlaying ads on top of godaddy.com, and ebay.com run affiliate programs that
9 USENIX Association 23rd USENIX Security Symposium 649 credit affiliates with a fraction of the sales made as a using tab and webRequest permissions, as well as result of customers referred by the affiliates. Usually by registering callbacks on chrome.tabs.onUpdated merchant programs assign unique identifiers to affiliates, to identify changes in the URL as a user types, which affiliates then include in the URL that refers cus- and chrome.webRequest.onBeforeSendHeaders to tomers to the merchant site. Furthermore, affiliate pro- modify the referrer header before the browser sends a re- grams usually associate a cookie with the user’s browser quest to a merchant site. We found four other extensions so that they can attribute a sale to an affiliate within sev- created by the same developer that similarly provided eral hours after a user originally visited the merchant site some small utility to the user while defrauding merchant with an affiliate identifier. programs in the background. Overall this developer’s ex- As an example, when a user reads product reviews tensions have nearly 70K users. on an Amazon affiliate’s blog and clicks on a link Another extension we found named “Facebook to Amazon, the link includes an Amazon affiliate ID Theme: Basic Minimalist Black Theme” (2.5K users) al- specified with the tag parameter in the URL, such lows users to change the appearance of Facebook. Be- as http://www.amazon.com/dp/0961825170/?tag= sides its stated intent, however, it also monitors brows- affiliateID. When Amazon receives this request, it ing and appends an affiliate identifier to 7 different Ama- returns a Set-Cookie header with a cookie that asso- zon sites. By using its Content Security Policy (Sec- ciates the user with the affiliate. When the customer re- tion 2.3) to perform eval, it runs a highly-obfuscated turns to Amazon within 24 hours and makes a purchase, hexadecimal and base64-encoded background script that Amazon credits the affiliate with a small percentage of stores all affiliate identifiers in Chrome’s storage (using the transaction amount. storage permissions), and registers callbacks on tab up- Such programs expect affiliates to bring potential cus- date events using tab permissions. When the user visits tomers to their sites via affiliate pages that advertise the any URL, Chrome notifies the extension, and the exten- merchant products. However, we found examples of sion uses regular expressions to identify target Amazon several extensions involved in cookie stuffing—a tech- URLs for which to add an affiliate identifier. The ex- nique that causes the user’s browser to visit the merchant tension then updates the URL before the browser sends URLs without the user clicking on affiliate URLs. Do- the request. The creator of the extension appears well ing so causes the merchant to deliver a cookie associ- aware that the extension violates Amazon’s Conditions ated with the fraudulent affiliate, who then receives credit of Use [3] and has heavily used obfuscation, evidently to for any future, unrelated purchase made by the customer evade any static analysis for detecting affiliate fraud. on the merchant site. Besides defrauding the merchant, As another example, we found an extension named the fraudulent affiliate also causes an over-write of the “Page Refresh” (200 installations) that allows users to cookie associated with any legitimate affiliate who might refresh tabs periodically and only requests tabs permis- have genuinely influenced the user to buy the product. sion. By using the background page to listen on all tab In our study, we found two kinds of extensions that update events, if a user visits a merchant site it sets the defrauded affiliate programs. The first group includes URL in the tab to a URL shortener that redirects the user extensions that provide some utility to users—such as to the same merchant page but with the affiliate identifier refreshing pages automatically every few seconds, or included in the URL, thereby stuffing a cookie into the changing the theme of popular sites like Facebook—but user’s browser. This extension abuses 40 different mer- do not inform users of the extension author profiting from chants, again including Amazon. the user’s web browsing. Generally, these activities in- This approach has the advantage that it capitalizes on volve monitoring visited URLs for merchant sites where organic traffic to merchant sites, which can make fraud the extension can earn a commission and modifying the detection difficult because merchants see visit behavior outgoing requested URLs to include the affiliate ID, or highly similar to that they would otherwise see as a result by injecting iframe’s that include affiliate URLs. of legitimate affiliate referrals. For example, we found an extension named “*Split The second group of extensions includes extensions Screen*” (with 52K users) that allows users to show two that clearly state in their descriptions that the exten- tabs in a single window, while also stealthily monitoring sion monetizes the user’s online purchases—generally the URLs visited by the user. It then silently replaces the for charitable causes or donations to organizations. The requested URL with the affiliate’s URL for sites such as intent or legitimacy of such programs is difficult to ascer- amazon.com, amazon.co.uk, hotelscombing.com, tain. For example, the extension “Give as you Live” [8] hostgator.com, godaddy.com, and booking.com. has over 11K users, and forms part of a larger cam- For some merchants, it also sets the referrer header for paign [7] to raise funds for charities from user purchases outgoing requests to falsely imply a visit through the af- online. The extension works by adding a list of stores filiate’s site. The extension is able to make these changes for which the extension author has signed up as an affil-
10 650 23rd USENIX Security Symposium USENIX Association iate to the results of major search engines. It also adds a "content_scripts": [{ script on merchant sites such as amazon.co.uk to redi- "js":["BlobBuilder.js", ... ], rect users via its own URL. While it does bring legitimate "matches":["http://*/*", "https://*/*" ], and likely well-intentioned traffic to Amazon, the legiti- "run_at": "document_end" mate affiliates can lose out if users choose to read product }], reviews on affiliate sites and then make the purchase via "permissions":["http://*/*", "https://*/*", this extension. "*://*.facebook.com/", In fact, a plethora of extensions exists allowing users "tabs", "cookies", "notifications", to donate to charity simply by shopping online. An- "contextMenus", "webRequest", ...], other such extension uses webRequest permissions to modify the requested URL to the affiliate URL, includ- Figure 3: Permissions and content script excerpts from ing over-writing the existing affiliate URL. While this the manifest for an extension that spams on Facebook clearly constitutes cookie-stuffing, the extension adver- and creates Tumblr accounts. tises itself as “Help support our charity by shopping at amazon.co.uk”.3 abuse social networks, reporting that thousands of users 5.3 Information Theft had installed extensions from the Chrome Web Store that spam on Facebook [4]. Information theft clearly reflects malicious behavior that We found a number of extensions that post spam mes- has the potential to harm the user in a number of ways, sages and use other features provided by social networks, from disclosing private information to financial loss. such as the ability to upload and comment on photos or This broad category of abuse in many ways replicates query the social graph. When we execute these exten- the functionality of some malware families. Within the sions with Hulk, the HoneyPage features allows the ex- browser, we observe stealing of: keypresses, passwords tensions to create elements and insert them into the DOM and form data, private in-page content (e.g., bank bal- tree. While we do not typically inspect the visual results ances), and authentication tokens such as cookies. We of our executions, in one case we observed an extension do not include extensions that simply re-use existing au- creating div elements to mimic Facebook status updates thentication tokens already present, such as extensions and inserting them into a page. The HoneyPage acted as that spam on social networks; we discuss these in Sec- a sink for the spam status messages resulting in a page tion 5.4. full of spam for the infected user. One example of keylogging we found in the Chrome One extension of interest, WhasApp (a name closely Web Store, “Chrome Keylogger”, is an experimental ex- resembling the popular WhatsApp, a mobile chat appli- tension from researchers [14] that is now removed. Key- cation), has since been removed from the Chrome Web loggers use content scripts to register callbacks for key Store, but we also found evidence of the same extension press events, recording the pressed key by using the mes- being sideloaded from malware. The extension targets saging API to communicate with a background page. both Facebook and Tumblr. At Facebook, the extension The background page then queues up data to send to a uploads images to Facebook and then comments on them remote server. This behavior has similarities with that with messages containing URLs. In some cases the links of extensions that steal form data, although the specific are used to spread the malicious extension to a wider au- event handlers differ. Both form field theft and keylog- dience, while other URLs sought to monetize users as ging require the extension to specify a content script but part of a spam campaign to advertise products. At Tum- do not require other permissions. blr, the extension creates new Tumblr accounts and veri- fies them in the background. 5.4 OSN Abuse The manifest file contains permissions and content scripts that request broad access, as shown in Figure 3. Online social network abuse constitutes the final cate- The extension is in fact over-privileged, since the exten- gory of prevalent malicious extensions we found. These sion in fact does not use some of the API permissions extensions typically target Facebook, and spread via both the manifest includes. Prior work has identified over- the Chrome Web Store and sideloading. These exten- privileging as not uncommon, even among benign ex- sions use existing authentication data to interact with tensions [13]. Figure 3 shows the extension specifically the APIs and websites of online social networks. Previ- requesting access for permissions and content scripts ous work identified and reported Chrome extensions that on facebook.com in addition to all other sites, which 3 The extension creator also helpfully marked the JavaScript code provides a hint as to the sites targeted. To carry out that adds the affiliate identifier as something to obfuscate in the future. spamming on Facebook and Tumblr account creation,
11 USENIX Association 23rd USENIX Security Symposium 651 the extension actually only requires the use of content 7 Limitations scripts. The abusive component of the extension is 15 lines of JavaScript that downloads a much larger remote Our system uses dynamic analysis for analyzing exten- JavaScript file containing the spamming functionality. sions, and, as with every dynamic analysis system, the correct classification of an extension relies on triggering the malicious activity. Hulk employs HoneyPages and event handler fuzzing on the extension’s web request lis- 6 Recommendations teners to enhance dynamic analysis, but does not provide a complete view of extension behavior. For example, In this section, we frame changes to make Chrome’s ex- we do not attempt to address cloaking that loads differ- tension ecosystem safer. Extensions should not have the ent code based on the client’s location or time. We also ability to manipulate browser configuration pages, such will not observe behavior that depends on specific tar- as chrome://extensions, that govern how users man- gets, such as those that require user interaction with a age and uninstall extensions. Extensions should also not visited page to take effect. Similarly, pages that require be allowed to uninstall other extensions unless they are sign-in pose difficulties. Hulk has a pre-set list of sites from the same author or a trusted source (such as Google and credentials to use while visiting pages, but does not or Antivirus vendors). We also recommend preventing perform account creation on the fly. extensions from manipulating HTTP requests by remov- Hulk’s Honeypages do not currently support multi- ing security-related headers that compromise the secu- step querying of DOM elements. While we can place rity of web pages. This change will require modifica- elements in the DOM tree that an extension looks for, if tions to several extension APIs to comprehensively ad- the extension expects elements to have additional prop- dress this issue, the primary one being webRequest. erties in order to trigger its malicious behavior, we will To address cloaking and other changes in remotely in- fail to adapt to the extension’s expectations. We plan on cluded content, we suggest that Google should encour- improving HoneyPages to support multi-step querying, age local inclusion of static files in the context of a and for many element types and attributes this appears web page. Chrome supports pushing automatic updates possible. of extensions to users, so remotely including additional We currently also lack data flow analysis in the JavaScript code is not necessary to support rapid changes Chrome browser, a feature that would substantially im- in an extenion’s code. This change will make it possi- prove the depth of behavior available for analysis. One ble to have a more complete analysis of extension behav- example where this would prove particular useful regards 4 ior, since the analysis engine—Hulk or otherwise —will keystroke interception. Without data flow tracking, we have the complete extension code available. To encour- cannot automatically derive whether this information ul- age developers to write completely self-contained exten- timately becomes transmitted to a third party via a net- sions and not load additional code from the network, one work request. could introduce a new policies, such as: if an exten- Another difficult concern for Hulk is analysis eva- sion loads code from a remote site, it loses permissions sion by extensions that specifically look for HoneyPages. such as the ability to inject that new code into the visited A determined adversary with knowledge of the system pages. could try to evade Hulk by querying for random elements Finally, extensions should not have the ability to hook in the DOM tree first, and, if found, avoid malicious ac- all keyboard events on a given site. The window.onkey* tivity. A similar type of evasive behavior arose for in API that exists in JavaScript has utility for pages that submissions to Wepawet [17]. One way to counter this is want to intercept the keyboard events of their users, but in by introducing non-deterministic HoneyPages for which the context of extensions it provides too much power. An DOM tree queries only succeed with a given probabil- experimental API (chrome.commands) exists that allows ity. We could further enhance this approach by crawling extensions to register keyboard shortcuts; this strikes us a few million sites and building models of the existing as a step in the right direction, as this covers the common elements to assign apt probabilities weights for different use-case for requiring access to these events. queries. This approach may also require analysis of an These suggestions will not eliminate malicious exten- extension’s DOM queries in case the extension repeat- sions, but can prevent classes of attacks, and significantly edly performs these in an effort to detect randomized facilitate the analysis of extensions. queries. Finally, we can consider measuring code cov- erage to examine the impact that each DOM query has on the amount of code executed by an extension, as the 4 In particular, ultimately an extension store operator such as Google needs to undertake such analysis as part of its curation of the extension will skip executing the malicious code when it store contents. detects the presence of an analysis system.
12 652 23rd USENIX Security Symposium USENIX Association 8 Related Work 9 Summary
In this paper we presented Hulk, a system to dynamically Browser extensions have been available for Internet Ex- analyze Chrome browser extensions and identify mali- plorer and Firefox for over a decade. As a result of cious behavior. Our system monitors an extension’s ac- a study of vulnerabilities in Firefox extensions, Barth tions and creates a dynamic environment that adapts to an et al. designed an extension architecture that promotes extension’s needs in order to trigger the intended behav- least privilege and isolation of components to prevent ior of extensions, classifying the extension as malicious a compromised extension from gaining full access to a or benign accordingly. In total, we identified 130 ma- user’s browser [5], an architecture subsequently adopted licious and 4,712 suspicious extensions that have up to by Google Chrome. Since then, further work has exam- 5.5 million browser installations, many of which remain ined the success of the Chrome extension architecture live in the Chrome Web Store. Based on these results, at preventing damage [6] and the ability of developers we developed a detailed characterization of the malicious to correctly request privileges for their extensions [13]. behavior that we found, targeted at determining the moti- Similar studies have examined the Firefox extension sys- vation behind the extension. Finally, we propose several tem to limit the potential damage arising from exploita- changes for the Chrome browser ecosystem that could tion of extension vulnerabilities, and to improve the de- eliminate classes of extension-based attacks and aid with fenses the browser provides [27]. These works have a analysis. focus mostly tangential to our work, since the principle of least privilege does not prevent an overtly malicious extension from executing malicious code. Acknowledgments
The security industry has documented malicious ex- We would like to thank our shepherd David Evans for his tensions in ways similar to malware reports and other insightful comments and feedback. We would also like to new threats [2, 4]. Liu et al. examined Google Chrome thank Niels Provos, Adrienne Porter Felt, Nav Jagpal and extensions and, based on malicious extensions the au- the rest of the Safebrowsing team at Google for their in- thors built, suggested refined privileges to make detect- sight and discussions throughout this project. This work ing malicious extensions easier [21]. In our work, we was supported by the National Science Foundation under build a system that performs dynamic analysis and clas- grants 0831535 and 1237265, by the Office of Naval Re- sification of extensions, and present an analysis of mali- search (ONR) under grant N000140911042, the Army cious extensions that we found in the wild. Research Office (ARO) under grant W911NF0910553, JavaScript-based program analysis has particular by Secure Business Austria and by generous gifts from promise for benefiting our work, and in light of our cur- Google. Any opinions, findings, and conclusions or rec- rent limitations we will be exploring techniques that we ommendations expressed in this material are those of the can adapt to improve our system’s detection capabili- authors and do not necessarily reflect the views of the ties. Research has applied information flow analysis to sponsors. Firefox extensions [10], performed taint-based tracking of untrusted data within the browser [11], used sym- References bolic execution to detect vulnerabilities [26], applied static verification to extensions [16], contained exten- [1] Anubis — Malware Analysis for Unknown Binaries. sions in privacy-preserving environments [20], and used http://anubis.iseclab.org/. supervised learning of browser memory profiles to detect [2] AMADEO, R. Adware vendors buy Chrome Ex- privacy-sensitive events [14]. tensions to send ad- and malware-filled updates. Our work has similarities to that of other malware de- http://arstechnica.com/security/2014/01/ tection and execution systems. While our implementa- malware-vendors-buy-chrome-extensions-to- tion and requirements significantly differ from systems send-adware-filled-updates/, Jan 2014. that execute Windows binary malware (such as Anu- [3] AMAZON. Associates Program Operating Agree- bis [1]), at a high level we share common goals of ex- ment. https://affiliate-program.amazon.com/ ecuting and extracting data from samples. Like Anu- gp/associates/agreement/, 2012. bis, Wepawet, the GQ honeyfarm, and other malware [4] ASSOLINI, F. Think twice before installing Chrome execution platforms, we share the difficult problem of extensions. http://www.securelist.com/en/blog/ triggering malicious behavior in a synthetic environ- 208193414/Think_twice_before_installing_ ment [9, 19]. Other research in this area has focused Chrome_extensions, Mar 2012. on classification and discerning malware from good- [5] BARTH, A., FELT, A. P., SAXENA, P., AND BOODMAN, ware [24]. A. Protecting Browsers from Extension Vulnerabilities.
13 USENIX Association 23rd USENIX Security Symposium 653 In Proceedings of the Network and Distributed System Se- Internet Measurement Conference (IMC) (2011), ACM, curity Symposium (NDSS) (2010). pp. 397–412. [6] CARLINI, N., FELT, A. P., AND WAGNER, D. An Evalu- [20] LI, Z., WANG, X., AND CHOI, J. Y. Spyshield: Pre- ation of the Google Chrome Extension Security Architec- serving privacy from spy add-ons. In Proceedings of the ture. In Proceedings of the USENIX Security Symposium Recent Advances in Intrusion Detection (RAID) (2007). (2012). [21] LIU,L.,ZHANG, X., YAN, G., AND CHEN, S. Chrome [7] CHARLES ARTHUR. Infographic: Internet shopping. Extensions: Threat Analysis and Countermeasures. In http://www.theguardian.com/technology/blog/ Proceedings of the Network and Distributed System Se- 2011/jul/04/internet-shopping-infographic- curity Symposium (NDSS) (2012). give-as-you-live-charity, 2011. [22] LUDWIG, P. No more silent extension installs. [8] CHROME WEB STORE. Give as you Live. https:// http://blog.chromium.org/2012/12/no-more- chrome.google.com/webstore/detail/give-as- silent-extension-installs.html, Dec 2012. you-live/fceblikkhnkbdimejiaapjnijnfegnii, [23] NIKIFORAKIS, N., INVERNIZZI, L., KAPRAVELOS, 2013. A., VAN ACKER, S., JOOSEN,W.,KRUEGEL, C., [9] COVA , M., KRUEGEL, C., AND VIGNA, G. Detection PIESSENS, F., AND VIGNA, G. You are what you in- and Analysis of Drive-by-Download Attacks and Mali- clude: Large-scale evaluation of remote JavaScript inclu- cious JavaScript Code. In Proceedings of the World Wide sions. In Proceedings of the ACM Conference on Com- Web Conference (WWW) (2010). puter and Communications Security (CCS) (2012). [10] DHAWAN, M., AND GANAPATHY, V. Analyzing Infor- [24] RAJAB, M. A., BALLARD, L., LUTZ, N., MAV RO M - mation Flow in JavaScript-Based Browser Extensions. In MATIS, P., AND PROVOS, N. CAMP: Content-Agnostic Proceedings of the Annual Computer Security Applica- Malware Protection. In Proceedings of the Network and tions Conference (ACSAC) (2009). Distributed System Security Symposium (NDSS) (2013). [11] DJERIC, V., AND GOEL, A. Securing script-based exten- [25] REDDIT. Reddit: I am One of the Developers of a sibility in web browsers. In Proceedings of the USENIX Popular Chrome Extension. . . . http://www.reddit. Security Symposium (2010). com/r/IAmA/comments/1vjj51/i_am_one_of_the_ [12] F-SECURE. Coremex innovates search engine hijack- developers_of_a_popular_chrome/, Jan 2014. ing. http://www.f-secure.com/weblog/archives/ [26] SAXENA,P.,AKHAWE, D., HANNA, S., MAO,F.,MC- 00002689.html, April 2014. CAMANT, S., AND SONG, D. A Symbolic Execution [13] FELT, A. P., GREENWOOD, K., AND WAGNER, D. The Framework for JavaScript. In Proceedings of the IEEE Effectiveness of Application Permissions. In Proceedings Symposium on Security and Privacy (2010). of the USENIX Conference on Web Application Develop- [27] TER LOUW, M., LIM, J. S., AND VENKATAKRISHNAN, ment (WebApps) (2011). V. Enhancing Web Browser Security Against Malware [14] GIUFFRIDA, C., ORTOLANI, S., AND CRISPO, B. Mem- Extensions. Journal in Computer Virology 4, 3 (2008), oirs of a browser: A cross-browser detection model for 179–195. privacy-breaching extensions. In Proceedings of the ACM [28] WANG, D., SAVAG E , S., AND VOELKER, G. M. Cloak Symposium on Information, Computer and Communica- and Dagger: Dynamics of Web Search Cloaking. In Pro- tions Security (ASIACCS) (2012), ACM. ceedings of the ACM Conference on Computer and Com- [15] GOOGLE. What are extensions? https://developer. munications Security (CCS) (2011), ACM, pp. 477–490. chrome.com/extensions/index, 2014. [29] WEST, M. An Introduction to Content Security Pol- [16] GUHA, A., FREDRIKSON, M., LIVSHITS, B., AND icy. http://www.html5rocks.com/en/tutorials/ SWAMY, N. Verified Security for Browser Extensions. security/content-security-policy/, 2012. In Proceedings of the IEEE Symposium on Security and Privacy (2011), IEEE, pp. 115–130. [17] KAPRAVELOS, A., SHOSHITAISHVILI, Y., C OVA , M., KRUEGEL, C., AND VIGNA, G. Revolver: An Auto- mated Approach to the Detection of Evasive Web-based Malware. In Proceedings of the USENIX Security Sym- posium (2013). [18] KAY, E. Protecting Chrome users from mali- cious extensions. http://chrome.blogspot. com/2014/05/protecting-chrome-users-from- malicious.html, May 2014. [19] KREIBICH, C., WEAVER, N., KANICH, C., CUI, W., AND PAXSON, V. GQ: Practical containment for measur- ing modern malware systems. In Proceedings of the ACM
14 654 23rd USENIX Security Symposium USENIX Association