Posts Tagged ‘Javascript’

« Older Entries

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 http://securethoughts.com/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: http://securethoughts.com/security/rssatomxss/googlechromexss.atom [or .rss]
    2. Opera: http://securethoughts.com/security/rssatomxss/opera10xss.atom [or .rss]
  2. Exploit Scenario 2 –
    1. Include all in Scenario 1
    2. Opera: http://securethoughts.com/security/rssatomxss/opera10xss.atom.tx [Any arbitary file extension at. E.g .tx, .tm]
    3. Chrome: http://securethoughts.com/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 »

Bypassing OWASP ESAPI XSS Protection inside Javascript

Thursday, August 20th, 2009

Everyone knows the invaluable XSS cheat sheet maintained by “RSnake”. It is all about breaking things and features all the scenarios that can result in XSS. To complement his efforts, there is an excellent XSS prevention cheat sheet created by “Jeff Williams” (Founder and CEO, Aspect Security). As far as I have seen, this wiki page provides the most comprehensive information on protecting yourself from XSS on the internet. It advises using the OWASP ESAPI api to mitigate any XSS arising from untrusted user input.

I was evaluating this ESAPI api and the recommendations given on the wiki to see if there are any potential flaws. Any weakness impacts a very large number of users since many developers are using it to strengthen their web applications throughout the world. This is my way of contributing back to the community, but can never match the immense efforts put by Jeff and other OWASP team members in developing this library.

I want to give you a little bit of background before diving into the real vulnerability. The XSS prevention cheat sheet classifies XSS protections by dividing them into broadly four buckets – HTML Body injection, HTML Attribute injection, Javascript injection and CSS injection. For each of these four buckets, there is an ESAPI function reference you can use for output escaping/encoding.

If you allow any untrusted user input into javascript functions document.write() OR eval(), it can still execute the XSS even after you do the scrubbing using the ESAPI encodeForJavaScript() function. The reason being that hex escaped chars are converted back into normal chars at the time of execution of these functions.

Here is the proof of concept jsp code:

<%@page import="org.owasp.esapi.*"%>

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
   "http://www.w3.org/TR/html4/loose.dtd">

<html>
    <head>
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
        <title>ESAPI XSS Protection Bypass</title>
    </head>
    <body>
        <h1>ESAPI XSS Protection Bypass</h1>
        <p id="tb1"/><br>
        <p id="tb2"/>
        <script>
            //in real scenario, these three strings come from request.getParameter or user input
            <%
                String vulstr1 = "-1';alert(0);";
                String vulstr2 = "<img src=x onerror=alert(1)>";
                String vulstr3 = "0,x setter=alert,x=2";
            %>   

            // you can safely use it in places like this
            // Ex. vulstr1 is completely encapsulated in a and alert(0) not executed.
            var a='<%= ESAPI.encoder().encodeForJavaScript(vulstr1) %>';
            alert(a);

            // However, you can bypass protection in places like these
            // Ex. vulstr2 gets written to html and alert(1) executes
            document.write("<%= ESAPI.encoder().encodeForJavaScript(vulstr2) %>");
            // Ex. part of vulstr3 get assigned to u, rest alert(2) executes
            eval("u=<%= ESAPI.encoder().encodeForJavaScript(vulstr3) %>");
        </script>
    </body>
</html>

Much thanks to Jeremiah Grossman and Jeff Williams for taking the time to review my idea and providing their insights. Jeremiah told me that he has seen such injections from time to time at WhiteHat and these do exist in the wild.

Jeff confirmed that some documentation changes will fix this. I agree that no esapi code change is required, because function themselves are not insecure.

But, if you are currently using esapi functions inside your javascript code, it is important that you re-review your javascript code and the places where your make calls to esapi functions.

If you use the esapi function encodeForJavaScript() inside document.write, it is advised that you change them with other appropriate esapi functions depending on the context where the data is ultimately landing. For example, if you have document.write(“<script>alert(‘XSS’)</script>”), you know the data is landing in html body context, so it is appropriate to use encodeForHTML() wrapper. Using user input inside eval is less common, but more disastrous. The reason for this is you can still begin another command context using , and (space) char and it won’t be encoded by function encodeForHTML(). So, it is better to avoid putting user input inside eval.

Any more suggestions or discussion on fixes is highly welcome.

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

Tags: , , , ,
Posted in Exploits, Solutions, WebAppSec, XSS | 10 Comments »

Hijacking Safari 4 Top Sites with Phish Bombs

Tuesday, August 11th, 2009


Music: Bomfunk MC’s – Super Electric

Well, this one is an interesting issue I found while evaluating Safari 4 Beta (v528.16). This is not your usual XSS or CSRF bug which requires a site vulnerability, but a persistent browser backdoor that impacts all Safari 4 users using versions 4.0.2 and below. I was pretty amazed at some of the new features offered by the latest version of Apple’s browser, especially the hyped Top Sites and Cover Flow. I decided to hack this cool feature. Here is what i found.

=============================================
SECURETHOUGHTS.COM ADVISORY
- CVE-ID : CVE-2009-2196
- Release Date : August 11, 2009
- Discovered by : Inferno
=============================================

I. TITLE
————————-
Hijacking Safari 4 Top Sites with Phish Bombs

II. VULNERABLE
————————-
Safari 4 all versions < 4.0.3
Platforms affected - Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5.7, Mac OS X Server v10.5.7, Windows XP and Vista

III. BACKGROUND
————————-
Safari is a web browser developed by Apple Inc. It is the default browser in Mac OS X v10.3 and higher. Safari for the Microsoft Windows platform first released on 11 June 2007 and currently supports both Windows XP and Windows Vista. The current stable release of the browser is 4.0.3 for Mac OS X and Windows. (Source – Wikipedia).

Safari 4 introduced the Top Sites feature to provide an at-a-glance view of a user’s favorite websites. It is the most hyped feature of Safari 4 and widely used by users to quickly jump to their frequently used sites which can include their banks, email accounts, shopping sites, etc.

IV. DESCRIPTION
————————-
It is possible for a malicious website to place arbitrary sites into your Top Sites view through automated actions. The attack technique makes use of javascript windows where in a small window is used to repeatedly browse to different sites that the attacker wants to add in your Top Sites list. This window is completely hidden using the window.blur function and user won’t know that is happening in the background. Please note that this attack is not possible using invisible iframes as Safari does not use iframe urls to decide Top Sites content.

Once the attack completes execution, the small window gets closed and the next time you use Safari Top Sites, it will be have the attacker’s defined sites replace your existing legitimate sites. To make this decision of which sites to replace with, an attacker can first use the CSS History Hack found by Jeremiah Grossman[2] and then accordingly set fake sites relative to those user’s visited websites. Hence, this could easily facilitate a serious phishing attack. The situation is worsened by the Safari’s inadequate protection against URL obfuscation attacks as highlighted in [3], which makes it almost impossible for a regular user to spot the fake site and differentiate it from a legitimate one.

V. PROOF OF CONCEPT
————————-
http://securethoughts.com/b/q.htm
The PoC currently runs in under a minute, which is based on most conservative input parameter values.

The two input parameters in this attack are the number of times the fake website should be visited (n)(default=28) and timeout(t)(default=2 sec) that triggers a switch between two fake websites. It is very simple and adds two fake websites for bankofamerica.com and gmail.com to your top sites. (it does not check your browser history, but that is left as an exercise for the reader :) ). Also, you might have to increase the parameter value of ‘n’ if you visit your favorite sites very often.

A real-world hacking scenario would look like:

1. Attacker injects malicious javascript on
(a) His or her evil site OR
(b) On a legitimate site which allows javascript (e.g. bulletin boards, dashboards, etc).

2. Victim visits the above site.

3. Malicious javascript runs and first checks browser history (using CSS history hack[2]) from a list of Alexa Top 500.

4. Attacker replaces the user’s visited sites with fake phishing sites (makes legitimate sounding names with url obfuscation).

5. Every time user opens a phishing site and gets a login page, user’s credentials gets stolen. Attacker will present a login error message, asking user to try again later. At the same time, attacker will reset that phishing site back to the legitimate page. This way, user will never know what happened.

6. On another note, attacker can always keep atleast 1 or 2 phishing websites at all times in Top Sites. This will help the attacker to maintain persistent control of a user’s session and every time user visits a new site, it will be detected by the attacker and will be replaced by a phishing site in Top Sites.

Apple Safari 4 Top Sites Spoofing

VI. FIX DESCRIPTION
————————-
This issue is addressed by preventing automated website visits from affecting the Top Sites list. Only websites that are manually entered in the url address bar are considered to be placed in the Top Sites view.

VII. SOLUTION
————————-
Upgrade to Safari 4.0.3.

Apple security updates are available via the Software Update mechanism:
http://support.apple.com/kb/HT1338

Apple security updates are also available for manual download via:
http://www.apple.com/support/downloads/

VIII. REFERENCES
————————-
1. Apple Security Updates
http://support.apple.com/kb/HT1222

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

3. Phishing with URL Obfuscation continues in Safari 4
http://securethoughts.com/2009/06/phishing-with-url-obfuscation-continues-in-safari-4/

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

XI. DISCLOSURE TIMELINE
————————-
May 21, 2009: Vulnerability discovered by Inferno.
May 21, 2009: Apple contacted.
May 21, 2009: Automated response from Apple.
May 26, 2009: First response from Apple Security Team.
Jun 03, 2009: First Status update provided by Apple.
Jun 27, 2009: Second Status update provided by Apple.
Jul 24, 2009: Coordinated public release of Advisory with Apple.
Aug 11, 2009: Software Update and Public Advisory issued by Apple.

I would like to thank Apple Security Team for their timely responses, understanding the high severity of this issue and releasing a patch in a reasonable time period.

Both Chrome and Opera browsers offer similar features, but are not impacted by this vulnerability. Chrome only allows manually typed urls in the address bar to go into the “Most Visited” start page, whereas Opera requires a user to explicitly add his or her favorite web page as a speed dial entry. IE does not have this feature, so is unaffected by this.

I met several interesting people at BlackHat and Defcon this year from Apple, Microsoft, WhiteHat, SecTheory, McAfee, Paypal, etc. One of the folks i met was Daniel Herrera from SecTheory. He told me some of the research he had been doing, one of which was a similar anomaly in Top Sites. He was very happy to know that Apple is fixing this issue. In the near future, he will share with us his cool ideas. This includes some of the vulnerabilities he is working on for Opera.

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

Tags: , , , ,
Posted in Browsers, Exploits, Phishing | 7 Comments »

« Older Entries