Pentest: Which Components should be Considered First?

Every system has vulnerabilities - there is no such thing as absolute security. Penetration testing helps you identify and fix those vulnerabilities. But modern applications are becoming increasingly complex: in addition to the core application, functions are usually added that are integrated by third-party providers via API. Resources for pen testing are limited. Therefore, many organizations ask themselves the question: Which components of my software are particularly at risk and should therefore be checked first in a pen test?

Systematically Assess Vulnerabilities with CVSS

Every system has vulnerabilities. But not every vulnerability is equally important. In addition to the access vector, complexity and authentication, impacts on confidentiality, integrity and availability also play a role in vulnerability assessment.

The Common Vulnerability Scoring System (CVSS) is often used for scoring. The CVSS provides organizations with the ability to quantitatively express the vulnerabilities of their architecture. Each value corresponds to one of four vulnerability categories:

Vulnerabilities with Critical Severity

Critical vulnerabilities allow attackers to execute their own code on the target system or access sensitive data. Common critical vulnerabilities include BOLA, remote code execution or command injections.

High severity vulnerabilities allow attackers to access an application's resources and data. This allows him to steal sensitive data. A well-known example of a high severity vulnerability is SQL injection. Here, the attacker manages to access the system's database via user-defined fields. Unlike the critical vulnerability, high severity vulnerabilities alone can never lead to the disclosure of all data. For this, attackers need to find additional attack vectors.

Medium Severity Vulnerabilities

A medium-severity vulnerability can most often be traced to errors in the configuration - for example, a faulty SSL certificate. This allows attackers to access sensitive information. However, such a gap places high demands on the attacker. In the case of the wrong certificate, for example, he must be in a specific location in order to read data at the right time.

Low Severity Vulnerabilities

Low severity vulnerabilities are either due to errors in configuration or accidental disclosure of information, and are not likely to cause significant damage in their impact. However, these vulnerabilities can be a basis for an attacker to exploit more severe vulnerabilities. An example of a low severity vulnerability is version number disclosure. If a website discloses the version number of an application, an attacker can perform vulnerability mapping. If a vulnerability already exists for that application in the version, he can use it to then gain access to the system.

Which Components are at Risk?

From the categorization of vulnerabilities, conclusions can be drawn about proper prioritization during penetration testing.

Based on severity levels, certain areas of the software architecture are more vulnerable than others. Mobile applications are at most affected by vulnerabilities with a high severity level. Above that, it can only attack individual users, but not access all the data in the system.

Modern applications are not built from scratch. Every web application accesses external services to incorporate important standard functions whose in-house development is not practical or not possible. These include captchas, credit card payments, or e-mail address validations. Such API interfaces, on the other hand, can have critical vulnerabilities that put the entire system at risk. This is because an API interface reaches deep into the system qua function. Whoever gains access to the API interface thus has a kind of master key at hand.

BOLA: API Vulnerability #1

Today's biggest vulnerability of API interfaces is Broken Object Level Authorization - BOLA. This is the conclusion reached by the Open Web Application Security Project OWASP in its report on the top 10 API vulnerabilities.

BOLA was the vulnerability responsible for many popular attacks. The victims of these attacks included Telekom and Apple. BOLA refers to authorization flaws in the API interface. A popular example is the vulnerability in the app of the cab company Uber, which became known in 2019.

The cab company asked for the user's email address and phone number, checking the format. Now, if the email address and phone number are swapped, Uber's API returns an error message containing UUID - the user's unique identifier. Using this vulnerability, it would be possible to get the user's UUID based on the phone number or email address.

Prioritize Penetration Testing: Check API first

For most applications, it makes sense to check the API interface first. It is exclusively here that vulnerabilities of severity critical can arise when considered in the context of mobile apps. As a result, an attacker can gain access to all user data in the worst-case scenario. In addition to the resulting economic damage, the image damage caused by such a vulnerability is also massive.

A system such as the CVSS helps you to assess the imminent dangers and weigh them up against each other in a meaningful way. The CVSS provides a tool for quantification on your website. Security tools like Netsparker also prioritize the vulnerabilities they find. For a long time, Netsparker relied on its own rating system. In the meantime, however, you can also have your reports evaluated according to CVSS 3.1.