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 throughobscurityI 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
Current thread:
- RE: (addendum) redirection vuln crawlers breed & security through obscurity Evans, Arian (Apr 20)