HACKING-Penetration Testing Primer

CHAPTER -0

Penetration testing, or pentesting

involves simulating

real attacks to assess the risk associated with

potential security breaches. On a pentest (as opposed

to a vulnerability assessment), the testers not only discover

vulnerabilities that could be used by attackers

but also exploit vulnerabilities, where possible, to

assess what attackers might gain after a successful

exploitation.

From time to time, a news story breaks about a major company being
hit by a cyberattack. More often than not, the attackers didn’t use the latest
and greatest zero-day (a vulnerability unpatched by the software publishers).
Major companies with sizable security budgets fall victim to SQL injection
vulnerabilities on their websites, social-engineering attacks against
employees, weak passwords on Internet-facing services, and so on. In other

words, companies are losing proprietary data and exposing their clients’
personal details through security holes that could have been fixed. On a
penetration test, we find these issues before an attacker does, and we recommend
how to fix them and avoid future vulnerabilities.
The scope of your pentests will vary from client to client, as will your
tasks. Some clients will have an excellent security posture, while others will
have vulnerabilities that could allow attackers to breach the perimeter and
gain access to internal systems.
You may also be tasked with assessing one or many custom web applications.
You may perform social-engineering and client-side attacks to gain
access to a client’s internal network. Some pentests will require you to act
like an insider—a malicious employee or attacker who has already breached
the perimeter—as you perform an internal penetration test. Some clients will
request an external penetration test, in which you simulate an attack via the
Internet. And some clients may want you to assess the security of the wireless
networks in their office. In some cases, you may even audit a client’s
physical security controls.

The Stages of the Penetration Test

Pentesting begins with the pre-engagement phase, which involves talking to
the client about their goals for the pentest, mapping out the scope (the
extent and parameters of the test), and so on. When the pentester and the
client agree about scope, reporting format, and other topics, the actual testing
begins.
In the information-gathering phase, the pentester searches for publicly
available information about the client and identifies potential ways to connect
to its systems. In the threat-modeling phase, the tester uses this information
to determine the value of each finding and the impact to the client if
the finding permitted an attacker to break into a system. This evaluation
allows the pentester to develop an action plan and methods of attack.
Before the pentester can start attacking systems, he or she performs a
vulnerability analysis. In this phase, the pentester attempts to discover vulnerabilities
in the systems that can be taken advantage of in the exploitation
phase. A successful exploit might lead to a post-exploitation phase, where the
result of the exploitation is leveraged to find additional information, sensitive
data, access to other systems, and so on.
Finally, in the reporting phase, the pentester summarizes the findings for
both executives and technical practitioners.
Not e For more information on pentesting, a good place to start is the Penetration Testing
Execution Standard (PTES) at http://www.pentest-standard.org/.

Pre-engagement

Before the pentest begins, pentesters perform pre-engagement interactions
with the client to make sure everyone is on the same page about the

penetration testing. Miscommunication between a pentester and a client
who expects a simple vulnerability scan could lead to a sticky situation
because penetration tests are much more intrusive.
The pre-engagement stage is when you should take the time to understand
your client’s business goals for the pentest. If this is their first pentest,
what prompted them to find a pentester? What exposures are they most
worried about? Do they have any fragile devices you need to be careful
with when testing? (I’ve encountered everything from windmills to medical
devices hooked up to patients on networks.)
Ask questions about your client’s business. What matters most to them?
For example, to a top online vendor, hours of downtime could mean thousands
of dollars of lost revenue. To a local bank, having online banking sites
go down for a few hours may annoy a few customers, but that downtime
wouldn’t be nearly as devastating as the compromise of a credit card database.
To an information security vendor, having their homepage plastered
with rude messages from attackers could lead to a damaged reputation that
snowballs into a major revenue loss.
Other important items to discuss and agree upon during the preengagement
phase of the pentest include the following:

Scope

What IP addresses or hosts are in scope, and what is not in scope? What
sorts of actions will the client allow you to perform? Are you allowed to
use exploits and potentially bring down a service, or should you limit the
assessment to merely detecting possible vulnerabilities? Does the client
understand that even a simple port scan could bring down a server or
router? Are you allowed to perform a social-engineering attack?

The testing window

The client may want you to perform tests only during specific hours or
on certain days.

Contact information

Whom should you contact if you find something serious? Does the client
expect you to contact someone 24 hours a day? Do they prefer that
you use encryption for email?

A “get out of jail free” card

Make sure you have authorization to perform a penetration test on the
target. If a target is not owned by the company (for instance, because
it’s hosted by a third party), make sure to verify that the client has
formal approval from the third party to perform the penetration test.
Regardless, make sure your contract includes a statement that limits
your liability in case something unexpected happens, and get written
permission to perform the test.

Payment terms

How and when will you be paid, and how much?

Finally, include a nondisclosure agreement clause in your contract.
Clients will appreciate your written commitment to keep the penetration
test and any findings confidential.

Information Gathering

Next is the information-gathering phase. During this phase, you analyze
freely available sources of information, a process known as gathering open
source intelligence (OSINT). You also begin to use tools such as port scanners
to get an idea of what systems are out there on the Internet or internal network
as well as what software is running. We’ll explore information gathering
in more detail in Chapter 5.

Threat Modeling

Based on the knowledge gained in the information-gathering phase, we
move on to threat modeling. Here we think like attackers and develop plans
of attack based on the information we’ve gathered. For example, if the client
develops proprietary software, an attacker could devastate the organization
by gaining access to their internal development systems, where the source
code is developed and tested, and selling the company’s trade secrets to a
competitor. Based on the data we found during information gathering, we
develop strategies to penetrate a client’s systems.

Vulnerability Analysis

Next, pentesters begin to actively discover vulnerabilities to determine how
successful their exploit strategies might be. Failed exploits can crash services,
set off intrusion-detection alerts, and otherwise ruin your chances of
successful exploitation. Often during this phase, pentesters run vulnerability
scanners, which use vulnerability databases and a series of active checks
to make a best guess about which vulnerabilities are present on a client’s system.
But though vulnerability scanners are powerful tools, they can’t fully
replace critical thinking, so we also perform manual analysis and verify
results on our own in this phase as well. We’ll explore various vulnerabilityidentification
tools and techniques in Chapter 6.

Exploitation

Now for the fun stuff: exploitation. Here we run exploits against the vulnerabilities
we’ve discovered (sometimes using a tool like Metasploit) in an
attempt to access a client’s systems. As you’ll see, some vulnerabilities will be
remarkably easy to exploit, such as logging in with default passwords. We’ll
look at exploitation in Chapter 8.

Post Exploitation

Some say pentests truly begin only after exploitation, in the post-exploitation
phase. You got in, but what does that intrusion really mean to the client? If
you broke into an unpatched legacy system that isn’t part of a domain or

otherwise networked to high-value targets, and that system contains no
information of interest to an attacker, that vulnerability’s risk is significantly
lower than if you were able to exploit a domain controller or a client’s development
system.
During post exploitation, we gather information about the attacked system,
look for interesting files, attempt to elevate our privileges where necessary,
and so on. For example, we might dump password hashes to see if we
can reverse them or use them to access additional systems. We might also
try to use the exploited machine to attack systems not previously available
to us by pivoting into them. We’ll examine post exploitation in Chapter 13.

Reporting

The final phase of penetration testing is reporting. This is where we convey
our findings to the customer in a meaningful way. We tell them what they’re
doing correctly, where they need to improve their security posture, how you
got in, what you found, how to fix problems, and so on.
Writing a good pentest report is an art that takes practice to master.
You’ll need to convey your findings clearly to everyone from the IT staff
charged with fixing vulnerabilities to upper management who signs off on
the changes to external auditors. For instance, if a nontechnical type reads,
“And then I used MS08-067 to get a shell,” he or she might think, “You mean,
like a seashell?” A better way to communicate this thought would be to mention
the private data you were able to access or change. A statement like “I
was able to read your email,” will resonate with almost anyone.
The pentest report should include both an executive summary and a
technical report, as discussed in the following sections.

Executive Summary

The executive summary describes the goals of the test and offers a highlevel
overview of the findings. The intended audience is the executives in
charge of the security program. Your executive summary should include
the following:

Background   

A description of the purpose of the test and definitions

of any terms that may be unfamiliar to executives, such as vulnerability
and countermeasure.
Overall posture 
An overview of the effectiveness of the test, the
issues found (such as exploiting the MS08-067 Microsoft vulnerability),
and general issues that cause vulnerabilities, such as a lack of patch
management.
Risk profile 
 An overall rank of the organization’s security posture
compared to similar organizations with measures such as high, moderate,
or low. You should also include an explanation of the ranking.
General findings 
A general synopsis of the issues identified along
with statistics and metrics on the effectiveness of any countermeasures
deployed.

Recommendation summary
  A high-level overview of the tasks required
to remediate the issues discovered in the pentest.

Strategic road map

Give the client short- and long-term goals to
improve their security posture. For example,  you might tell them to
apply certain patches now to address short-term concerns, but without
a long-term plan for patch management, the client will be in the same
position after new patches have been released.
Technical Report
This section of the report offers technical details of the test. It should
include the following:
Introduction An inventory of details such as scope, contacts, and so on.
Information gathering Details of the findings in the informationgathering
phase. Of particular interest is the client’s Internet footprint.
Vulnerability assessment Details of the findings of the vulnerabilityanalysis
phase of the test.
Exploitation/vulnerability verification Details of the findings from
the exploitation phase of the test.
Post exploitation Details of the findings of the post-exploitation
phase of the test.
Risk/exposure A quantitative description of the risk discovered. This
section estimates the loss if the identified vulnerabilities were exploited
by an attacker.

Conclusion A final overview of the test.

Summary

This chapter has taken a brief look at the phases of penetration testing,
including pre-engagement, information gathering, threat modeling,
vulnerability analysis, exploitation, post exploitation, and reporting.
Familiarity with these phases will be crucial as you begin your pentesting
career, and you’ll learn more about them as you move through the  WEBSITED