Message-ID: <8654C851B1DAFA4FA18A9F150145F9250621BC3F@FNEX01.fishnetsecurity.com>
Date: Wed, 19 Apr 2006 14:48:46 -0500
From: "Evans, Arian" <Arian.Evans@...hnetsecurity.com>
To: "Ivan Sergio Borgonovo" <mail@...thatworks.it>,
	<bugtraq@...urityfocus.com>
Subject: RE: redirection vuln crawlers breed & security through obscurity


1. This is definitely a pretty common, if not well-known
problem, being "broken access control" that relies on
obscurity or something weak/trivial to forge (like an
HTTP refer field path) to control access to an entry
point in a webapp. Sometimes, no further authorization
checks are made (on pages/functions behind the entrypoint).

2. Tools already exist that allow you to manually ignore
redirects per your question blow, and some do this automatically.
www.owasp.org and www.webappsec.org are good places to start.

3. This said, "how secure?" in this case is a math problem.
Given you know the directory structure, if all you are doing
is trying to brute-force enumerate the file name, then all
you have is a fuzzing problem plus HTTP requests/sec rate
(that is realistic to achieve).

If your admin default page is "supersexysecretsignon.php"
I can turn a fuzzer lose on this until I get an HTTP 200 OK,
or a change in body content, and automatically flag the page.

In the case above, I have 21 characters to fuzz plus an
page extension, so (21^27 * [$.extensions]) to work through.

I could fuzz *everything* or be lazy and fuzz a variable
and tack on a list of say 10 well-known extensions to each
iteration of the variable.

Assuming I do not know the page name, let's take 50 chars
ASCII/numeric, assume it is case-sensitive on *nix, so you
would have 50^64 possible combinations starting at "a".
Then multiply that times the number of extensions you want
to try, unless you want to fuzz those characters too.

How fast you could work through that keyspace is a good
question. I recommend you Google for Mike Shema's work
on session token entropy from RSA '05 and later, and
he has excellent tables on 'n' HTTP/req/sec = $work_time
to exhaust a given keyspace, which is exactly what you
are essentially asking here I believe.

Excellent questions, again. Two good mailing lists to ask
these sorts of questions on are:

webappsec@...urityfocus.com
websecurity@...appsec.org

Double-check my math. I haven't my coffee today, adding
to my native processor's already unfortunate tendency to
introduce random floating-point error into my ad-hoc calculations,

Arian J. Evans
FishNet Security

Note: Microsoft Office breaks text-based emails by default.
To see text messages properly formatted, turn off:
Tools>Options>|Email Options|+Remove Extra Line Breaks

816.421.6611 [fns office]
816.701.2045 [direct]
888.732.9406 [fns toll-free]
816.421.6677 [fns general fax]
913.710.7085 [mobile] <--best bet
aevans@...hnetsecurity.com [email]

http://www.fishnetsecurity.com



> -----Original Message-----
> From: Ivan Sergio Borgonovo [mailto:mail@...thatworks.it] 
> Sent: Saturday, April 15, 2006 7:47 AM
> To: bugtraq@...urityfocus.com
> Subject: redirection vuln crawlers breed & security through obscurity
> 
> 
> I just came across such kind of code (php) written by a colegue:
> 
> //header.inc
> if($_SESSION['UN']!='hardcoded_UN' or $_SESSION['UN']!='hardcoded_PW')
> 	header("Location: ./login.html");
> //missing else to mitigate the problem!!
> //HTML stuff here...
> 
> code structure of all the other "supposed to be" private pages is:
> 
> //wannabeprotected.php
> include_once("include/header.inc")
> //wannabe protected code
> 
> Everything resides at something like:
> http://site/admin/
> 
> of course the ONLY thing you've to do to break into the admin 
> interface is:
> - disable redirection in your preferred browser (w3m)
> - guess the right address and
> - point exactly to it: http://site/admin/index.php or any 
> existing page[1] eg. http://site/admin/killingmesoftly.php
> 
> http://site/admin/ won't work. I did some research to see if 
> you could find a way to make "educated guess" by examining 
> the flow of HTTP responses, but I didn't came out with any 
> good idea. Nevertheless index.php doesn't seem to be a bad 
> educated guess (as Default.asp, index.asp, index.pl, login.asp...).
> 
> Now some questions and a proposal:
> - how safe is to rely on secrecy of the URL? I'm looking for 
> a quantification of the risk, not a "it is a bad idea" ;)
>  of course http://site/`pwgen -N1 30`/`pwgen -N1 30`.php is 
> safer than http://site/admin/index.php. Any already made 
> study? numbers?
> - are SE like google going to index such kind of pages if 
> there is no "external" link[*]?
> - are there already many specialized vuln crawlers looking 
> for such kind of URLs?
> 
> What about building crawlers that ignore redirection to scan 
> for such kind of vulns?
> I think that kind of mistake should be pretty popular.
> 
> Did I reinvent the wheel?
> 
> [1] this makes educated guessing easier increasing the number 
> of potential targets: manager.php, insert.php, delete.php and 
> it makes this [in]security model rely just on the dir path... 
> unless the programmer is so crazy to call all his files with 
> random names. But coding the access credential in a path 
> makes the code not that relocable... etc... etc..
> 
> [*] What I mean: it exists a chain of links that connect that 
> page with a link on a homepage or an already indexed page.
> 
> BTW the colegue didn't set any association between .inc and 
> the php interpreter. So you can even get the header.inc 
> source with another maybe harder educated guess.
> 
> ... and happy Easter holidays.
> 
> -- 
> Ivan Sergio Borgonovo
> http://www.webthatworks.it
> 

Powered by blists - more mailing lists