Home page logo
/

bugtraq logo Bugtraq mailing list archives

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

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 () securityfocus 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 () securityfocus com
websecurity () webappsec 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 () fishnetsecurity com [email]

http://www.fishnetsecurity.com



-----Original Message-----
From: Ivan Sergio Borgonovo [mailto:mail () webthatworks it] 
Sent: Saturday, April 15, 2006 7:47 AM
To: bugtraq () securityfocus 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




  By Date           By Thread  

Current thread:
  • RE: (addendum) redirection vuln crawlers breed & security through obscurity Evans, Arian (Apr 20)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]