We are living in an age defined by SPEED. We look always for shortcuts, faster ways, and faster solutions in order to save our time. Supposing most of the people use browser extensions because they are too lazy to download and install a software with the same functions as the extension, or they want to save some time or because they just discovered a faster way to explore lots of features in a short time, I will continue the talk about the danger behind browser extensions. 2. What are these extensions? Firstly chrome extensions are NOT browser plugins, they are browser add-ons, HTML5 applications that enrich the browser’s user experience. By installing these extensions, you give your browser additional functionality (mail notification, ad blocking, online bookmarking, developer tools, page recommendation, notebooks, and so on). 3. Why are they so interesting as a subject of research? Google chrome extensions are basically HTML applications, so they suffer for the same vulnerabilities as usual websites but the difference between extensions and websites is the fact that an extension requires higher level access privileges. For example, in theory, extensions can read and write all the cookies so they are a good to start a hijacking attack. They can even change your proxy settings, block requests that your browser is trying to send over HTTP or HTTP, can take screenshots of websites and so on. Knowing this I figured why the extensions are so popular, we should take a closer look and try to avoid the bad things extensions can bring. 4. How are they built? Basically they are a bunch of files (HTML + JS + CSS ), zipped and signed with a developer key, (just like a usual mobile application) packaged into a CRX file.. 5. How we can install these things? We can install the extensions more or less from the Chrome Web Store, also we can install them from some 3rd party websites or just manually by dragging the extension CRX file intothe chrome extensions page and hit the install option. 6. Extension Components Extensions have a few distinct components: -Manifest File –similar like most mobile applications, this file lists all the components embedded and defined by the application permissions. Manifest files are just a simple JSON file, containing the name of the extension, description, permissions and one of more important sections is “content_scripts” Example of Manifest File
-matches is a regular expression which defines on which website the extension or the content script going run. So as long the URL matches the settings in the extension, the browser will load up the content script. -Content Scripts – on presented example we have jquery-1.8.1 and content.js as content scripts -View Pages – this component is related to the user interface. Extensions can have a little button on the right top bar of browser interface, also can have a options page, usually loaded as a pop-up, where we are able to adjust extension functionalities. To make things more complicated, extensions have some background pages that runs constantly in a hidden mode and lives inside the browser session. So as long as you can execute code in that domain, the background page is persistent.
– NPAPI Plugins (optional) – some extensions also bundle NPAPI plugins which are simple binary code compiled for the architecture of the browser. The Code running in an NPAPI plugin has the full permissions of the current user and is not sandboxed or shielded from malicious input so we must double check the source of the extensions that use NPAPI before installing and using them. 7. Security – How secure are the extensions we use? First let’s take a look at how all these components talk to each other. The first part, Content Script, runs in a context or in origin of the webpage that is been displayed, so of course it can access the actual DOM elements. It can modify the DOM to enrich the website (for example, to capture all the images or to insert some additional toolbars and so on). It uses the standard JavaScript DOM access like HTML property, document cookies or document title. So this is a way of exchanging information between the website and a part of the extension greater than the content script. BUT at the same time, the content script cannot stock the information directly to the JavaScript already running. Also it cannot call functions, it cannot be called from the original website so there is a security boundary here. Content Script also has access to the part of the extension that is able to submit AJAX requests which is much powerful because it’s a cross domain, so it can get the response back. View Pages, can communicate with the Content Script and vice versa only by sending messages and receiving responses (similar with HTML5 post messages API). No direct functions calls, no DOM access just exchanging messages. BUT View Pages in a background page can instantiate new content scripts which is a form of an evil because, you can directly pass the code as a string parameter here and it will get evaluated as a content script in the context of the webpage that has been viewed. View and Background Pages are the only components of a Google Chrome extension which has access to this powerful extension API and represent the hard stuff of an extension because using this API, the extension can change proxy settings, monitor requests, access cookies in open tabs, take screenshots of open websites and access the data that you pasted in your clipboard. Also the background pages by default can call NPAPI plugins. 8. Permissions listed upon installation
Similar of what mobile applications on most platforms do, Extensions have Permissions which are displayed to the user and requires user agreement. 9. Attacking Extensions So, extensions are HTML applications and there are a lot of them. We also know that one of most dangerous HTML vulnerabilities is XSS. View page DOM XSS was a really, really bad thing last year and after some research I discovered a lot of extensions vulnerable to DOM XSS. Basically, when you design web applications, no matter if they are chrome extensions or websites it’s easier to write a vulnerable code. Than a safe one. 10. How does a typical XSS take place? In this article I will focus on vectors employing a malicious website. The model is users have a vulnerable extension installed and visit a malicious website which tries to exploit the extension. Here’s a small example: Supposing we have a payload in a webpage DOM, let’s say it’s in the title of a bookmarking extension. Acting as the extension somehow, the user interface attaches by clicking on a button that the extension has provided in the website. Of course the content script fetches the payload from the DOM into its own variable, and then the extension forwards it to the View page by sending a message with the title of the page the user wants to bookmark. Then the View Page does its logic and decides to display the title of the website back. So we will have a malicious webpage bookmarked, a classic DOM XSS vulnerability. [plain]
This is not a DOM XSS just in just a website, actually it’s an XSS in a view page of an extension so it will get access to all API’s that the extension was permitted to access. The XSS can be really simple, running on the background and just accessing the evil function and executing it. 11. NPAPI Binary code vulns Are far scarier but not that common it’s when you have NPAPI plugin and binary code vulnerabilities inside. Usually looks like this: Malicious payload in a DOM > gets transferred to the content script > then transferred to the view page and then the view page accesses the method that is exported by NPAPI plugin. NPAPI plugins are simply binary code so as long they have some binary vulnerabilities like command injection or buffer overflow or format string vulnerabilities, we can exploit it, from the webpage. The interesting thing is the code executed in NPAPI plugin runs with just user permissions. 12. Tools for exploiting Chrome extensions -BeFF – Fake Flash Update Module – is basically a very good tool to exploit XSS. -XSSchef – Chrome extension Exploitation Framework What can you actually do (when having appropriate permissions)?
Monitor open tabs of victims
Execute JS on every tab (global XSS)
Extract HTML, read/write cookies (also httpOnly), localStorage
Get and manipulate browser history
Stay persistent until whole browser is closed (or even futher if you can persist in extensions’ localStorage)
Make screenshot of victims window
Further exploit e.g. via attaching BeEF hooks, keyloggers etc.
Explore filesystem through file:// protocol
Bypass Chrome extensions content script sandbox to interact directly with page JS
-Mosquito – Chrome Extension exploitation tool Mosquito is a Google Chrome extension exploitation tool allowing an attacker to leverage XSS found in extension content script, to issue arbitrary cross-domain HTTP requests with victim browser (and victim cookies). With this tool attackers can exploit content-script XSS vulnerabilities in extensions based on manifest v1 and v2. Mosquito requires also –MalaRIA (JDK to compile) -websockify (Python and some libs to run it) -a confirmed content-script XSS vulnerability in Google Chrome extension CONCLUSION: Extensions are vulnerable as well and exploiting them give more powers so double check if the extension you need will not pwn your ass! References:
- Developer chrome – extensions
- Developer chrome – tutorials
- Advanced Chrome extension exploitation – whitepaper Tools:
- BeFF – fake flash update module
- XSSCHEF – Chrome extension exploitation framework
- Mosquito – Chrome extension exploitation tool
