Penetration Testing Summit 2010

The SANS Penetration Testing Summit was held this year at the Hyatt Baltimore in Baltimore, MD on June 14 - 15 and was focused on “What Works in Penetration Testing".

The event was held just across from Camden Yards, home of the Baltimore Orioles.

Tips For Penetration Testers

I participated in a panel discussion with Joshua Wright, Vincent Liu and Joshua Abrams titled, "Most Effective New Technique You've Applied in the Past 12 Months". We started by having each of us share two fun, new or interesting penetration testing techniques that we've applied in the past year. It was a great discussion, covering topics such as wireless, vulnerability assessments and what tools to get started with.

I shared a story with the audience about lock picking. The story details the travels of my friend (let's call him "Bob") who was put into a situation where he had to pick a lock. Bob did not have his lock-picking set and was forced to use more crude tools. In the end, Bob ended up prying off the entire doorknob with even more rudimentary and crude tools. I then circled back around to the lessons learned and how they apply to both lock picking and penetration testing:

1. Never leave home without your tools - This is very important for a penetration tester. You never want to be in a situation where you do not have the right tools for the job. I suggested that you might want to carry around a USB thumb drive with all of your tools on it. For example, you can purchase this small, flat 16GB USB drive for just over $30, load it with your favorite Linux distribution, install and configure your tools and then keep it in your wallet. Linux distributions, such as Backtrack Linux, that will run well on this media can even be configured to run Nessus. (For you lock-pickers out there, consider purchasing a set of these.) Having your own tools is important not only to make sure you have the right tools, but also to ensure the integrity of the tools you are using. If there is a potential that the system you are testing has been compromised, the tools that would be used to investigate may very well have been backdoored.
2. Practice, Practice and more Practice - It is important to be extremely comfortable with the tools that you are using, especially if you are running them against a production environment. What I've learned is that you need to not only be good at using the "good" tools, but the "bad" ones as well. For example, "Bob" could have easily picked the door lock had he brought his lock-pick set with him. Instead, all he had was a paperclip and a hairpin. Penetration testers need to practice with the equivalent of paperclips and hairpins, and this translates into using built-in tools (such as the Windows cmd.exe shell or Bash) to get your job done.
3. Be Stealthy and Cause No Damage - You must maintain a balance between completing a test that yields accurate and useful results and not disrupting the operations of the business you are testing. When possible, test the backup or non-production networks first so as to not impede the ability of production systems to run and continue to operate the business. When you obtain access to a system, it is important to leave it as you found it. In the lock-picking example, prying off the door may leave marks and damage the door itself. Doing so leaves evidence of forced entry. However, if you can gain entry into a system (or a door) without being detected, it points out flaws in the security system that must be addressed, while not impacting the client.

A view of the penetration testing tips panel.

I also discussed some tips for port scanning large numbers of hosts. Whatever vulnerability scanner you are using, make sure you dig into the options. For example, you should be able to tell the scanner "don't try so hard when fingerprinting a service" and "scan 1,024 hosts at all times".

Just because you can "exploit" it...

On the second day, Ron Gula also participated in a panel on recent advancements in penetration testing and vulnerability assessments titled "Scan-Zilla: Conducting Practical and Effective Large-Scale Enterprise Vuln Scans". Ron spoke about the benefits of passive network monitoring and provided many examples of detecting in real-time when your DMZ changes, where all of your web servers are located on the network and how all of this can be done with no need to obtain approval for scans or a penetration test. Various vendors on the panel were given an opportunity to present their products and how they would approach scanning a large network (1 million+ IP addresses). According to some panel members, the larger problem is not the logistics of running a successful scan but what you do with the tremendous amount of data that is collected.

Another topic that was discussed involved prioritizing vulnerabilities once a scan has completed. Members of the panel discussed how if a vulnerability could be exploited remotely that it automatically deserved to be at the top of the priority list. Another prioritization factor mentioned was if an exploit for a particular vulnerability had been made public. There are several reasons and other factors to consider when prioritizing vulnerabilities:

1. 0-Day exploits - While what we're reading about in today's news in regard to unpatched vulnerabilities may be scary, what about the ones we're not reading about? If you review the vulnerability disclosure timeline for many vulnerabilities, you will find that multiple researchers and the affected vendors have known about them for quite some time (sometimes six months to a year or more). I believe it is safe to say that if one person knows about a vulnerability, they may not be the only one. This means that attackers could exploit these vulnerabilities on your network and there is no patch to mitigate the threat. Now what? This is where network monitoring and configuration auditing can help, in addition to providing a holistic view of security within your organization.
2. The public exploit may not work - Those of us who have written or studied exploits know that it’s a tricky business. Memory is very dynamic, execution prevention can complicate things and each platform presents different challenges for exploits to be successful. The fear is that if you only patch according to successful exploitation, your systems may not be protected. What if that particular exploit just didn't work on your system because the code did not take into account your configuration or architecture? Then, what if attackers have perfected an exploit and are using it against your systems? Trusting an exploit to work and set priority for remediation is risky business, especially if there is a patch available.
3. Other categories of vulnerabilities could be more dangerous - While there is no question that a vulnerable system that can be exploited remotely poses a risk, what about other situations that pose more risk? A great example is passwords. From an attacker’s perspective, it does not matter how they gain access to a system; in fact, guessing the password or using a default password is a great way to get access because it does not rely on a missing patch. Misconfiguration is another great way to gain control of systems, and even an entire network, but also does not require a missing patch. For example, if an attacker is able to take advantage of a misconfiguration on a Cisco router (such as a weak password, SNMP string, etc.) they could potentially take control of the whole network. Again, configuration auditing can help and Tenable has just released configuration auditing through Nessus for the Cisco IOS operating system.

Conclusion

The penetration testing summit was a great conference. Some other highlights include the presentation given by Carlos Perez and myself titled, "POST-Exploitation: Doing the Happy Dance and More" where we picked apart the activities that occur on a system once it has been compromised. Dan Kaminsky also gave a fascinating presentation "Penetration Testing by Targeting the Soft Underbelly of Infrastructure" and announced a new web site that aims to provide a library to make software more secure. Unfortunately, I was unable to attend the second day of the conference, but I am looking forward to next year. Thank you to Ed Skoudis and The SANS Institute for putting on a fantastic conference!