11.2. Types of Assessments
Now that you have ensured that your Kali environment is ready, the next step is defining exactly
what sort of assessment you are conducting. At the highest level, we may describe four types of
assessments: a vulnerability assessment, a compliance test, a traditional penetration test, and an applica-
tion assessment. An engagement may involve various elements of each type of assessment but it is
worth describing them in some detail and explaining their relevance to your Kali Linux build and
environment.
Before delving into the different types of assessments, it is important to first note the difference
between a vulnerability and an exploit.
A vulnerability is defined as a flaw that, when taken advantage of, will compromise the confiden-
tiality, integrity, or availability of an information system. There are many different types of vul-
nerabilities that can be encountered, including:
• File Inclusion:
File inclusion vulnerabilities
1
in web applications allow you to include the
contents of a local or remote file into the computation of a program. For example, a web
application may have a ”Message of the day” function that reads the contents of a file and
includes it in the web page to display it to the user. When this type of feature is programmed
incorrectly, it can allow an attacker to modify their web request to force the site to include
the contents of a file of their choosing.
• SQL Injection: A
SQL injection
2
attack is one where the input validation routines for the
program are bypassed, allowing an attacker to provide SQL commands for the targeted pro-
gram to execute. This is a form of command execution that can lead to potential security
issues.
• Buffer Overflow: A
buffer overflow
3
is a vulnerability that bypasses input validation rou-
tines to write data into a buffer’s adjacent memory. In some cases, that adjacent memory
location may be critical to the operation of the targeted program and control of code exe-
cution can be obtained through careful manipulation of the overwritten memory data.
• Race Conditions: A
race condition
4
is a vulnerability that takes advantage of timing depen-
dencies in a program. In some cases, the workflow of a program depends on a specific
sequence of events to occur. If you can alter this sequence of events, that may lead to a
vulnerability.
An exploit, on the other hand, is software that, when used, takes advantage of a specific vulner-
ability, although not all vulnerabilities are exploitable. Since an exploit must change a running
process, forcing it to make an unintended action, exploit creation can be complex. Furthermore,
there are a number of anti-exploit technologies in modern computing platforms that have been
1
https://en.wikipedia.org/wiki/File_inclusion_vulnerability
2
https://en.wikipedia.org/wiki/SQL_injection
3
https://en.wikipedia.org/wiki/Buffer_overflow
4
https://en.wikipedia.org/wiki/Race_condition
287
Chapter 11 — Introduction to Security Assessments
designed to make it harder to exploit vulnerabilities, such as
Data Execution Prevention
5
(DEP) and
Address Space Layout Randomization
6
(ASLR). However, just because there is no publicly-known
exploit for a specific vulnerability, that does not mean that one does not exist (or that one can not
be created). For example, many organizations sell commercialized exploits that are never made
public, so all vulnerabilities must be treated as potentially exploitable.
11.2.1. Vulnerability Assessment
A vulnerability is considered a weakness that could be used in some manner to compromise the
confidentiality, integrity, or availability of an information system. In a vulnerability assessment,
your objective is to create a simple inventory of discovered vulnerabilities within the target envi-
ronment. This concept of a target environment is extremely important. You must be sure to stay
within the scope of your client’s target network and required objectives. Creeping outside the
scope of an assessment can cause an interruption of service, a breach of trust with your client, or
legal action against you and your employer.
Due to its relative simplicity, a vulnerability test is often completed in more mature environments
on a regular basis as part of demonstrating their due diligence. In most cases, an automated tool,
such as the ones in the
Vulnerability Analysis
7
and
Web Applications
8
categories of the Kali tools
site and Kali desktop applications menu, is used to discover live systems in a target environment,
identify listening services, and enumerate them to discover as much information as possible such
as the server software, version, platform, and so on.
This information is then checked for known signatures of potential issues or vulnerabilities. These
signatures are made up of data point combinations that are intended to represent known issues.
Multiple data points are used, because the more data points you use, the more accurate the iden-
tification. A very large number of potential data points exist, including but not limited to:
• Operating System Version: It is not uncommon for software to be vulnerable on one op-
erating system version but not on another. Because of this, the scanner will attempt to
determine, as accurately as possible, what operating system version is hosting the targeted
application.
• Patch Level: Many times, patches for an operating system will be released that do not in-
crease the version information, but still change the way a vulnerability will respond, or
even eliminate the vulnerability entirely.
• Processor Architecture: Many software applications are available for multiple processor
architectures such as Intel x86, Intel x64, multiple versions of ARM, UltraSPARC, and so on.
5
https://en.wikipedia.org/wiki/Executable_space_protection#Windows
6
https://en.wikipedia.org/wiki/Address_space_layout_randomization
7
https://tools.kali.org/category/vulnerability-analysis
8
https://tools.kali.org/category/web-applications
288
Kali Linux Revealed
In some cases, a vulnerability will only exist on a specific architecture, so knowing this bit
of information can be critical for an accurate signature.
• Software Version: The version of the targeted software is one of the basic items that needs
to be captured to identify a vulnerability.
These, and many other data points, will be used to make up a signature as part of a vulnerability
scan. As expected, the more data points that match, the more accurate the signature will be. When
dealing with signature matches, you can have a few different potential results:
• True Positive: The signature is matched and it captures a true vulnerability. These results
are the ones you will need to follow up on and correct, as these are the items that malicious
individuals can take advantage of to hurt your organization (or your client’s).
• False Positive: The signature is matched; however the detected issue is not a true vulnera-
bility. In an assessment, these are often considered noise and can be quite frustrating. You
never want to dismiss a true positive as a false positive without more extensive validation.
• True Negative: The signature is not matched and there is no vulnerability. This is the ideal
scenario, verifying that a vulnerability does not exist on a target.
• False Negative: The signature is not matched but there is an existing vulnerability. As bad
as a false positive is, a false negative is much worse. In this case, a problem exists but the
scanner did not detect it, so you have no indication of its existence.
As you can imagine, the accuracy of the signatures is extremely important for accurate results.
The more data that is provided, the greater the chance there is to have accurate results from an
automated signature-based scan, which is why authenticated scans are often so popular.
With an authenticated scan, the scanning software will use provided credentials to authenticate
to the target. This provides a deeper level of visibility into a target than would otherwise be possi-
ble. For instance, on a normal scan you may only detect information about the system that can be
derived from listening services and the functionality they provide. This can be quite a bit of infor-
mation sometimes but it can’t compete with the level and depth of data that will be obtained if you
authenticate to the system and comprehensively review all installed software, applied patches,
running processes, and so on. This breadth of data is useful for detecting vulnerabilities that oth-
erwise may not have been discovered.
A well-conducted vulnerability assessment presents a snapshot of potential problems in an organi-
zation and provides metrics to measure change over time. This is a fairly lightweight assessment,
but even still, many organizations will regularly perform automated vulnerability scans in off-
hours to avoid potential problems during the day when service availability and bandwidth are
most critical.
As previously mentioned, a vulnerability scan will have to check many different data points in
order to get an accurate result. All of these different checks can create load on the target system
as well as consume bandwidth. Unfortunately, it is difficult to know exactly how many resources
will be consumed on the target as it depends on the number of open services and the types of
289
Chapter 11 — Introduction to Security Assessments
checks that would be associated with those services. This is the cost of doing a scan; it is going to
occupy system resources. Having a general idea of the resources that will be consumed and how
much load the target system can take is important when running these tools.
|
