Hacking 2 : Introduction to penetration test (What is penetration testing, Penetratio testing methodologies, Categories of penetration test, Types of penetration Test, Report writing).

What Is a Penetration Test?

       

A penetration test is a subclass of ethical hacking; it comprises a set of methods and procedures that aim at testing/protecting an organization’s security. The penetration tests prove helpful in finding vulnerabilities in an organization and check whether an attacker will be able to exploit them to gain unauthorized access to an asset. 

Vulnerability Assessments versus Penetration Test

Oftentimes, a vulnerability assessment is confused with a penetration test; however, these terms have completely different meanings. In a vulnerability assessment, our goal is to figure out all the vulnerabilities in an asset and document them accordingly. In a penetration test, however, we need to simulate as an attacker to see if we are actually able to exploit a vulnerability and document the vulnerabilities that were exploited and the ones that turned out to be false-positive.

Pre engagement

Before you start doing a penetration test, there is whole lot of things you need to discuss with clients. This is the phase where both the customer and a representative from your company would sit down and discuss about the legal requirements and the “rules of engagement.”

Rules of Engagement

Every penetration test you do would comprise of a rules of engagement, which basically defines how a penetration test would be laid out, what methodology would be used, the start and end dates, the milestones, the goals of the penetration test, the liabilities and responsibilities, etc. All of them have to be mutually agreed upon by both the customer and the representative before the penetration test is started. Following are important requirements that are present in almost every ROE:

• A proper “permission to hack” and a “nondisclosure” agreement should be signed by both the parties.
• The scope of the engagement and what part of the organization must be tested.
• The project duration including both the start and the end date.
• The methodology to be used for conducting a penetration test.
• The goals of a penetration test.
• The allowed and disallowed techniques, whether denial-of-service testing should be performed or not.
• The liabilities and responsibilities, which are decided ahead of time. As a penetration tester you might break into something that should not be accessible, causing a denial of service also, you might access sensitive information such as credit cards. Therefore, the liabilities should be defined prior to the engagement.

Milestones

Before starting a penetration test, it’s good practice to set up milestones so that your project is delivered as per the dates given in the rules of engagement.

You can use either a GANTT chart or a website like Basecamp that helps you set up milestones to keep track of your progress. The following is a chart that defines the milestones followed by the date they should be accomplished.

Penetration Testing Methodologies

In every penetration test, methodology and the reporting are the most important steps. Let’s first talk about the methodology. There are several different types of penetration testing methodologies that address how a penetration test should be performed. Some of them are discussed in brief next.

OSSTMM

An open-source security testing methodology manual (OSSTMM) basically includes almost all the steps involved in a penetration test. The methodology employed for penetration test is concise yet it’s a cumbersome process which makes it difficult to implement it in our everyday life. Penetration tests, despite being tedious, demands a great deal of money out of company’s budgets for their completion which often are not met by a large number of organizations.

NIST

NIST, on the other hand, is more comprehensive than OSSTMM, and it’s something that you would be able to apply on a daily basis and in short engagements. The screenshot indicates the four steps of the methodology, namely, planning, discovery, attack, and reporting.

The testing starts with the planning phase, where how the engagement is going to be performed is decided upon. This is followed by the discovery phase, which is divided into two parts—the first part includes information gathering, network scanning, service identification, and OS detection, and the second part involves vulnerability assessment.

After the discovery phase comes the attack phase, which is the heart of every penetration test. If you are able to compromise a target and a new host is discovered, in case the system is dual-homed or is connected with multiple interfaces, you would go back to step 2, that is, discovery, and repeat it until no targets are left. The indicating arrows in the block phase and the attack phase to the reporting phase indicate that you plan something and you report it—you attack a target and report the results.

The organization also has a more detailed version of the chart discussed earlier, which actually explains more about the attack phase. It consists of things such as “gaining access,” “escalating privileges,” “system browsing,” and “install additional tools.” We will go through each of these steps in detail in the following articles.

OWASP

As you might have noticed, both the methodologies focused more on performing a network penetration test rather than something specifically built for testing web applications. The OWASP testing methodology is what we follow for all “application penetration tests” we do here at the RHA InfoSEC. The OWASP testing guide basically contains almost everything that you would test a web application for. The methodology is comprehensive and is designed by some of the best web application security researchers.

Categories of Penetration Test

When the scope of the penetration test is defined, the category/type of the penetration test engagement is also defined along with it. The entire penetration test can be Black Box, White Box, or Gray Box depending upon what the organization wants to test and how it wants the security paradigm to be tested.

Black Box

A black box penetration test is where little or no information is provided about the specified target. In the case of a network penetration test this means that the target’s DMZ, target operating system, server version, etc., will not be provided; the only thing that will be provided is the IP ranges that you would test. In the case of a web application penetration test, the source code of the web

application will not be provided. This is a very common scenario that you will encounter when performing an external penetration test.

White Box

A white box penetration test is where almost all the information about the target is provided. In the case of a network penetration test, information on the application running, the corresponding versions, operating system, etc., are provided. In the case of a web application penetration test the application’s source code is provided, enabling us to perform the static/dynamic “source code analysis.” This scenario is very common in internal/onsite penetration tests, since organizations are concerned about leakage of information.

Gray Box

In a gray box test, some information is provided and some hidden. In the case of a network penetration test, the organization provides the names of the application running behind an IP; however, it doesn’t disclose the exact version of the services running. In the case of a web application penetration test, some extra information, such as test accounts, back end server, and databases, is provided.

Types of Penetration Tests

There are several types of penetration tests; however, the following are the ones most commonly performed:

Network Penetration Test

In a network penetration test, you would be testing a network environment for potential security vulnerabilities and threats. This test is divided into two categories: external and internal penetration tests.

An external penetration test would involve testing the public IP addresses, whereas in an internal test, you can become part of an internal network and test that network. You may be provided VPN access to the network or would have to physically go to the work environment for the penetration test depending upon the engagement rules that were defined prior to conducting the test.

Web Application Penetration Test

Web application penetration test is very common nowadays, since your application hosts critical data such as credit card numbers, usernames, and passwords; therefore this type of penetration test has become more common than the network penetration test.

Mobile Application Penetration Test

The mobile application penetration test is the newest type of penetration test that has become common since almost every organization uses Android- and iOS-based mobile applications to provide services to its customers. Therefore, organizations want to make sure that their mobile applications are secure enough for users to rely on when providing personal information when using such applications.

Social Engineering Penetration Test

A social engineering penetration test can be part of a network penetration test. In a social engineering penetration test the organization may ask you to attack its users. This is where you use speared phishing attacks and browser exploits to trick a user into doing things they did not intend to do.

Physical Penetration Test

A physical penetration test is what you would rarely be doing in your career as a penetration tester. In a physical penetration test, you would be asked to walk into the organization’s building physically and test physical security controls such as locks and RFID mechanisms.

Report Writing

In any penetration test, the report is the most crucial part. Writing a good report is key to successful penetration testing. The following are the key factors to a good report:

Your report should be simple, clear, and understandable. Presentation of the report is also important. Headers, footers, appropriate fonts, well-spaced margins, etc., should be created/selected properly and with great care. For example, if you are using a red font for the heading, every heading in the document should be in that style. The report should be well organized. Correct spelling and grammar is important too. A misspelled word leaves a very negative impact upon the person who is reading your report. So, you should make sure that you proofread your report and perform spell-checks before submitting it to the client. Always make sure that you use a consistent voice and style in writing a report. Changing the voice would create confusion in the reader; so you should choose one voice and style and stick to it throughout your report.

Make sure you spend time on eliminating false-positives (vulnerabilities that are actually not present), because false-negatives will always be there no matter what you do. Eliminating the false-positives would enhance the credibility of the report. Perform a detailed analysis of the vulnerability to find out its root cause. A screenshot of a RAW http request or the screenshot that demonstrates the evidence of the finding would give a clear picture to the developer of the status.

Understanding the Audience

Understanding the audience that would be reading your penetration testing report is a very crucial part of the penetration test. We can divide the audience into three different categories:

1. Executive class

2. Management class

3. Technical class

While writing a report, you must understand which audience would read which part of your report; for example, the company’s CEO would not be interested in what exploit you used to gain access to a particular machine, but on the flip side, your developers will probably not be interested in the overall risks and potential losses to the company; instead, they would be interested in fixing the code and therefore in reading about detailed findings. Let’s briefly talk about the three classes.

Executive Class

This category includes the CEOs of the company. Since they have a very tedious schedule and most of the times have less technical knowledge, they would end up reading a very small portion of the report, specifically the executive summary, remediation report, etc., which we will discuss later in this article.

Management Class

Next, we have the management class, which includes the CISOs and CISSPs of the company. Since they are the ones who are responsible for implementing the security policy of the company, hey would probably be a bit more interested in reading about overall strengths and weaknesses, the remediation report, the vulnerability assessment report, etc.

Technical Class

This class includes the security manager and developers, who would be interested in reading your report thoroughly. They would investigate your report as they are responsible for patching the weaknesses found and for making sure that the necessary patches are implemented.

Writing Reports

Now we are going to get into the essentials of the reporting phase, which will teach you about the structure of a report. We have discussed what a good report should look like. I pointed out that knowing your audience was essential. One of the key factors about a good report is that it should meet the needs for each audience and be presented in a clear and understandable manner. The next major part of writing a report is the analysis, where we perform risk assessment and calculate the overall risk to the organization based upon our findings; along with this, your report should also provide remediation on how the risk can be averted.

Structure of a Penetration Testing Report

Let’s look step by step on how a good report should be laid out. At the end of this article, I have provided links to some of the best reports which have been provided to the local mass.

Cover Page

We start with the cover page; this is where you would include details such as your company logo, title, and a short description about the penetration test. I would suggest you hire a good designer and work on a professional and appealing cover page because if your cover page looks great, it would make a good first impression upon the customer reading it.

Table of Contents

On the very next page, you should have an index so that the audience interested in reading a particular portion of the report can easily skip to that portion.

Executive Summary

As the name suggests, an executive summary is the portion that is specifically addressed to executives such as the CEO or the CIO of the company. The executive summary is the most essential part of a penetration testing report; a good executive summary can make all the difference between a good report and a bad one.

Since the executive summary is specifically written to address the nontechnical audience, you should make sure that it’s presented in such a way that it’s easily comprehensible. Following are some of the essential points that you should take into consideration while writing an executive summary.

• Since executives are very busy, they have minimal time to invest in reading your reports. Therefore you should make sure that your executive summary is precise and to the point. 
• Your executive summary should start with defining the purpose of the engagement and how it was carried out. Things such as the scope should be defined but very precisely.
• Next, you should explain the results of the penetration test and the findings.
• Following this, you should discuss the overall weaknesses in general and the countermeasures that were not implemented that caused the vulnerability in the first place.
• Next comes the analysis part; this is where you should write about the overall risk that was determined based upon our findings.
• And, finally, you should write about to what extent the risk would decrease after addressing the issues and implementing the appropriate countermeasures.
• The following is a point out of an executive summary. I would suggest you spend some time reviewing the essential points discussed and compare them with the executive summary that follows. 

Remediation Report

Next up we have the remediation report, which contains the overall recommendations that once implemented would increase the security of the organization. This is specifically an area of interest for the management class, as they are the ones that are going to enforce the security policies of an organization.

As mentioned earlier, these guys may or may not be technical; therefore our remediation report should be very precise and easy to understand. Things that could improve overall security such as implementing SDLC, a firewall, and an intrusion detection system should be recommended. The following is an example of how a remediation report should look like:

Vulnerability Assessment Summary

Next, we have the vulnerability assessment summary, sometimes referred to as “findings summary.” This is where we present the findings from our engagement. Things such as the overall strengths and weaknesses and risk assessment summary can also be included under this section.

It always helps to include charts in your report, which would give the audience a better understanding of the vulnerabilities that were found. Security executives might be interested in this portion of the report as they would

need to enforce the countermeasures.

There are different ways for representing vulnerability assessment outputs in the form of graphical charts. Personally, I include two graphs; the first one classifies the vulnerability assessment on the basis of the severity and the second one on percentage.

Next, We suggest a “vulnerabilities breakdown” chart, where We talk about the findings for a particular host followed by the number of vulnerabilities that were found.

Tabular Summary

A tabular summary is also a great way to present the findings of a vulnerability assessment to a customer. vulnerability assessment based upon the number of live hosts and also talks about the number of findings with high, moderate, or low risk.

Risk Assessment

Risk assessment as defined before is the analysis part of the report. It is very crucial for the customer because they would want to know the intensity of the damage the vulnerabilities are likely to cause; similarly, the security executives would also want to know how their team is performing.

Risk Assessment Matrix

When we talk about risk assessment analysis in terms of a penetration test, we have to compare the “likelihood of the occurring” and the “impact caused by the occurring.”

After including the risk assessment matrix, you should write a line or two describing the total risk. Based upon the comparison of the vulnerabilities that were determined, their likelihood and their impact we conclude the overall risk is high and the risk percentage was determined to be 82%.

Methodology

We have discussed a wide variety of methodologies and standards of penetration testing, such as OSSTMM, NIST, and OWASP. I would also like to include the methodology that was followed for conducting the penetration test, though its inclusion in the report is optional, it could add great value to your penetration report. In a scenario where you have been asked to follow a certain standard, talking about the methodology and its steps is a good idea.

Detailed Findings

This is where you address the technical audience, specifically the security manager and the developers, also, this is where you are allowed to talk in depth about how the vulnerabilities were discovered, the root causes of the vulnerabilities, the associated risks, and the necessary recommendations.

Let’s now briefly talk about four essentials that should be included in the “Detailed Findings” section.

Description

This is where you talk about the vulnerability itself; a brief explanation should be provided in this section.

Explanation

This is the section where you reveal where the vulnerability was found, how it was found, the root cause of the vulnerability, the proof of concept, or the evidence of the finding.

Risk

This is where you talk about the risks and the likely impact that the vulnerability carries.

Recommendation

This is where you address the developers on how to fix the vulnerability; you may also include general suggestions to avoid that particular class of vulnerability in future.

In the “Description” section we discussed the vulnerability. In the “Explanation” section, we talked about where the vulnerability was found and what line of the programming code is the root cause of the vulnerability. We then talked about general risks and the impact and finally the general remediation to avoid vulnerabilities of a similar class.

Reports

Now that you know the basics and structure of how a penetration testing report is written, I would urge you to spend some time reviewing the following penetration testing sample reports.

• http://www.offensive-security.com/penetration-testing-sample-report.pdf

Conclusion

In this article, we talked about basic terminologies that you will encounter on a daily basis as a penetration tester. We discussed about the types of penetration tests and the different penetration testing methodologies. We then talked about what makes a good penetration testing report. We also looked at how a penetration test report should be laid out in order to provide the target audience the necessary information.