Scribd
Upload
6 views6 pages

Cyber Unit 1 CH 2

The document discusses the common misconceptions and limitations of vulnerability assessments, penetration testing, and red team exercises, emphasizing the importance of understanding their definitions and potential pitfalls. It highlights issues such as false positives and false negatives in vulnerability scans, the limitations of penetration testing in only utilizing known exploits, and the structured nature of red team exercises that may not reflect real-world attack scenarios. Overall, it stresses the necessity of using multiple tools and techniques for effective vulnerability identification and assessment.

Uploaded by

2070GYANENDRA DUBEY
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
6 views6 pages

Cyber Unit 1 CH 2

The document discusses the common misconceptions and limitations of vulnerability assessments, penetration testing, and red team exercises, emphasizing the importance of understanding their definitions and potential pitfalls. It highlights issues such as false positives and false negatives in vulnerability scans, the limitations of penetration testing in only utilizing known exploits, and the structured nature of red team exercises that may not reflect real-world attack scenarios. Overall, it stresses the necessity of using multiple tools and techniques for effective vulnerability identification and assessment.

Uploaded by

2070GYANENDRA DUBEY
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 6

Common pitfalls of vulnerability assessments, penetration testing, and red team

exercises

In this section, we will discuss some misconceptions and limitations regarding


traditional/classical vulnerability scanning, penetration testing, and red team
exercises. Let us now understand the actual meaning of these three topics in
simple terms and their limitations:

What Is Considered a Vulnerability?

A vulnerability is any security weakness within a network, infrastructure, or other


system that can potentially allow external threat actors to gain unauthorized
control or access to an application, endpoint, service, or server.

Common software vulnerabilities include:

Lack of authorization and data encryption.

Insufficient authentication for critical functions.

Operating system command injection.

Buffer overflow.

Unrestricted upload of suspicious file types.

Vulnerability Assessment (VA): The process of identifying vulnerabilities or


security loopholes in a system or network through a vulnerability scanner. One of
the misconceptions about VA is that it will let you find all of the known
vulnerabilities; well, that’s not true. Limitations with VA include that only
potential vulnerabilities are found, and it depends purely on the type of scanner
that you utilize. It might also include a number of false positives and, to the
business owner, there is no clear indication as to which ones do not pose a
relevant risk and which one will be initially utilized by the attackers to gain access.
The biggest pitfall of VA is false negatives, meaning the scanner did not find an
issue that the system or application has.

Processing reports

False positives and false negatives

Vulnerability scanners generate reports of the vulnerabilities they find, but before
we discuss how these reports are used, we must discuss False Positives and False
Negatives.

Both false positives and false negatives are errors in the results of a scan.

A false positive is when the scanner says there is a vulnerability, but there
actually isn’t a vulnerability. This can waste the time of security personnel trying
to fix a vulnerability that simply doesn’t exist.

A false negative is when the scanner says there isn’t a vulnerability, but there
actually is. This means that even if a scan says it found 0 vulnerabilities, that
doesn’t mean there are no vulnerabilities present.

Vulnerability Scans and False Positives

The importance of checking a web application for vulnerabilities is well


understood, but it can take a lot of skill and time to do this manually.

There are many tools available that can automate the process but, as with all
tools, it is important to understand their limitations.
Web application scanning tools will automatically review a website by crawling
through all its links, reviewing each page using an algorithm to match responses
to signatures.

If a match is found, the tool may perform additional checks to determine a degree
of certainty, if there is a vulnerability.

Example 1:

Using its database of signatures, the scanner identifies that a version of a library
in use has vulnerabilities. It then reports the vulnerability and the page it was
found on.

Example 2:

The scanner identifies an input field, which it tests to see if a blind injection attack
is possible, inserting input that contains a delay and monitoring the speed of
response for a delay. The response takes longer than normal, so the scanner
marks the input field as being vulnerable to a blind injection attack.

However, are these genuine vulnerabilities? During a manual vulnerability test or


penetration test, the tester will try to verify such findings before producing the
report.

Example 3:
The tester attempts to get the web application to run the vulnerable function in
the library; if it does, it is a genuine vulnerability. If the application does not use
the function or allow the tester to trick it into calling the vulnerable function, it is
not a vulnerability.

Example 4:

The tester uses a range of inputs with different delays to see if the response time
changes correspondingly, while examining the output. If the response time
changes according to the delay, it is a genuine vulnerability. If the response time
is constant or the output explains the delay, such as a timeout because the
application didn’t understand the input, then it is a false positive.

Automated scanners’ lack of precision about their findings is their most


contentious issue, especially when testing web applications.

It is also important to understand they will not necessarily find all vulnerabilities.
The same goes for human testing.

False positives and false negatives

Whether you are using a vulnerability scanning tool or another form of


vulnerability identification, there are two types of errors to be aware of:

Type I error – false positive, a result that indicates a vulnerability is present when
it is not. This creates noise and results in unnecessary remediation work.

Type II error – false negative, where a vulnerability is present but is not identified.
The false negative is the more serious error, as it creates a false sense of security.
How to identify false negatives is beyond the scope of this article, but our general
advice is to use multiple tools and techniques for vulnerability identification, and
not to assume a clean result from a tool or tester means you are 100% secure.

Penetration testing (pentesting): The process of safely simulating the hacking


scenarios by exploiting vulnerabilities without much impact on the existing
network or business. There is also a lower number of false positives since testers
will try to validate the vulnerabilities and also attempt to exploit them. A
limitation with pentesting is that it uses only currently known, publicly available
exploits; mostly, these are a focus for project testing. We often hear from
pentesters during an assessment, Yay! Got Root—but we never hear the question,
what can you do with it? This could be due to various reasons such as project
limitations, including the reporting of high-risk issues immediately to the client, or
the client only being interested in one segment of the network and only wanting
that part tested.

One of the misconceptions about the pentest is that it provides the attacker with
a full view of the network, and you are safe once penetration testing has been
performed. This is not the case when attackers have found a vulnerability in the
business process of your secure application.

Red Team Exercise (RTE): A focused process of evaluating the effectiveness of an


organization to defend against cyber threats and improve its security by any
possible means; during an RTE, we can discover multiple ways of achieving project
objectives/scenarios and goals, such as complete coverage of activities with the
defined project goal, including phishing (enticing a victim to enter sensitive
information or download malicious content through emails), vishing (enticing a
victim to provide or do some actions with malicious intent through phone calls),
“WhatsApping” (engaging a victim through WhatsApp messenger with malicious
intent), wireless, disk drops (USB and SSD), and physical penetration testing. The
limitations with RTEs are time-bound, pre-defined scenarios and an assumed
rather than real environment. Often, the RTE is run with a fully monitored mode
for every technique, and tactics are executed according to the procedure, but this
isn’t the case when a real attacker wants to achieve an objective.
Figure 1.1 showcases the difference between all three activities in terms of the length and breadth of
their focus:

Figure 1.1: The three methods of assessing the vulnerability of systems and the breadth and depth to
which they are successful

Often, all three different testing methodologies refer to the term hack or
compromise. We will hack your network and show you where your weaknesses
are; but wait, does the client or business owner understand the difference
between these terms? How do we measure it? What are the criteria? And when
do we know that the hack or compromise is complete? All the questions point to
only one thing: what the purpose of the testing is, and what the primary goal in
mind is.

You might also like