Archive for the ‘Exploits’ Category

« Older Entries

Using Blended Browser Threats involving Chrome to steal files on your computer

Thursday, November 5th, 2009

=============================================

SECURETHOUGHTS.COM ADVISORY
- CVE-ID : CVE-2009-3931 (Chrome)
- Release Date : November 05, 2009
- CVSS Severity : 9.3 (High)
- Discovered by : Inferno

=============================================

I. TITLE
————————-
Using Blended Browser Threats involving Chrome to steal files on your computer

II. VULNERABLE
————————-
Chrome all versions < 3.0.195.32
Tests performed on v3.0.195.25

III. BACKGROUND
-------------------------
Google Chrome is a web browser released by Google which uses the WebKit layout engine and application framework. It is one of the four most popular browsers in the market today. Google released the entire source code of Chrome, including its bespoke V8 JavaScript engine as an open source project entitled Chromium, in 2008. Google Chrome is best known for its fast speed, simplicity and reliability.

IV. DESCRIPTION
-------------------------
Google Chrome has an inbuilt file downloader[1], just like every other browser. However, the behavior of this function is different from other browsers and provides users much more usability and convenience. Chrome automatically downloads a file from any site that is passed using the Content-Disposition header value “attachment” (on the contrary, all other browsers show a save as dialog). There are some mitigations done by Chrome to protect users from auto downloading malware by raising an alert on executable extensions such as .exe, .htm, .jar, etc.

The vulnerability arises from the fact that there are other extensions such as .svg, .mht, .mhtml that don’t exist in the Chrome’s malicious extension blacklist and hence the user never gets a warning message before they are auto downloaded to his or her computer. If these downloaded files are clicked from the Chrome’s download bar or Windows Explorer (which the user is highely likely to click considering his or her trust in Chrome that it warns for malicious extensions), they will automatically get opened in other browsers and can be used to steal any file on the user’s computer.

The reason for the name “Blended Browser Threats” is because here, Google Chrome is used as a vehicle for attack, whereas the real vulnerability executes inside other browsers such as IE6, Safari on your computer. The vulnerability is not directly exploitable in IE6, Safari since an evil site cannot automatically download content on your computer without your permission. Another important point to note here is you might not be using the browsers IE6, Safari and instead using Chrome. But clicking a particular file on Chrome’s download bar can make it automatically open in IE6, Safari. See the proof of concept examples below.

V. PROOF OF CONCEPT
————————-
1. The MHT, MHTML (MIME HTML) file format is used by Internet Explorer to embed all external resources, usually images, in a single document. Basically, whenever you click “Save As” on a web page, this is the default format used to save it. So, MHT, MHTML files gets automatically opened in IE when clicked. The exploit I want to discuss is interesting in the context of IE6 (estimated to be installed on roughly 25% of the computers). For other newer versions like IE7, IE8, the user is explicitly prompted about the danger of executing javascript and hence much harder to exploit.

An evil site opened inside Chrome can automatically download a MHT/MHTML file to your computer. If the user clicks on this downloaded file from the Chrome’s download bar or opens this file through Windows Explorer, it gets automatically opened in IE6. The malicious script executes and can be used to send any of your local files to a remote evil destination. Ex: Click on this link-

/security/chromelocalfilexss/chromedownload.php?fname=WATCHMENAKED.mhtml

Chrome File Downloader Exploit - Steal Local Files with help from IE6

2. The SVG(Scalable Vector Graphics) file is a registered extension in some Safari versions and hence a SVG file gets automatically opened in Safari. If you ever had an older version of Safari on your computer, this extension will be most probably there in your registry. Hence, it does not matter what your current version of Safari is (and you may very well be using the latest version of Safari). So the exploit works like this:

An evil site opened inside Chrome can automatically download a SVG file to your computer. If the user clicks on this downloaded file from the Chrome’s download bar or opens this file through Windows Explorer, it gets automatically opened in Safari. The malicious script executes and can be used to send any of your local files to a remote evil destination. Ex: Click on this link-

/security/chromelocalfilexss/chromedownload.php?fname=WATCHMENAKED.svg

Chrome File Downloader Exploit - Steal Local Files with help from Safari

3. An evil site opened inside Chrome can automatically download inappropriate content such as a por_ographic image to your computer. Ex: Click on this link-

/security/chromelocalfilexss/chromedownload.php?fname=WATCHMENAKED.jpg

Chrome File Downloader Exploit - Push Por_ographic Image

VI. FIX DESCRIPTION
————————-
Google Chrome Team fixed this vulnerability by appending these dangerous extensions such as .mht, .mhtml, .svg, etc to already existing extension blacklist.
Check out the fixes done in Chromium Source Code here [2,3].

Chrome Team is also actively looking how to improve this mechanism in the long run, but because of the need to maintain compatibility with certain existing uses, this needs to be done carefully.

VII. SOLUTION
————————-
Chrome: Upgrade to latest version of Google Chrome (v3.0.195.32 or higher). If you remain connected to the internet, this should be automatic.

The more secure solution is to configure your browser to prompt you explicitly before downloading any file type. This can be done by going to Chrome Configuration Options -> Under the Hood -> Check the ‘Ask where to save each file before downloading‘ flag.

VIII. References
————————-
1. Downloads: Downloading a file – Google Chrome Help
http://www.google.com/support/chrome/bin/answer.py?hl=en&answer=95759

2. Google Chrome Code Fix 1
http://codereview.chromium.org/243115

3. Google Chrome Code Fix 2
http://codereview.chromium.org/261022

4. Interesting Reads – thanks to Michal.
(a) Security in Depth: Local Web Pages – Adam Barth
http://blog.chromium.org/2008/12/security-in-depth-local-web-pages.html

(b) Same-Origin Policy:Browser Security Handbook – Michal Zalewski
http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy

IX. CREDITS
————————-
This vulnerability is discovered by
Inferno (inferno {at} securethoughts {dot} com)

X. DISCLOSURE TIMELINE
————————-
Oct 5, 2009 12:14 AM: Vulnerability reported to Google Security Team.
Oct 6, 2009 11:19 AM: Automated Response from Google Security Team.
Oct 6, 2009 01:46 PM: First Status update provided by Michal Zalewski. Vulnerability confirmed.
Oct 6, 2009 11:33 PM: Second Status update provided by Michal Zalewski. Code Fix 1 checked in by Adam Barth.
Oct 8, 2009 12:30 AM: Code Fix 2 checked in by Adam Barth.
Nov 5, 2009 01:18 PM: Chrome v3.0.195.32 Released containing the Security Patch.

I would like to thank Michal Zalewski and Adam Barth from Google for their prompt responses and getting the patch ready in a timely manner. It was a pleasure working with them. I am grateful to Google for providing credit for my research by listing me on their “We Thank You” Page.

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , ,
Posted in Browsers, Exploits, WebAppSec | 3 Comments »

Hijacking Opera’s Native Page using malicious RSS payloads

Wednesday, October 28th, 2009

Well, this one is a continuation of my previous post on Cross Site Scripting issues relating to RSS feed readers. In that post, I mentioned Scenario (3), but didn’t discuss any details or PoC since Opera Team was actively fixing it. This issue is now fixed in the latest security update v10.01 from Opera Team.

In this exploit, an attacker uses a maliciously crafted RSS payload to achieve full control over the Victim’s Opera Browser. The attack works by convincing a user to visit a RSS feed link. When the user opens the url in Opera, there are two things that take place. The first one being Javascript in various RSS feed entries gets executed in the context of the calling site. This part was discussed in the previous post and can be used to execute XSS in the context of that site. The second thing that occurs is the untrusted rss feed content lands up in the Opera’s Feed Subscription Page (also the reason for this post). Since this is a native page, it runs in a higher privileged zone than the internet zone (something similar to chrome:// in Firefox and Chrome).

So, if you find a way to execute your malicious javascript in the feed subscription page, you can essentially execute native opera functions and ultimately use it to control the Victim’s Opera browser. It looks like Opera’s Team did think about the implications of putting untrusted user content in this page and hence only permitted a certain whitelist of html tags. In addition, for some html tags such as “A” and “IMG”, it required certain preconditions to be met. See the code snippets captured using Opera inbuilt debugger DragonFly (you can also use Firebug lite).

Whitelisted HTML Tags Definition – Opera Feed Subscription Page (Source – DragonFly)

Opera Feed Subscription Page Source in DragonFly - Part 1
HTML Tag Sanitizer/Filter Function – Opera Feed Subscription Page (Source – DragonFly)

Opera Feed Subscription Page Source in DragonFly - Part 2

If you had tried the simple xss attacks like <img src=”x:x” onerror=”some javascript”/> or something like <a onmouseover=”some javascript”>link</a>, these won’t work here (hint: check out preconditions defined above). It is important to understand what you are attacking and if read this code, you will figure out what constitutes a valid malicious payload that will evade this filter or sanitizer on the Opera Subscriptions Page.

So, here is an example PoC exploit code which executes the opera.feeds.subscribeNative function to automatically register a feed in Opera browser without user consent.

/security/rssatomxss/opera10exploit2.atom
(Tested on Opera 10.00 Stable Build 1750)
Automatic Feed Registration without User Consent

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , ,
Posted in Browsers, Exploits, WebAppSec, XSS | 5 Comments »

Exploiting Chrome and Opera’s inbuilt ATOM/RSS reader with Script Execution and more

Tuesday, September 15th, 2009

Update: I missed pointing out the cutting edge research done by Robert Auger in this area back in 2006. [1,2]. Also, Michal Zalewski has written about the RSS and ATOM vulnerabilities in the comprehensive Browser Security Handbook. Definitely check these links out.

=============================================

SECURETHOUGHTS.COM ADVISORY
- CVE-ID : CVE-2009-3263 (Chrome)
- Release Date : September 15, 2009
- Severity : Medium to High
- Discovered by : Inferno

=============================================

I. TITLE
————————-
Exploiting Chrome and Opera’s inbuilt ATOM/RSS reader with Script Execution and more

II. VULNERABLE
————————-
Chrome all versions – 2 and 3 (< 3.0.195.21)
Opera all versions - 9 and 10.

III. BACKGROUND
-------------------------
Back in 2006, there was interesting research done by James Holderness[1] and James M. Snell[2] which uncovered a variety of XSS issues in various online feed aggregator services (e.g. Feed Demon). The vulnerability arises from the fact that it is not expected of RSS readers to render scripted content. I want to extend that research by doing threat analysis on inbuilt feed readers offered in most modern browsers. I have found Google Chrome (v2,3) and Opera (v9,v10) to be vulnerable, while Internet Explorer(v7,8), Firefox 3.5 and Safari 4 are resilient to the exploits mentioned below.

IV. DESCRIPTION
————————-
Google Chrome and Opera’s inbuilt RSS/ATOM Reader renders untrusted javascript in an RSS/ATOM feed.

Exploit Scenarios

  1. Scenario 1 –
    1. Attacker social engineers a victim user to visit a rss/atom feed link pointing to his or her evil site.
    2. Victim uses Google Chrome / Opera browser to view the feed.
    3. Malicious javascript gets executed on victim’s browser. Examples
      1. Modifies into a phishing page and asks user credentials for subscribing to Google Reader / My.Opera.com
      2. Searches user’s browser history for visited url list [3]
      3. Scans user’s internal network with/without javascript [4]
  2. Scenario 2 –
    1. Both attacker and victim user have an account to a trusted website.
    2. Either
      1. The trusted web site lets the attacker inject JavaScript content into any section of the site’s RSS or an Atom feed.
    3. OR
      1. The trusted website uses blacklist to block known executable file types for scripted content. E.g. html, jsp, etc.
      2. Attacker uploads a file with extension .rss/.atom/arbitary extension preceded by .rss/.atom [e.g. .atom.tx]. Most widely used Apache web server passes Content-Type as “application/{atom/rss}+xml” for all the three cases automatically in default configuration.
      3. Attacker convinces victim to visit the direct link to uploaded file.
      4. Victim’s cookies and other sensitive data gets sent to attacker’s site.
      5. Note: For Internet Explorer (v7,8), the task is easier because it does automatic mime type detection. So, you can execute javascript content in any file extension. E.g. click /security/rssatomxss/anyfile.tx. However, for other browsers, Firefox 3.5, Safari 4, Opera 10 and Chrome 3, they don’t support this functionality (perhaps for security reasons). So, using such extensions mentioned above can be used as a workaround for script execution in Opera and Chrome browsers.
  3. Scenario 3 –
    1. Similar to Scenario 1, but exploit can be used for complete control over feeds in the Opera browser.

V. PROOF OF CONCEPT
————————-

  1. Exploit Scenario 1 [Testcases - 18 XSS for Chrome, 38 XSS for Opera] –
    1. Chrome: /security/rssatomxss/googlechromexss.atom [or .rss]
    2. Opera: /security/rssatomxss/opera10xss.atom [or .rss]
  2. Exploit Scenario 2 –
    1. Include all in Scenario 1
    2. Opera: /security/rssatomxss/opera10xss.atom.tx [Any arbitary file extension at. E.g .tx, .tm]
    3. Chrome: /security/rssatomxss/googlechromexss.atom.tx [Any arbitary file extension at. E.g .tx, .tm]
  3. Exploit Scenario 3 –
    1. Details and PoC will be released after patch is provided by Opera Security Team in next minor release.

For research purposes, you can try out the PoCs on these virtualized (and vulnerable) versions of various browsers, without installing any bits on your computer [5].

VI. FIX DESCRIPTION
————————-

  1. Chrome: ATOM/RSS feed rendering is completely disabled by forcing a text/plain MIME type [6]. If you need feed rendering, a good alternative is FeedBurner which protects from any script execution attacks by blocking them at time of the feed registration.
  2. Opera: Scenarios (1) and (2) will not be fixed, as it is a design feature. Scenario (3) will be patched in next minor release.

Google Chrome before fix –
Google Chrome - 18 XSS issues in ATOM/RSS Reader

Google Chrome after fix –
Google Chrome after fix - Stops rendering dynamic content

Opera before fix –
Opera - 38 XSS issues in ATOM/RSS Reader

Opera After Fix –
Still the same. Only Scenario (3) will be fixed.

VII. SOLUTION
————————-
Chrome: Upgrade to latest version of Google Chrome (v3.0.195.21 or higher). If you remain connected to the internet, this should be automatic.
Opera: Wait for upcoming patch for Scenario (3) in next minor release (non-alpha/beta) of Opera 10 [Opera 9 users need to upgrade]. However, you will still continue to be vulnerable to script execution.

VIII. REFERENCES
————————-
1. Attack Delivery TestSuite – James Holderness
http://intertwingly.net/blog/2006/08/09/Attack-Delivery-TestSuite

2. Feed Security – James M. Snell
http://www.snellspace.com/wp/?p=448

3. CSS History Hack – Jeremiah Grossman
http://jeremiahgrossman.blogspot.com/2006/08/i-know-where-youve-been.html

4. Browser Port Scanning without Javascript – Jeremiah Grossman
http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html

5. Downloading Xenocode’s “sandboxed” applications – Wladimir Palant
http://adblockplus.org/blog/downloading-xenocode-s-sandboxed-applications

6. Google Chrome Fix Details
http://code.google.com/p/chromium/issues/detail?id=21238

IX. CREDITS
————————-
This vulnerability is discovered by
Inferno (inferno {at} securethoughts {dot} com)

X. DISCLOSURE TIMELINE
————————-
Sep 7, 2009 12:09 PM: Vulnerability reported to Google and Opera Security Teams.
Sep 7, 2009 12:10 PM: Automated Response from Google Security Team.
Sep 7, 2009 03:49 PM: First Status update provided by Google Security Team. Quick response for a Holiday.
Sep 8, 2009 01:09 AM: First Status update provided by Opera Security Team. Vulnerability concluded as design feature.
Sep 8, 2009 03:28 PM: Vulnerability confirmed by Google Chrome Security Team. Patch timelines provided.
Sep 9, 2009 07:39 AM: Second Status update provided by Opera Security Team. Asked for exploit possibility for certain scenarios.
Sep 10, 2009 01:33 AM: Third Status update provided by Opera Security Team. Vulnerability confirmed for new provided testcases.
Sep 15, 2009 01:31 AM: Final Status update provided by Opera Security Team. Scenario (3) will be fixed, while Scenarios (1), (2) will not be.
Sep 15, 2009 03:04 PM: Patch released by Google Security Team in v3.0.195.21.
Sep XX, 2009 XX:XX XX: Patch planned by Opera Security Team for next minor release.

I would like to thank Chris Evans from Google Chrome Security Team and Sigbjørn Vik from Opera Security Team for their prompt responses, engaging in insightful discussions and getting the fix ready in a timely manner. It was a pleasure working with them.

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , , , ,
Posted in Browsers, Exploits, WebAppSec, XSS | 5 Comments »

« Older Entries