Critical Control 17:Penetration Tests and Red Team Exercises

Published: 2011-10-26. Last Updated: 2011-10-28 00:09:40 UTC
by Rick Wanner (Version: 1)

Another diary compliments of Handler in training Russ McRee:

Penetration testers and red teamers rejoice! We have a control for you: Critical Control 17: Penetration Tests and Red Team Exercises (hereafter referred to as PT & RT for brevity).

A few thoughts in support of your efforts:

1) Before taking on this activity, formalize it with management (in writing) to include vision, mission statement, and statements of work (SOW) in order to set clear expectations (and keep you from being fired or jailed). Prepare to write reports, and present findings. PT and RT activity is only as good as the dissemination of results and the subsequent remediation. Sure the fun part is going after systems and resources with permission, but the documented follow-up is just as important.

2) A formalized process inclusive of best practices and documentation also supports PT & RT on behalf of compliance requirements (PCI, etc.). Trust me when I say, it’s a lot easier to win the argument for a PT & RT program when you can tell your leadership that it supports meeting compliance requirements. Yes, compliance is often a “min bar” but if it helps get your program underway, you’re winning right?

3) A great resource and good starting point: Open Source Security Testing Methodology Manual 3.0

4) If you’re going to red team, then blue team while you’re at it. A well-devised, concerted offensive engagement against your enterprise is also an ideal opportunity for your defenders to validate their monitoring and hardening practices.

5) While it’s nice to have resident expertise, it’s hard to imagine that every organization has the resources to dedicate personnel exclusively to PT & RT, much as may be the case with dedicated IR resources. Often these duties fall on network engineers and systems administrators with a penchant for security. If so, great; how better to tune red team/blue team chops.

6) The social engineering (SE) aspect of PT & RT activity inevitably includes an organizational political component you should be sensitive to. I’ll cut to the chase, people fall for SE tactics all the time and there is always shame associated with it. Making enemies will not help your cause. Devise SE tactics (educational intranet sites, metrics generators) that don’t necessarily automatically relegate people to the wall of shame/sheep. If you must actually compromise someone, dot your I’s and cross your T’s. Non-invasive recon for likely or ideal targets for whom management signs off before total pwnzorship is in your best interest. Again, your get out of jail free card is very important here. Malfeasance or anomalous behavior from systems belonging to your “victims” can then potentially be attributed to you.

7) Virtual environments, while not ideal, make for an inexpensive test bed for PR & RT activity. Build attacker VMs (largely done for you; BT5 or Samurai WTF anyone?) and victim VMs (unpatched Windows, vulnerable LAMP, etc)

Have fun, but be careful.

What successes have you had structuring penetration testing and red teaming as a repeatable, sustained activity in your organizations? Let us know via the comment form.

-- Rick Wanner - rwanner at isc dot sans dot org - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

Keywords: Critical Controls CSAM Cyber Security Awareness Month 2011 NCSAM Penetration Testing

1 comment(s)

The Theoretical "SSL Renegotiation" Issue gets a Whole Lot More Real !

Published: 2011-10-26. Last Updated: 2011-10-26 14:02:09 UTC
by Rob VandenBrink (Version: 1)

6 comment(s)

For years, we have been taught (warned?) that establishing an SSL session consumes much more in the way of CPU resources than the actual sessions do, once established. We've also been warned that there is a theoretical vulnerability in SSL Renegotiation in many web server implementations. Combined, they make for a nice "it'd be bad if someone wrote such a tool" story in many security classes.

These two situations are evident in the specifications for SSL offload and Load Balancer devices, which are typically rated in "sessions established per second" rather than a total session count or data throughput value. It's also very much "in our face" when doing vulnerability assessments, when web server after web server comes back with a vulnerability named something like "SSL Renegotiation saturation" (or similar). We've been told, over and over, that there is a "theoretical" problem here, waiting for an exploit to happen.

Since there hasn't been much in the way of exploits in this area, efforts towards resolving the SSL Renegotiation problem haven't been on anyone's front burner. That's all changed now - THC (The Hackers Choice), has released another tool - THC-SSL-DOS. This tool targets the problem of SSL Renegotiation. With very limited bandwidth, a single host can DOS almost any vulnerable web server. Even offload devices such as load balancers are vulnerable (though more attacking hosts are required). In their release notes, THC makes the excellent point that the SSL renegotiation feature has never been widely used, and arguably should be simply disabled on almost all webservers.

Unfortunately, SSL Renegotiation is enabled by default on many servers, and we all know what happens with defaults - systems get installed with default settings, then NEVER get changed.

Just to emphasise the point, THIS IS NOT A NEW SECURITY EXPOSURE, it's simply a handy proof of concept tool to demonstrate a problem that's been hanging around for quite some time, hopefully with the goal (and with luck, the result) of getting this setting changed on vulnerable systems.

Take a peek at this new tool. Hopefully it will serve as a catalyst, proving that this is one setting that should be changed post-install. It'd be nice if the developers of affected web server applications would take this as a cue to modify their installation scripts to change the default value of this setting as well.

http://thehackerschoice.wordpress.com/2011/10/24/thc-ssl-dos/

http://www.thc.org/thc-ssl-dos/

===============

Rob VandenBrink
Metafore

Keywords: Renegotiation SSL THC

6 comment(s)

ISC StormCast for Wednesday, October 26th 2011 http://isc.sans.edu/podcastdetail.html?id=2089