How to Write an Effective Pentest Report: Vulnerability Reports

The pentest process is not limited to executing various test cases to identify security vulnerabilities. It is a multi-step process that, at a high level, includes: planning, initialization, execution, documentation, and wrap-up. It is essential to provide details on what you have identified, convey how you approached the pentest, communicate blockers, offer remediation plans, and share all relevant information. For most pentest engagements, a report is the ultimate deliverable to a customer. So, you must ensure that your report is clean, clear, and effective.

Strong report writing is an effective tool for communicating with a customer. As a pentester this can be especially beneficial for communicating what you have done when testing hardened applications. The report gives an opportunity to explain what the application’s maturity level is, how various attack attempts were blocked or neutralized, and what kind of work was performed during the engagement.

In this two-part blog series, we will focus on various aspects and components of writing an effective report. These articles can be used by a bug bounty hunter, consultant, or anyone who is tasked with writing pentest reports.

When we talk about pentesting there are essentially two types of reports. We will break these up into two blogs according to each report:

1. Vulnerability Report: This report is focused on a specific vulnerability that a pentester identified during the engagement. For every uniquely identified issue, pentesters prepare a vulnerability report that contains enough technical information to help the security and development teams understand the issue, its impact, root cause, and the approach to fixing the issue.

2. Final Report: This report is focused on the overall pentest engagement and presents a high-level summary. This typically includes an executive summary, overall risk profiling, individual vulnerability reports, overall remediation plan, the methodology used, test cases performed, tools used, and other details specific to the engagement.

For the first blog, let’s take a deeper look at writing a vulnerability report:

Vulnerability Report

As mentioned above, a vulnerability report offers a clear summary of a particular finding that was discovered during a pentest. It outlines elements such as the root cause, impact, and overall risk.

To begin, let’s first understand the various components to writing an effective vulnerability report and then we will take a look at a sample report using those points. There are various components in a vulnerability report and they often change from organization to organization, however, we will be discussing the important components that we mainly use, such as:

Vulnerability Title: This section should contain a clear and concise title that gives the reader context about the vulnerability that a pentester has found.

Vulnerability Description: This section should contain a high-level summary of the identified issue and an explanation of the impact it could cause if exploited successfully. This is usually kept general and straightforward to give the reader context about the issue. You can talk here about how the issue works, leaving specifics about the customer’s environment for different sections of the Vulnerability Report.

Affected Component: This section usually contains a URL, Parameter, or another affected resource listed to give more specific information as to where the vulnerability exists.

Affected Users: This section explains which users of the application could be affected if an attacker exploited the issue successfully.

Proof of Concept (Steps to Reproduce): This section is critical, as it contains the detailed steps required to successfully reproduce an issue. Always ensure that the steps are detailed enough for anyone with even little to no security background can successfully reproduce the issue and understand the impact. To create more impactful steps, include proper screenshots and video proofs of concept as and when required.

Criticality: This is an important section because it tells the reader what the overall impact of the vulnerability could be if exploited successfully. Keep the impact description as realistic as possible, instead of writing what may theoretically happen. The best way to do this is to stick to one immediate consequence, such as “an attacker could gain access to a user account”, and not speculate what the attacker could do with that access (as they could do something unexpected). Criticality can be broken down into two parts:

Impact: This section examines the finding's effect on technical and business operations. The OWASP Risk Rating Methodology describes this on a scale of Low to Very High.

Likelihood: This section explains how likely the vulnerability can be exploited by a threat actor. The OWASP Risk Rating Methodology describes this on a scale of Low to Very High.

Exploitation Complexity: This is an optional section, which describes how complicated it is to exploit a vulnerability and what requirements must be met for an attacker to successfully exploit the vulnerability.

Overall Severity: The overall severity is a calculation of Impact x Likelihood. The average of Impact and Likelihood defines the overall severity of the issue. This needs to be measured properly to provide organizations an idea about how to prioritize this vulnerability within the remediation plan.

CVSS Score: CVSS (Common Vulnerability Scoring System) Score helps organizations define the criticality of an issue on a scale of 0 to 10 — no criticality to critical. You can read a high-level overview here.

Tools Used and Setup Required: This section should talk about the tools and setup required to successfully reproduce the vulnerability.

Additional Information: If your vulnerability report requires any additional information specific to the vulnerability or exploitation scenario, you can add it here. This is an optional section, but one that exists to capture details that don’t quite fit into the other sections.

Suggested Fixes (Remediations): This section contains a well-defined and exploitation-specific remediation plan which the developers can use to fix the issue or achieve Defense-in-Depth. Do not provide generic remediation and focus on writing detailed and specific remediations. Begin remediation recommendations with action words in the Imperative (command) form, like “Install”, “Upgrade”, “Ensure”, or “Implement.”.

HTTP Request/Response: This is an optional section that includes the HTTP Requests and Responses you used to exploit the vulnerability.

Additional Sections

Here are some additional sections that may be included in a vulnerability report to provide more in-depth details and references about a security vulnerability.

STRIDE: The STRIDE model is a useful tool to help us understand and classify all possible threats on a target system. Read More about the STRIDE model here.

CWE: The Common Weakness Scoring System (CWSS) provides a mechanism for prioritizing software weaknesses in a consistent, flexible, and open manner. It is a collaborative, community-based effort that is addressing the needs of its stakeholders across government, academia, and industry. Read more about the CWE system here.

CAPEC: The Common Attack Pattern Enumeration and Classification (CAPEC™) effort provides a publicly available catalog of common attack patterns that helps users understand how adversaries exploit weaknesses in applications and other cyber-enabled capabilities. Read more about the CAPEC system here.

Prerequisites: The attacker’s authentication credentials required before exploiting the vulnerability. For example, “an attacker must have admin credentials", "attacker must be a person in the middle-man position," or “N/A” if the application issue requires no authentication.

Note: Content between [any content here] is for explanation purposes only and is not to be included in the report itself.

Sample Vulnerability Report — Template

The following images and text were created as a Sample Vulnerability Report on the Cobalt platform. The information provided is not real pentest data but was created to give you an idea of how a pentester might see the reports on the platform.

Let’s dive in:

Vulnerability Title: Account Takeover due to Insecure Direct Object Reference

Vulnerability Type: Broken Access Control (BAC) > Insecure Direct Object Reference (IDOR)

Vulnerability Description: Access control, sometimes called authorization, is how a web application grants access to content and functions to some users and not others. These checks are performed after authentication, and govern what ‘authorized’ users are allowed to do. Access control sounds like a simple problem but is difficult to implement correctly. A web application’s access control model is closely tied to the content and functions that the site provides. In addition, the users may fall into a number of groups or roles with different abilities or privileges.

Many of these flawed access control schemes are not difficult to discover and exploit. Frequently, all that is required is to craft a request for functions or content that should not be granted. Once a flaw is discovered, the consequences of a flawed access control scheme can be devastating. In addition to viewing unauthorized content, an attacker might be able to change or delete content, perform unauthorized functions, or even take over site administration. A detailed explanation can be found here.

The application utilizes an incremental numerical user identifier to uniquely identify a user account. However, due to missing access controls in place, an attacker can replace the user identifier with the victim user’s identifier and gain access to the victim’s profile information. An attacker can further change the information such as email address which doesn’t require any kind of authentication requirement, allowing an attacker to change the victim email to attacker-controlled email, perform a password reset, and gain complete access to the victim user’s account.

Please note that without any user interaction it is possible to take over any user’s account that may exist in the application system.

Affected URL (Component): https://www.companyabc.tech/profile/:user_id:

Proof of Concept (Steps to Reproduce):

1. Navigate to https://www.companyabc.tech and log in as a valid user.
2. Click the User Avatar > Profile, and the application returns the profile page.
3. URL: https://www.companyabc.tech/profile/3345 [Screenshot]
4. Change the user ID from “3345” to the victim user’s ID, “3300”, then navigate to the modified URL: https://www.companyabc.tech/profile/3300
5. Observe that the victim user’s profile is accessible. [Screenshot]
6. Change the email in the victim user’s profile to the tester-controlled email. The application accepts the email change and does not require authentication verification. [Screenshot]
7. Navigate to https://www.companyabc.tech/forget-pass and request a password reset link, then use it to reset the victim user’s password.
8. Log in to the victim user’s account using a new set of email:password credentials. [Screenshot]
9. For more detailed steps, see the attached Video Proof of Concept [Proof-of-Concept Video].
   
   

Impact or Criticality: Critical An attacker could compromise and gain access to any user’s account, and gain access to any confidential information, modify the account details, or block the access of the original owner. This means an attacker can impact all three factors: Confidentiality, Integrity, andAvailability.

Likelihood: Very High The application has a public registration enabled, which allows anyone to create an account. Also, the user identifier is numerical and incremental which requires no effort in guessing. There is no authentication verification requirement on the email confirmation.

Affected Users: All users that exist in the application system that could be affected.

Overall Severity: Critical Why? — Overall Severity = Impact x Likelihood, which in this case is Critical x Very High, resulting in overall severity of Critical.

CVSS Score: 9.8 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

CWE: 284

Suggested Fix (Remediations):

1. Make sure that the application has proper access controls in place that do not allow an attacker to perform an IDOR attack by tampering with the user ID and a check for authorization verification is implemented properly to prevent this attack from happening.
2. Implement a UUID-based approach to uniquely identify a user account instead of using numerical and incremental IDs.
3. Implement an authentication verification requirement on the email change to ensure that impact is minimized.
   
   

Prerequisites: An attacker would require to be authenticated as a normal user in order to successfully exploit this issue.

HTTP Request/Response:

GET /profile/3345 HTTP/1.1 Host: companyabc.tech User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:88.0) Gecko/20100101 Firefox/88.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Content-Length: 0 Connection: close Referer: https://companyabc.tech Cookie: _ga=GA1.2.683135595.1618850716; _gid=GA1.2.1884052768.1619188179; Upgrade-Insecure-Requests: 1

Final Thoughts & Tips

No matter how small the vulnerability is, you are providing your customer and your team with important building blocks for the final pentest report. Key points to keep in mind:

1. Be precise about the impact and explain properly why a certain severity is assigned.
2. Don’t use generic severity for issues. For example, an IDOR does not necessarily need to be rated as a High Severity, it can be anything between Low to Critical depending on the impact.
3. Be conscious of the report readers.
4. Include screenshots and video Proofs of Concept wherever required. If the navigation is complicated, ensure that you provide proper screenshots with highlighted navigation steps.
5. Write in the Active voice, not the passive voice. In active voice sentences, all actions have a clear actor. For example, “When pentesters attempted [a test action], the application responded by [the test result].”
6. Discuss the vulnerability in the Past Tense. You are trying to capture the point in time in which the pentest took place. While you may be writing right after discovering an issue, the reader may not get to your report for several days--possibly after it’s fixed.
7. Be consistent. If you capitalize “Multi-Factor Authentication”, writing “multi-factor authentication” elsewhere in the report looks a little lazy. If you use terms like “brute-force” or “Wi-Fi” at the beginning of your report, make sure you include the hyphen each time those words appear.

Thank you for checking out this post, hope you found it to be useful. Explore the reporting options offered with Cobalt's penetration testing services, including attestation letters and other reports specific for your stakeholder needs.