CHAPTER 11

The Pen Test: Putting It All Together

In this chapter you will learn about

Maybe it hasn’t been Amelia Earhart’s solo trip across the Atlantic, or Columbus sailing the ocean blue, but you have to admit, it has been a long journey. We’ve covered everything that should be relevant for your upcoming exam, and even a few things that might make you a better hacker. And some of the stuff we covered is just plain cool. So now we find ourselves here at the last chapter, where everything comes together for the ethical hacker.

Note I didn’t say “for the hacker,” because you’re not going to be just a hacker. You’re going to be a different breed, working to improve security and safeguard data and resources—not the other way around. You’ll be doing good work for the betterment of your society. Sure, that may sound corny to some of you, but I truly believe it. And I know, if you believe your profession is making the world a better place, the pride you have in it will result in you becoming better and better at it each and every day. Before too long, you’ll look back on this little book like one of those English 101 books from college, and wonder at how far you’ve come.

So let’s take just a few paragraphs here and discuss the penetration test, where you’ll put into practice what you’ve read in a book. I promise this won’t take long—it’s a short chapter, and I’m pretty sure you deserve a break.

Methodology and Steps

Much has been made so far in this book about steps and taking a logical approach to hacking. I can honestly say that most of that is purely for your exam—for your “book knowledge,” if you will. Hackers will take advantage of any opportunity as it presents itself, and they’ll always look for the easy way in. Why bother running through all the steps of a hacking attack on a machine that’s either too secured to allow a breach (easily and within a decent timeframe) or doesn’t present a pot of gold at the end of the attack rainbow? However, all that said, we’re going to run through steps, phases, and definitions in this chapter—just so you have what you need for your exam. Buckle up, let’s ride.

The Security Assessments

Every organization on the planet that has any concern whatsoever for the security of its resources must perform various security assessments—and some don’t have a choice, if they need to comply with FISMA or other various government standards (see Figure 11-1). In CEH parlance, a security assessment is any test that is performed in order to assess the level of security on a network or system. The security assessment can belong to one of two categories: a security audit (otherwise known as a vulnerability assessment) or a penetration test.

A security audit scans and tests a system or network for existing vulnerabilities, but does not intentionally exploit any of them. This vulnerability assessment is designed to uncover potential security holes in the system and report them to the client for their action. This assessment does not fix or patch vulnerabilities, nor does it exploit them—it simply points them out for the client’s benefit.

	NOTE It’s a good idea to keep in mind the difficulty of the “find but don’t test” theory of vulnerability assessments. For instance, say you believe there might be an SQL injection vulnerability in a website. But to determine if it’s vulnerable, you have to attempt to insert SQL—which is pen testing. Very often, the only way to verify the existence of a vulnerability must be to test for it.

Figure 11-1 NIST and FISMA logos

A penetration test, on the other hand, not only looks for vulnerabilities in the system but actively seeks to exploit them. The idea is to show the potential consequences of a hacker breaking in through unpatched vulnerabilities. Pen tests are carried out by highly skilled individuals pursuant to an agreement signed before testing begins. This agreement spells out the limitations, constraints, and liabilities between the organization and the penetration test team. This agreement is designed to maximize the effectiveness of the test itself while minimizing operational impact.

Speaking of pen tests overall, there are basically two types of penetration tests defined by EC-Council: external and internal. An external assessment analyzes publicly available information and conducts network scanning, enumeration, and testing from the network perimeter—usually from the Internet. An internal assessment, as you might imagine, is performed from within the organization, from various network access points. Obviously, both could be part of one overall assessment, but you get the idea.

We’ve covered black box, white box, and grey box testing already, so I won’t beat you over the head with these again. However, just to recap: Black box testing occurs when the attacker has no prior knowledge of the infrastructure at all. This testing takes the longest to accomplish and simulates a true outside hacker. White box testing simulates an internal user who has complete knowledge of the company’s infrastructure. Grey box testing provides limited information on the infrastructure. Sometimes grey box testing is born out of a black box test that determines more knowledge is needed.

NOTE Pen testing can also be defined by what your customer knows. Announced testing means the IT security staff is made aware of what testing you’re providing and when it will occur. Unannounced testing occurs without the knowledge of the IT security staff, and is only known by the management staff who organized and ordered the assessment. Additionally, unannounced testing should always come with detailed processes that are coordinated with a trusted agent. It is normally very bad to have a company’s entire IT department tasked with stopping an incident that is really just an authorized pen test.

Testing can also be further broken down according to the means by which it is accomplished. Automated testing is a point-and-shoot effort with an all-inclusive toolset such as Core Impact. This could be viewed as a means to save time and money by the client’s management, but it simply cannot touch a test performed by security professionals. Automated tools can provide a lot of genuinely good information, but are also susceptible to false positives and false negatives, and they don’t necessarily care what your agreed-upon scope says is your stopping point. A short list of some automated tools is presented here:

Figure 11-2 Core Impact

Figure 11-3 Metasploit’s Autopwn

Manual testing is still, in my humble opinion, the best choice for a true security assessment. It requires good planning, design, and scheduling, and provides the best benefit to the client. Although automated testing definitely has a role in the overall security game, many times it’s the ingenuity, drive, and creativeness of the hacker that results in a true test of the security safeguards.

As for the actual test itself, EC-Council and many others have divided the actions taken into three main phases. In the pre-attack phase, you’ll be performing all the reconnaissance and data-gathering efforts we discussed earlier in this book. Competitive intelligence, identifying network ranges, checking network filters for open ports, and so on are all carried out here. Also, running whois, DNS enumeration, finding the network IP address range, and nmap network scanning all occur here. Other tasks you might consider include, but aren’t limited to, testing proxy servers, checking for default firewall or other network-filtering device installations or configurations, and looking at any remote login allowances.

Figure 11-4 CANVAS

In the attack phase, you’ll be attempting to penetrate the network perimeter, acquire your targets, execute attacks, and elevate privileges. Getting past the perimeter might take into account things such as verifying ACLs by crafting packets and checking to see if you can use any covert tunnels inside the organization. On the web side, you’ll be trying XSS, buffer overflows, and SQL injections. After acquiring specific targets, you’ll move into password cracking and privilege escalation, using a variety of methods we’ve covered here. Finally, once you’ve gained access, it’s time to execute your attack code.

Finally, the post-attack phase consists of two major steps. First, there’s an awful lot of cleanup to be done. Anything that has been uploaded to the organization’s systems in the way of files or folders needs to be removed. Additionally, any tools, malware, backdoors, or other attack software loaded on client systems needs to be taken off. And don’t forget the Registry—any changes made there need to be put back to the original settings. The idea is to return everything to the pre-test state. Remember, not only are you not supposed to fix anything you find, but you’re also not supposed to create more vulnerabilities for the client to deal with.

	NOTE Cleanup is a very difficult part of assessments. Logs, backups, and other artifacts are sometimes nearly impossible to remove. Ensuring your remote agents kill themselves off (like Core Impact does by default) can help, but if you have a client who wants manual inspection, it may become a serious cost driver.

And the second step in the post-attack phase? Well, that deals with the deliverables, which we’ll discuss next.

Security Assessment Deliverables

I know you’re probably going to hate hearing this, but I’ve got to be truthful with you—just because you’re an ethical hacker performing security assessments for major clients doesn’t mean you’re off the hook paperwork-wise. The pen test you were hired to do was designed with one objective in mind: to provide the client with information they need to make their network safer and more secure. Therefore, it follows that the client will expect something in the form of a deliverable in order to take some action—something that will require you to practice your organizing, typing, and presentation skills. So if you thought you were getting into a paperwork-free, no-time-behind-the-desk job, my apologies.

Typically your test will begin with some form of an in-brief to the management. This should provide an introduction of the team members and an overview of the original agreement. You’ll need to point out which tests will be performed, which team members will be performing specific tasks, the timeline for your test, and so on. Points of contact, phone numbers, and other information—including, possibly, the “Bat phone” number, to be called in the event of an emergency requiring all testing to stop—should all be presented to the client before testing begins.

	NOTE Some clients and tests will require interim briefings on the progress of the team. These might be daily wrap-ups the team leader can provide via secured e-mail, or full-blown presentations with all team members present.

After the test is complete, a comprehensive report is due to the customer. Although each test and client is different, some of the basics that are part of every report are listed here:

An example of a standard pen test report template can be viewed at www.vulnera-bilityassessment.co.uk/report%20template.html.

	NOTE Many of the tools we’ve covered in this book have at least some form of reporting capability. Oftentimes these can, and should, be included with your end-test deliverables.

And so, dear reader, we’ve reached the end of your testable material. I promised I’d keep this chapter short and to the point, and I believe I have. Most of the information in this chapter is a review of items we’ve already discussed, but it’s important to know for both your exam and your real-world exploits. I sincerely hope I’ve answered most of your questions, and eliminated some of the fear you may have had in tackling this undertaking.

Best of luck to you on both your exam and your future career. Practice what we’ve talked about here—download and install the tools and try exploits against machines or VMs you have available in your home lab. And don’t forget to stay ethical! Everything in this book is intended to help you pass your upcoming exam and become a valued pen test member, not to teach you to be a hacker. Stay the course and you’ll be fine.

Chapter Review

Security assessments can be one of two types: a security audit (vulnerability assessment) or a penetration test. The security audit scans and tests a system or network for existing vulnerabilities, but does not intentionally exploit any of them. This assessment is designed to uncover potential security holes in the system and report them to the client for their action. It does not fix or patch vulnerabilities, nor does it exploit them. It only points them out for the client’s benefit.

A penetration test actively seeks to exploit vulnerabilities encountered on target systems or networks. This shows the potential consequences of a hacker breaking in through unpatched vulnerabilities. Penetration tests are carried out by highly skilled individuals according to an agreement signed before testing begins. This agreement spells out the limitations, constraints, and liabilities between the organization and the penetration test team.

Penetration tests consist of two types of assessment: external and internal. An external assessment analyzes publicly available information and conducts network scanning, enumeration, and testing from the network perimeter—usually from the Internet. An internal assessment is performed from within the organization, from various network access points.

Black box testing occurs when the attacker has no prior knowledge of the infrastructure at all. This testing takes the longest to accomplish and simulates a true outside hacker. White box testing simulates an internal user who has complete knowledge of the company’s infrastructure. Grey box testing provides limited information on the infrastructure. Sometimes grey box testing is born out of a black box test that determines more knowledge is needed.

Testing can also be further broken down according to the way it is accomplished. Automated testing uses an all-inclusive toolset. Automated tools can provide plenty of information and many legitimate results for a lesser price than manual testing with a full test team. However, they are also susceptible to false positives and false negatives, and don’t always stop where they’re supposed to (software can’t read your agreement contract). Manual testing is the best choice for security assessment. It requires good planning, design, and scheduling, and provides the best benefit to the client. Manual testing is accomplished by a pen test team, following the explicit guidelines laid out before the assessment.

There are three main phases to a pen test. In the pre-attack phase, reconnaissance and data gathering efforts are accomplished. Gathering competitive intelligence, identifying network ranges, checking network filters for open ports, and so on are all carried out in this phase. Running whois, DNS enumeration, finding the network IP address range, and nmap network scanning are all examples of tasks in this phase.

Attempting to penetrate the network perimeter, acquire your targets, execute attacks, and elevate privileges are steps taken in the attack phase. Verifying ACLs by crafting packets, checking to see if you can use any covert tunnels inside the organization, and using XSS, buffer overflows, and SQL injections are all examples of tasks performed in this phase. After acquiring specific targets, you’ll move into password cracking and privilege escalation, using a variety of methods. Finally, once you’ve gained access, it’s time to execute your attack code.

The post-attack phase consists of two major steps. The first step involves cleaning up your testing efforts. Anything that has been uploaded to the organization’s systems in the way of files or folders needs to be removed. Any tools, malware, backdoors, or other attack software loaded on the client’s systems need to be taken off. Any Registry changes you’ve made need to be put back to their original settings. The goal of this phase is to return everything to the pre-test state.

The second step involves writing the pen test report, due after all testing is complete. The pen test report should contain the following items:

Questions

Answers