Recently in Pentesting Category

The crew over at Offensive Security has taken the time to produce and publish a 17 minute technical video describing a summarized version of an actual penetration test. While several mistakes were clearly made by the target network, none of the errors were unheard of, even in well-managed corporate environments.

This is probably one of the best examples of penetration testing that I have seen in quite a while. The story is told by "muts" from Offensive Security, which is a training and consultancy company that I highly respect.

Offensive Security's training offerings are high quality for a low price, and definitely something that I highly recommend to look into (Disclaimer: I hold the Offensive Security Certified Professional Certification).

While the course content may not be 100% state-of-the-art, the attacks and exploits in it are still highly applicable in many organizations. Furthermore, the way-of-thinking that is introduced by this class is unparalleled.

After viewing the video, I think you'll have a whole new perspective on these things.

Last week was the last week of my SANS mentor class for Hacker Techniques, Exploits and Incident Handling. Hopefully my students will try out for certification and pass gloriously.

As always, we wrapped the 10-week teaching cycle up with the ever-entertaining capture-the-flag (CtF) session that really drives home a few key points. In a previous blog post (computer security badness hierarchy. January 13, 2009), I argued that when we focus on our responsibility for securing information technology (as part of a much larger socio-economic information system), information security practitioners really only have to worry about a few types of things: Bad Users, Bad Configuration, and Bad Software.

Most CtF's are completely in line with my hierarchy and by using tools such as nmap and metasploit and by leveraging exploit code that is readily available in places like the Offensive Security Exploit Database (formerly known as Milw0rm), most challenges in "hack labs" can be solved easily.

The major exploitable categories are typically credential re-use (bad users), unpatched software (bad software), running unnecessary services (bad configuration) and lack of port filtering (bad configuration), and can be found on most (if not all) enterprise networks. Of course, there are many more attack vectors (think "Web" and "end-point").

As a security practitioner, there are few tools more valuable than a well-designed and fully implemented vulnerability management program. When possible, it is nice to drop the $100K+ to purchase one of the commercial suites, but by ensuring that all your computers (servers, desktops and laptops) are configured according to a hardening template and that they receive all patches in a timely fashion is already a major gain. Put on top of that a decent (current) anti-malware package, and you have a nice start.

Do not underestimate the complexity of "just" doing this. If you haven't started this yet, get going. If you have started, but don't think you're done: welcome to the club ;)

If you are embarking on such a project, think about collecting some metrics about how well you are doing it so you can measure progress and define success. Think of numbers like: percentage of end-points that have been patched appropriately, percentage of end-points with current anti-malware software, average lag between publication of vulnerabilities and completion of roll-out, number of end-points in compliance with the hardening template, etc.

It had been in the back of my mind for a long time to war-dial my own organization, just to see if there are any unauthorized modems attached to computers on our network.

The modem attack vector has been long ignored, but if present, it offers a great vector into a network. More commonly than not, locally attached modems are not subject to firewalls, intrusion detection systems, or any other of security controls.

Since I only looked at phone numbers of which we knew a modem was attached, my little exercise was not a true wardialing effort, nor did it provide full coverage. Yet, it yielded pretty useful results. I had (note: past tense!) just over 20 telephone DiDs that were marked as modem lines. When dialed, not one of those lines actually picked up (yay!). Most lines either went to voicemail (shouldn't happen on a modem line), were off the hook, or were disconnected altogether.

All in all, this effort allowed us to reclaim a bunch of unused DiDs, and it confirmed that on our registered modem lines nobody had configured their modem to auto-answer.

The next step will be to identify rogue modem lines.

Fortunately, I do not expect to find that many (if at all). Our field support technicians have been looking out for the presence of modems for a year or two now, and as machines are swapped out on their regular schedule, legacy modems are removed.

Let's see what we come up with in the next few months, but this is one attack vector that should be mostly closed.

I was very pleased to receive word today that I passed the Offensive Security Certification Challenge. The OSCP is probably one of the hardest hands-on technical challenges that I have taken, and I was very happy (and somewhat surprised) to learn that I passed it.

I have said it before, and I'll be saying it again:The Offensive Security classes are excellent value-for-money for any security professional who wants to further develop their technical hands-on skills.

Don't expect lots of talk about policies, governance, compliance, risk, etc., but do expect to be spending an incredible amount of (quality) time on the command prompts of both Unix-like operating systems and Windows boxes.