Documentation< Previous | Contents | Next >
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 vulnerabilities1 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 injection2 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 overflow3 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 condition4 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
1https://en.wikipedia.org/wiki/File_inclusion_vulnerability 2https://en.wikipedia.org/wiki/SQL_injection 3https://en.wikipedia.org/wiki/Buffer_overflow 4https://en.wikipedia.org/wiki/Race_condition
designed to make it harder to exploit vulnerabilities, such as Data Execution Prevention5 (DEP) and Address Space Layout Randomization6 (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.