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:
40 threads per machine
2 machines (split keyspace /2)
DS/3 (not bandwidth limited)
We try 10 basic extensions (.pl, .asp, aspx, etc.)
8^37*10= 5.14227283 × 10^24 years
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:
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
Thanks for all the polite responses to my muddling!
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
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
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]
888.732.9406 [fns toll-free]
816.421.6677 [fns general fax]
913.710.7085 [mobile] <--best bet
aevans () fishnetsecurity com [email]
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
I just came across such kind of code (php) written by a colegue:
//missing else to mitigate the problem!!
//HTML stuff here...
code structure of all the other "supposed to be" private pages is:
//wannabe protected code
Everything resides at something like:
of course the ONLY thing you've to do to break into the admin
- 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 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
- 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?
 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
- RE: (addendum) redirection vuln crawlers breed & security through obscurity Evans, Arian (Apr 20)