Ethical Hacking and Penetration Testing

Discussion on ethical hacking and penetration testing subjects.

InfoSec Institute's most popular information security and hacking training goes in-depth into the techniques used by malicious, black hat hackers with attention getting lectures and hands-on lab exercises . While these hacking skills can be used for malicious purposes, this class teaches you how to use the same hacking techniques to perform a white-hat, ethical hack, on your organization. You leave with the ability to quantitatively assess and measure threats to information assets; and discover where your organization is most vulnerable to hacking in this network security training course.

Some of the instructor-led hands-on hacking lab exercises in this security training experience:

* Capture the Flag hacking exercises every night
* Abusing DNS for host identification
* Leaking system information from Unix and Windows
* Stealthy Recon
* Unix, Windows and Cisco password cracking
* Remote buffer overflow exploit lab I - Smashing the Stack
* Remote buffer overflow exploit lab II - Integer Overflows
* Remote heap overflow exploit lab III - Beyond the Stack
* Desktop exploitation
* Remote keylogging
* Data mining authentication information from clear-text protocols
* Remote sniffing
* Breaking wireless security
* Malicious event log editing
* Transferring files through firewalls
* Hacking into Cisco routers
* Harvesting web application data
* Data retrieval with SQL Injection Hacking
* Calculating the Return on Investment (ROI) for an ethical hack

Click here to learn more about the most hands-on Ethical Hacking course ever!

Monday, October 31, 2005

Penetration Testing Methodology: Fact or Fiction?

I had a blog reader over the weekend shoot me an email asking me about my opinion on what the best penetration testing methodolgy is. I've performed a couple of hundred penetration tests, and I can say that over the last couple of years I've been exposed to (maybe I should say subjected to?) about a dozen different methodologies at different points in time. (BTW: If you have something you'd like me to write about, I'm open to suggestions!) I've seen both in-house and "industry standard" methodologies. If you aren't familiar with penetration testing methodologies, the idea behind them is that the penetration tester should follow a pre-scripted format for orchestrating the test as dictated by the methodology. Here are some of the 3 popular ones that come to mind:


NIST 4-Stage Pen-Testing Guideline
FoundStone's Pen-Testing Methodology

Now, what the reader was hoping for was a succinct, clear cut, answer. "Go here, download this, print it out, done, etc.". As you might have already guessed, I'm not going to give that level of satisfaction. And, I'm asked this question almost weekly, so now I'll be able to point people to this blog posting for the long winded answer. Ok, on to the answer.

In a nutshell, I firmly believe that any penetration testing methodology, no matter how well thought out, has limited usefulness. Why? Well the goal behind penetration testing is to try to find as many serious vulnerabilities as possible. In order to do this, you must develop the "mindset" of your attacker. You should look at your assessed system or application in all of the possible ways you think it could be misued, abused and exploited. You should then take a break, drink some well-deserved coffee, and then think of entirely new "misuse cases" for the system under review. Using a cut and dry methodology runs counter to the basic and essential premise of penetration testing; that a penetration test is an exercise in system abuse and cannot be readily scripted.

I realize that if you have never performed a penetration test, and don't have the faintest idea where to begin, you might get some value of out a methodology. However, I would venture to say that your time would be better spent hacking away on some dedicated lab equipment, writing your first Metasploit module, or writing a proposal for your boss to send you to a decent penetration testing course.

I also realize that the other (and in my eyes, more legitmate) reason to use a penetration testing methodology is the CYA factor. Most managers don't like the idea of employees willy-nilly hacking into things. The idea that an "industry standard methodology is being applied in accordance to best practices" sounds a lot better to the person in the corner office. Then, the methodology becomes more of a documentation tool, which I do see real value in.

Before I get too positive on documentation, remember what we have seen with vulnerability scanners. Generating lots of documentation can equally as dangerous. Everyone knows what has happened in the last 5 years with "vulnerablity assessment reports" generated out of nessus/internet scanner/etc. We all know the process:

1. Your boxes are rooted by 16 yr old dude in norway, he uses them to serve phising bait to 100 million paypal users.
2. High priced consultants run nessus for you, charge your company $50,000, take you out for drinks one night, generate a monster 500 page report.
3. So many false positivies and false negatives in the report no real vulns are ever acted on
4. Next month the same kid has your Oracle production E10000 serving PsyBNC to half of the norweigan underground.

Documentation can be paralyzing. It can be useless and point people down the wrong path, with end effect of people losing faith in the entire assessment process.

To sum up: Don't use a methodology unless you need to for documentation purposes, if you do, make sure the reports you generate deliver actionable intelligence on the security posture of the asssessed system.




  • At 6:29 PM, hubab said…

    i'm doing a term paper about prot scanning. so i was wondering if you can tell me about the ethical problems behind port scanning.thanx

  • At 6:47 AM, PacketPunk said…

    I totally agree with you that a pentest methodology is good in the eyes of managers and it is comforting for the client to know we follow some industry standard, it can also helps pentester to not forget something out from the report.

    With that said, I really prefer to go "by the flow" in a pentest and not restrict myself in the steps of a methodology. So in my opinion, an experienced pentester should not follow a methodology while performing the pentest, but should use it after to write the report in a concise way. Basically, it's more a matter of having created a good template based on a standard methodology.

    I just discovered your blog, looks promising!

  • At 8:57 AM, Anonymous said…

    pen test methodology is a good thing

    here is why

    we have a team of 4

    2 guys that are proficient with scans and general knowledge of OSes do follow the script and methodology

    myself analyze and go by the flow validating reported stuff and sifting through alerts trying to find something that is likely to be exploitable; check whatever webinspect has reported and so on

    we just make it clear to the client that this is our own methodology based on "fill_in_depending_if_federal_of_commercial" adjusted to their specific needs

  • At 12:48 PM, Richard said…

    Methodology is good. It shouldn't constrain the test/testers but it should enforce proper scientific measurement. The OSSTMM aims at this.

  • At 8:22 AM, Anonymous said…

    Experience is very valuable for penetration testing. However, the methodology has great value too - beyond just the documentation you've pointed out.

    A detailed checklist ensures that the penetration tester has not overlooked anything - especially after discovering 2-3 methods to break in, it's easy to relax a bit. A full checklist encourages the tester to complete the test and find every single way to break in. At Plynt, we do a lot of penetration tests and we've found our methodology is good for us (not just to show the client), as it instills more discipline in the testing.



Post a Comment

<< Home