chrisj wrote:I guess what I meant, was don't go running rough shod over things because they know you're there. Try not to be noisy enough that the skiddie down the street is missed in the logs, don't go filling the logs, don't purposely trip IPS/IDS because they know you're there, etc.
Chris, I do want to make it clear that my response really wasn't directed at you specifically. I respect you a great deal, and that was just kind of a random trigger for getting on my soap box. I see a lot of people talking about being covert and stealthy simple because that's how they see an ideal attack, not because it's actually practical or beneficial to either party in the context of a professional service.
sil wrote:...typical awesomeness...
That was the exact response I was expecting from you. I'm sorry to make you type all that out; I should have had the courtesy to write that for you
I don't think we're disagreeing as much as you think though. I think we agree that:
- Stealth is ideal
- Some actions can be noisy while simultaneously generally being considered "safe"
- ANY SINGLE PACKET can result in a DoS condition regardless of how "safe" it is; weird/rare/untested/unsupported configurations can cause a service/system to shrivel up and die from a typically innocuous action (i.e. banner grab)
- Do not be reckless, impersonate a script kiddie (or as you prefer, script kiddiot, which indeed has a much higher lol-factor), or intentionally cause a DoS condition (unless specifically requested)
I've been meaning to ask you this for awhile, but I am curious to know the scale of one of your typical penetration tests. I can tell it's (sadly, for me) worlds different than the work I've previously had the opportunity to do (a previous employer limitation that I'm actively remedying by branching out on my own).
For example, I remember the thread when someone asked where they should start. I responded with Windows targets since the majority of small-medium businesses use that, which would make it a good place to start and work your way up. You posted a link to NetCraft and essentially said, "Solaris and Oracle, obviously. That's what Fortune XXX companies use."
While that (obviously unintentionally) made me feel like a total noob, I'm still undecided if I completely agree. I certainly understand the argument, but at the same time, it'd also be difficult for someone with no, or little, experience to land such a gig. I'm still leaning in the direction I originally took for someone who's just starting out simply because it's the most available/accessible place to get your foot in the door and build from.
While I'm on the subject, I guess I'd like to also know where you started professionally and how you got to where you are now. I know you've been tinkering with everything forever, but how did you specifically go from a hobbyist to a moderately experienced professional to working on such massive projects (i.e. Solaris Admin to testing Solaris systems)?Wow, tangent. Did I take my Concerta this morning? I honestly can't remember... not a good sign...
Getting back on track, I've worked with customers that I know either certainly do not have controls such as IPSes, or have explicitly created an exception for me because they want to genuinely test the underlying configuration and not risk something being omitted because it was blocked (which would be another interesting practice to debate another time), and in these circumstances, an obsessive level of stealth simply has no benefit.
To further exemplify the atmosphere of some of the other environments I've been in, I've also found about 200k SSNs on anonymous FTP (it's an easy backup server, right?) and a SQL Server (blank SA) within about 15 minutes of being on-site (separate occasions/customers).
I've also been stifled by IPSes while working externally (which is why a VPS is great for double-checking) and dealt with aggressive NACs while on-site. I totally appreciate the circumstances where stealth is valuable.
The point I was ultimately trying to get across is that I think you should discuss these types of things with your customer thoroughly during the scoping stage and agree on an approach that is the most beneficial for those specific circumstances. This may be irrelevant in the upper echelons, but I genuinely see it as worthwhile with smaller, less sophisticated customers (as I noted earlier, when you're starting out).
Back to the OP, I think his wanting to demonstrate a deficiency in the authentication system is a perfect example of where stealth is irrelevant. Now, we can argue semantics and say that's an application test and not a penetration test, which is a fair point. You may equate that more to something like fuzzing, which again, is rarely, if ever, stealthy and basically pounds on the target until it breaks.
There are two miscellaneous final points I want to make. First, if you're going in blind (black box), you should obviously assume such controls are in place and attempt to fly under the radar. Second, I highly encourage everyone to fully understand the impact of their actions and learn how to perform such activities in a covert manner. It will make you better, and even if that knowledge is not relevant to the specific task at hand, it most definitely will be in the future.
This was all part of my plan when I started this thread
Ah, a mastermind...
The day you stop learning is the day you start becoming obsolete.