Introduction to Hacking
There are many definitions for “hacker.” Ask this question from a phalanx and you’ll get a new
answer every time because “more mouths will have more talks” and this is the reason behind
the different definitions of hackers which in my opinion is quite justified for everyone has a
right to think differently.
In the early 1990s, the word “hacker” was used to describe a great programmer, someone who
was able to build complex logics. Unfortunately, over time the word gained negative hype, and the
media started referring to a hacker as someone who discovers new ways of hacking into a system,
be it a computer system or a programmable logic controller, someone who is capable of hacking
into banks, stealing credit card information, etc. This is the picture that is created by the media
and this is untrue because everything has a positive and a negative aspect to it. What the media has
been highlighting is only the negative aspect; the people that have been protecting organizations
by responsibly disclosing vulnerabilities are not highlighted.
However, if you look at the media’s definition of a hacker in the 1990s, you would find a few
common characteristics, such as creativity, the ability to solve complex problems, and new ways of
compromising targets. Therefore, the term has been broken down into three types:
TYPE OF HACKER:-
1. White hat hacker—This kind of hacker is often referred to as a security professional or security
researcher. Such hackers are employed by an organization and are permitted to attack
an organization to find vulnerabilities that an attacker might be able to exploit.
2. Black hat hacker—Also known as a cracker, this kind of hacker is referred to as a bad guy,
who uses his or her knowledge for negative purposes. They are often referred to by the media
as hackers.
3. Gray hat hacker—This kind of hacker is an intermediate between a white hat and a black
hat hacker. For instance, a gray hat hacker would work as a security professional for an
organization and responsibly disclose everything to them; however, he or she might leave a
backdoor to access it later and might also sell the confidential information, obtained after
the compromise of a company’s target server, to competitors.
Similarly, we have categories of hackers about whom you might hear oftentimes. Some of them
are as follows:
1 Script kiddie—Also known as skid, this kind of hacker is someone who lacks knowledge on how
an exploit works and relies upon using exploits that someone else created. A script kiddie
may be able to compromise a target but certainly cannot debug or modify an exploit in case
it does not work.
(From http://cdn.kaskus.com and http://the-gist.org.)
2 Elite hacker—An elite hacker, also referred to as l33t or 1337, is someone who has deep knowledge
on how an exploit works; he or she is able to create exploits, but also modify codes that
someone else wrote. He or she is someone with elite skills of hacking.
3 Hacktivist—Hacktivists are defined as group of hackers that hack into computer systems for a
cause or purpose. The purpose may be political gain, freedom of speech, human rights, and
so on.
4 Ethical hacker—An ethical hacker is as a person who is hired and permitted by an organization
to attack its systems for the purpose of identifying vulnerabilities, which an attacker might
take advantage of. The sole difference between the terms “hacking” and “ethical hacking”
is the permission.
Important Terminologies
Let’s now briefly discuss some of the important terminologies that I will be using throughout this
session.
Asset
An asset is any data, device, or other component of the environment that supports information related
activities that should be protected from anyone besides the people that are allowed to view
or manipulate the data/information.
Vulnerability
Vulnerability is defined as a flaw or a weakness inside the asset that could be used to gain unauthorized
access to it. The successful compromise of a vulnerability may result in data manipulation,
privilege elevation, etc.
Threat
A threat represents a possible danger to the computer system. It represents something that an organization
doesn’t want to happen. A successful exploitation of vulnerability is a threat. A threat may
be a malicious hacker who is trying to gain unauthorized access to an asset.
Exploit
An exploit is something that takes advantage of vulnerability in an asset to cause unintended or
unanticipated behavior in a target system, which would allow an attacker to gain access to data
or information.
Risk
A risk is defined as the impact (damage) resulting from the successful compromise of an asset. For
example, an organization running a vulnerable apache tomcat server poses a threat to an organization
and the damage/loss that is caused to the asset is defined as a risk.
Normally, a risk can be calculated by using the following equation:
Risk = Threat * vulnerabilities * impact
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.
Preengagement
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.
If you need a more thorough documentation, refer to the “PTES Pre-engagement” document
(http://www.pentest-standard.org/index.php/Pre-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
Planning Discovery
Reporting
Additional discovery
Attack
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.”
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 chapter.
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,
they 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
Labels: CYBER SECURITY, intro to hacking
