> Within 15 minutes of > manual testing we found the web server to be vulnerable to both the UTF-8 > and double decode vulnerabilities. The reason for this was simply that the > tools (which I will not name) presumed that Windows NT is always installed > in a directory called winnt, when in this case it was installed in a > directory called winnt40. This was enough to throw the automated tools way > off of the scent. Which is a great argument for vulnerability assessments. Yes, many tools are scriptable, but even Nessus doesn't go as far in Win32 environments as you _can_ go with the right tools. Generally (and in order to set the playing field here) a pen test is done in the blind, or with very little information. The more prior knowledge a pen tester has, the less 'fair' the test is going to be. However, the lack of prior knowledge can extend the time of the pen test, depending on what was contracted. Vulnerability assessments are done internally, with the full cooperation of the admins. This means interviews of key personnel, and consultants have admin accounts in the domain in order to run their tools (NOTE: Observing closely how the admin account is set up and then taken down will tell the consultant quite a bit about the organization). Given that, information such as which directory NT or 2K is installed in will be available on a per-machine basis. I've written tools like this, it's not all that difficult. > Also, what about custom CGIs, ASPs etc, they may be vulnerable to /../ > attacks, SQL injection etc etc, but there isn't (to my knowledge) any 100% > sure fire reliable way to test for these automatically in this scenario. To > do the test properly you need to apply the methodology to the custom > environment. Or do a code review. Doing a code review in a test environment allows the consultant to test and verify his findings before presentation. Very few systems are set up identically, so a vulnerability in a script may mean one thing to one infrastructure, quite another to someone else. > I think a more suitable question is why would you pay a 'Consultant' good > money to hit a big green go button and print the results? You don't. A drunken monkey can do this (I've seen it! Just kidding...sorry, KoKo). But that is what many organizations do. It's not up to the consultants to meet an arbitrary standard based on someone else's moral code...they're in it for the money, and have a business model to follow. It's up to the company who hires and ultimately pays for the consultant to vet these organizations and find one that is suitable. One way of doing it is to ask the consulting firm for references...but they'd be fools to give you negative references, wouldn't they? So when you're talking to them, find out what their model is, how they go about doing things. In the end, it's a crap shoot, really. That's b/c whatever the sales guy tells you in your meetings, there is no legal requirement that the deliverable be anything but an ISS report printed on company letterhead. The key differentiator is analysis...how does one measure that before hand? ---------------------------------------------------------------------------- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/
This archive was generated by hypermail 2b30 : Mon Sep 10 2001 - 08:09:09 PDT