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 > > >
