1 / 33

Hulk: Eliciting Malicious Behavior in Browser Extensions

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

derora
Download Presentation

Hulk: Eliciting Malicious Behavior in Browser Extensions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Hulk: Eliciting Malicious Behavior in Browser Extensions AlexandrosKapravelos◊,Chris Grier†*, NehaChachra‡, Christopher Kruegel◊,Giovanni Vigna◊,VernPaxson†* ◊UC Santa Barbara, †UC Berkeley, ‡UC San Diego*International Computer Science Institute 23rdUSENIX Security Symposium (Aug., 2014)

  2. Outline • Introduction • Background • Architecture • Results • Profiting from maliciousness • Recommendations • Related work

  3. Introduction • All major web browsers today support broad extension ecosystems that allow third parties to install a wide range of modified behavior or additional functionality. • Some browsers have online web stores to distribute extensions to users. • In this paper, we examine extensions for Google Chrome that are designed with malicious intent.

  4. Background • Google Chrome supports extensions written in JavaScript and HTML (distributed as a single *.crxzip file). • Each extension contains a (mandatory) manifest that describes the permissions the extension uses and the list of resources that the browser should load. • The permission system determines which sites an extension can access, the allowed API calls, and the use of binary plugins.

  5. Installing extensions • Extensions can be installed via the official Chrome web store, by user manually, or sideloaded by third-party programs. • Chrome version 25 (Feb.,2013) included changes to prevent silent installation of Chrome extensions, requiring user confirmation. • Chrome version 35 (May, 2014) took further steps to prevent sideloading by requiring all installed extensions to be hosted in the Chrome Web Store.

  6. Extension permissions • Chrome requires extensions to list the permissions needed to access the different parts of the extension API. • webRequest: Allows the extension to "observe and analyze traffic and to intercept, block, or modify requests in- flight"

  7. Extension permissions (cont.) • content_scripts:Indicates JavaScript files that will run inside of the web page. • background: Allows extensions to run scripts in a background page. • content_security_policy: Extensions can use the same syntax to express their CSP in the manifest file.

  8. Architecture • Hulk dynamically loads extensions in a monitored environment and observes the interaction of extensions with the loaded web pages. • Using a set of heuristics to identify potentially dangerous behavior, it labels extensions as malicious, suspicious, or benign. • Automatically install extensions and instrument activity during web browsing using an instrumented browser.

  9. URL extraction • Look for URLs in the manifest, and search for URLs in the source code as well. • Also, visit a set of popular websites which may targeted by the malicious plugin.

  10. HoneyPages • Some extensions activate based on the content of a web page instead of the URL. • HoneyPages contain JavaScript functions that overload built-in functions that query the DOM tree of the web page. • If the extension queries an iframe DOM element with the intention to alter it, then the HoneyPage will create an iframe element, inject it in the DOM tree, and return it to the extension.

  11. Event-based execution • HoneyPages will not trigger callbacks for network events that require special properties, such as a specific URL or HTTP header. • By invoking all event callbacks that an extension registers in the chrome.webRequest API with mock event objects and pointing to a background HoneyPage, we can monitor changes extensions attempts to make.

  12. Monitoring hooks • An extension can use the Chrome extension API to perform actions not available to JavaScript running in a web page. • We leverage the current logging infrastructure offered by Chrome for monitoring the activity of extensions.

  13. Content scripts • By intercepting all additional code introduced by the extension in the context of the visited page, we can monitor if the extension fetch remote scripts.

  14. Network logging • Request URLs may be computed in at runtime. • We use a transparent proxy that intercepts all browser HTTP and DNS traffic to log the requests made during extension execution.

  15. Detecting malicious behavior • Extension API: • Uninstalling other extensions • Preventing uninstallation of the current extension(blocking chrome://extensions) • Manipulating HTTP headers by eemoving security-related HTTP header, such as Content-Security-Policy or X-Frame-Options is classified as malicious.

  16. Detecting malicious behavior • Interaction with visited pages: • Malicious extensions may perform sensitive information theft using JavaScript. (Example: JavaScript keylogger) • Injection of remote JavaScript content is classified as suspicious.

  17. Network level • Request errors (suspicious). • May be used for drive-by downloads. • Modification of HTTP requests(malicious). • Common seen on shopping-related extensions. • Detect header modification by comparing packets received by the OS and by the browser.

  18. Injected Content Analysis • The injected script runs in the context of the visited page and thus has full access to its DOM tree. • By using HoneyPages, we can understand the injected scripts’ intentions. • For example, if the injected code looks for a form field with the name “password,” it is classified as malicious.

  19. Results • Two sources of extensions: • The official Chrome Web Store (totaling 47,940 extensions) • Extensions sideloaded by binaries. (392 unique extensions)(Anubis) • Hulk labeled 130 as malicious and 4,712 as suspicious. • Benign extensions do not differ significantly from permissions requested by malicious/suspicious ones.

  20. Results

  21. Permissions used • Most commonly used permissions:

  22. Permissions used • 18,313 extensions that use host permissions to restrict on which pages the extension can use the privileged chrome.* API. • Extensions typically request broad permissions using wildcards in URL patterns.

  23. API calls • Top 15 Chrome Extension API calls made during by extensions during the experiments.

  24. Network level • Using network activity alone we identified 24 malicious extensions. • By removing HTTP response headers like Content-Security-Policy, the malicious extensions can inject JavaScript into pages • For example, there are multiple variants of an active extension on the Chrome Web Store called “Cheat in your favorite games” (20k users).

  25. Extension management • Several extensions on the Chrome Web Store prevent uninstallation. • “HD Video Player” (7,173 users). • “SmartScreenVideo Plugin” (11,012 users). • “No Tab Left Behind” (only 8 users)(false positive).

  26. Code injection • More than 3,000 extensions that dynamically introduced remotely-retrieved code either through script injections or by evoking eval. • An extension named “Bang5TaoShopping assistant” (5.6M users) injects code into every visited page.

  27. Profiting from maliciousness • Ad Manipulation: • The addition of new ads as well as the replacement of existing ads or identifiers with the same size images. • “SimilarSites Pro” (1.8M users), used obfuscated scripts to replace ads (728x90) in popular websites. • Other similar scripts, all under a company called “SimilarGroup.”

  28. Profiting from maliciousness • Affiliate Fraud: • Many major merchant web sites such as amazon.com, godaddy.com, and ebay.com run affiliate programs. • Affiliate programs usually associate a cookie with the user’s browser. • Malicious extensions do “cookie stuffing” — a technique that causes the user’s browser to visit the merchant URLs without the user clicking on affiliate URLs. • “*Split Screen*” (52K users), sets the referrer header for requests. • “Give as you Live” (11K users), however, is a charity campaign.

  29. Profiting from maliciousness • Information theft • Online social network abuse: • Extensions use existing authentication data to interact with online social networks. • “WhasApp”, an extension spams Facebook and Tumblr, sideloaded by malware.

  30. Recommendations • Extensions should not have the ability to manipulate browser configuration pages, such as chrome://extensions. • Extensions should also not be allowed to uninstall other extensions. • Extensions should not be allowed to remove HTTP security-related headers. • Extensions should not have the ability to hook all keyboard events on a given site.

  31. Limitations • Hulk uses dynamic analysis for analyzing extensions. • Can not address cloaking that loads different code based on the client’s location or time. • Can not observe behavior that depends on specific targets. • Hulk’s HoneyPagesdo not currently support multistep querying of DOM elements.

  32. Related work • Anubis, malware analysis for unknown binaries. • Further work has examined the success of the Chrome extension architecture at preventing damage and the ability of developers to correctly request privileges for their extensions. • Current permission system does not prevent an overtly privileged malicious extension from executing malicious code. • Adware vendor may purchase an extension, update it with malicious one.

More Related