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@xxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxx
> websecurity@xxxxxxxxxxxxx
>
> 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@xxxxxxxxxxxxxxxxxxx [email]
>
> http://www.fishnetsecurity.com
>
>
>
> > -----Original Message-----
> > From: Ivan Sergio Borgonovo [mailto:mail@xxxxxxxxxxxxxxx]
> > Sent: Saturday, April 15, 2006 7:47 AM
> > To: bugtraq@xxxxxxxxxxxxxxxxx
> > 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
> >
>