Date: Wed, 19 Apr 2006 17:46:17 -0500
From: "Evans, Arian" <Arian.Evans@...hnetsecurity.com>
To: <bugtraq@...urityfocus.com>
Subject: RE: (addendum) redirection vuln crawlers breed & security through obscurity


A couple folks have emailed me now and pointed out that
I made this sound too trivial, which I probably did, so
let me add something more concrete:

Here's a simpler fuzzing example:

::Assumptions::

40 threads per machine
2 machines (split keyspace /2)
DS/3 (not bandwidth limited)
80 req/sec
288,000 req/hour

unknown target-->admin123.asp
We try 10 basic extensions (.pl, .asp, aspx, etc.)

8^37*10= 5.14227283 × 10^24 years

http://www.google.com/search?hl=en&lr=&q=8+%5E+37+*+10+%2F+288000+%2F+8765+%2F+2&btnG=Search

So, not necessarily trivial, though in practice I find
I can optimize based upon observed naming conventions,
file system (e.g.-allowed char sets), etc. I again
recommend Shema's RSA presentations as highly relevant.

I did not add the obvious non technical risk scenario,
but one I think most of us have seen, which is like the
original posting where /admin is "hidden" under a:

/really/long/obscure/path/name/like/this.asp

Then when the business unit lays off their developers
and outsources webapp dev, you now have something like
25 developers * number of people they drink Guiness with,
whom all know the "secret obscure path" to /admin.
And anyone with read access to wwwlogs.

I'm sure there are many more scenarios than I can
envision, but the math/brute force one was the only
one I could think of to answer the original request
for "quantification".

Thanks for all the polite responses to my muddling!

YMMV,

-ae

> -----Original Message-----
> From: Evans, Arian 
> Sent: Wednesday, April 19, 2006 2:49 PM
> To: 'Ivan Sergio Borgonovo'; 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