Effective Vulnerability Report Writing — Quick Triages to Bonus $$$ (Always a Win)

Published in

InfoSec Write-ups

8 min readMay 2, 2020

Bug Bounty or Vulnerability research always has two sides. One is to discover & exploit security vulnerabilities and another important side is “Reporting”. From my own experience of writing reports and looking at the reports of others, I have observed that “writing an effective report leads to quick triage, good impression and many times some additional $$$”.

Hey Fellow Hackers, For today, I will be writing about “How to write an effective vulnerability report”.

In a Nutshell, We will discuss:

Importance of writing effective reports
Common Mistakes people often do
Report Writing 101
Understanding the Security Vulnerability
Determining the Impact
Proper Referencing & Calculating CVSS Scores
Steps to Reproduce & Proof-of-Concepts
Remediation — It’s Important
Report Template
A Sample Report
Takeaways

Report writing is a crucial process and it defines how your bug is understood by the triager and customer. The more clear, effective, and precise you will write without trying to bluff, it would be easier for both parties to quickly process.

As a Security Guy, your responsibility just doesn’t end when you find a valid looking vulnerability. Once you know the vulnerability, you have to define the impact as per the business and their risk. Since the security team is going to triage but the developer’s team is going to fix, if you can provide them with a valid solution that they can apply quickly to patch the issue, you make a good impression and might earn some extra $$$.

My Thoughts: If I find a bug and that is not fixed for a couple of years, there is no use for putting that bug to the company’s attention except you make some earning but the sole purpose “Data & Security” is still same.

Some Common Mistakes

(P.S.: No offense)

Using unprofessional language: I often see a few people who write reports very unprofessionally which looks really bad. For example:
> Hey I found an XSS on XYZ Parameter with this payload. If you won’t fix it it would do ABC and that’s it! (Just an example)
Using Abusive Content in Payloads: Often the beginner to sound cool, fire payloads including abusive content (like F*** Security). Now, assume there is a stored XSS in the community forum and you are firing an abusive payload. It is going to affect the company’s reputation. You are there to secure their application in a win-win situation.
Bluffing in Report to Increase Severity: Do not try to unnecessarily increase the impact of a report if you can not escalate. Assuming a theoretical scenario to bluff won’t help. Ex: explaining theoretical scenarios of exploitation of self XSS. Did you even try?
Poor Formatting & Insufficient Proofs: Formatting is Important. Highlighting proper sections and areas. Using proper alignments and code-blocks, all are necessary to make your report impactful. Most people do not pay attention to formatting. We find bugs, We write a paragraph copied and pasted and Reported.
Following up again & again (Being Impatient): Every platform and program have their First Reply Policy. For example: If a Bugcrowd Triage is not replying after 7 days of First Reply Policy, you can ask Support to create a blocker and have things processed. Do not be impatient and jump every next day asking for updates. It’s not just your report on the platform. :)

Rule: Never Bluff in your report. Remember, the triager and customer’s representative both are having Security Background & More Experience.

What could go wrong: A lot. Bluffing may lead to negative reputation, temporary or permanent blockage from program & ultimately your impression goes down.

Report Writing 101

Do you know that many programs pay for “Duplicates” or a “Bonus” if your “Report is Interesting & Good”? It’s really time to focus on writing an amazing report if you are not doing it already and you will surely thank me later for this.

Note: I am not just going to write the XYZ Template in this blog. Rather, I will be taking you through each component and how can you write a good looking report.

101 Rules:

Make sure to use Professional Language.
Include all relevant details but do not make it heavy.
Define Impact Clearly.
Steps to Reproduce should be very Precise. (I repeat Precise)
If you think the attack vector is complex, include a Video Proof-of-Concept.
Remember, most of the companies prefer a textual report with detailed steps and screenshots. They use it for compliance purposes. Keep this in mind.
Remediations are important.

We will look at each of these in detail in the upcoming section to avoid repetition.

Understanding the Security Vulnerability

Security Vulnerabilities can be anything from a simple business logic abuse to complicated Remote Code Execution. It is crucial for you to identify what exact issue you have found. Most of the time it is pretty straight forward like “Stored Cross-Site Scripting”. However, the point here is:

Is it a “Self Stored Cross-Site Scripting”? or you can make any user a victim of this Stored Cross-Site Scripting (Good One)? Before reporting anything you should be clear, what exactly the bug is so you can answer the queries of triager and customer.

From this, you can easily derive your first section of the report “Description”

I usually write Description like following

Description

The application at “https://target.com” provides functionality to create “Content” which is available to “Public View”. During the penetration test, it was observed that the application does not sanitize user-supplied input which allows an attacker to inject malicious javascript code leading into a “Stored Cross-Site Scripting” attack. An attacker would be able to perform malicious actions such as stealing user session cookies or redirecting the user to the attacker-controlled pages.

Does it make sense? How many of you write like that? Would you prefer using this kind of description for your reports? (Share in comments)

Determining the Impact

This is the most crucial and important. you have to make sure you define impact appropriately. I always look for three factors when I determine the impact which is:

Confidentiality: Is user sensitive data is available/read to an unauthorized person.
Integrity: Is it possible to create/delete/update data by an unauthorized person.
Availability: Is it possible for an unauthorized person to cause a denial of service or lockout or availability issues for legitimate users?

Once you know all three factors, it is really super easy to determine the exact impact.

Rule: They should be application-specific. Do not write a generic impact. Every attack vector has a different impact on a different application.

An XSS might be medium for one application but might be critical for another application depending upon the C.I.A. Impact.

CVSS Score & Referencing

CVSS (Common Vulnerability Scoring System) Score helps organizations define the criticality of an issue on a scale of 0 to 10 —None to Critical.

You can read a high-level overview here.

In CVSS 3.0, there are few components which are used to calculate CVSS Score, I’ll explain each of them in short so you can easily calculate the CVSS Score. There are two metrics:

Exploitability Metrics: Determines the overall exploitability score based on several factors.
Impact Metrics: Determines the overall impact score based on several factors.

Exploitability Metrics

Attack Vector — Network/Adjacent Network/Local/Physical
How an attacker is going to attack. For example, if it’s a web application you are accessing remotely, your attack vector is Network.
Attack Complexity — Low/High
How complex it is to reproduce and perform the same attack.
Privileges Required — None/Low/High
What level of privileges are required to perform the attack? If it is an unauthenticated attack, there would be None in Privileges Required.
User Interaction — None/Required
Do you require user interaction to perform the attack? For example: Self XSS requires user interaction.
Scope — Unchanged/Changed
Is there any change in scope? For example: moving from a Target A to Target B after/during the exploit?

Impact Metrics

Confidentiality Impact — None/Low/High
Integrity Impact — None/Low/High
Availability Impact — None/Low/High

We have already discussed these in the above Impact Section.

Based on these scores an overall CVSS Score is calculated. You can use the following CVSS Calculator.

Steps to Reproduce & Proof of Concepts

Rule: Write Clear & Precise steps to Reproduce with relevant screenshots attached with each step wherever required.

Rule: Provide clear navigation and as many detailed steps as you can.

If the attack vector is complicated, attach a video proof-of-concept.

An example of steps to reproduce I use looks like:

Steps to Reproduce

Navigate to “https://target.com” and login as a valid user.
Now, navigate to “Content” > “Create New Content”
In “Content Name” provide the following XSS Payload: <XSS Payload>
Fill all other required details and “Save”
Observe that XSS Payload from step-3 is executed.
<Screenshot Here>
Now log in as another valid user and browse the content created in step-4.
Observe the XSS payload is getting executed.
<Screenshot Here>

Remediation

Remediations are important. Do not just include the generic remediation. Try to see what all remediations are already provided by the application and how they can fix the issue so that it never happens.

For example: if you have found an XSS by bypassing their black-list based filtering, do not just suggest something like “Perform Input Filtering”, rather say “Implement White-list based approach and make sure all input is sanitized accordingly.”

If you have found a CVE based Exploit, provide the link to official patch advisory.
If there is code-level remediation, try to provide a reference for specific developer documentation.