How to write a great vulnerability report (#Bug_bounty)

How to write a great vulnerability report

Submitting a bug to a company can be a tricky thing. As one might expect, security vulnerabilities are not always very straightforward- they might require multiple steps to reproduce, or utilize techniques that others aren’t familiar with. And when explaining steps to others, describing even seemingly simple concepts can be quite hard

Introduction:

In the bug bounty world you sometimes come across the following type of vulnerability reports:

 Don’t forget you need to sell your service. You need to show the program owners that you care about their security and that you can talk the talk.

Prepare before you test

Being professional and understanding what the business is looking for often makes the difference between earning a few bucks and hitting a homerun.

To start, carefully read the program scope and rules of engagement. 
This is one of the most important things to do before you begin researching. Imagine spending time writing an awesome report and then in the end the program owner tells you it’s out of scope — it’s frustrating. It happened to me when I first started working on bug bounty programs. I didn’t spend enough time on reading the program scope. If you have specific questions about the scope, contact the program owner/curator by email or use the comments on another report to contact them.

Writing a good Report:

After you have done some research and found a great vulnerability the next step is to make a good report of your findings. To help you guys out, I have explained some of the guidelines I use for writing good reports. 

Report Format

While writing a vulnerability report it is important to include every bit of important information within your initial report. Before writing your report keep a few things in mind:

Your report could help determine the appropriate bounty amount.
The person reading your report only knows about your vulnerability as much as you allow them to, so remember to provide as much information as needed for them to reproduce the bug.

If you are unsure of the Engineer/Analyst on the program, write your report as though someone with no experience with the application is able to reproduce the issue.

Title of the vulnerability:

This is the first thing that the client sees and really should shine some light on the particular vulnerability you have found. A good title would include the type of bug found, where it was found, and the overall impact. For example “Remote File Inclusion in Resume Upload Form Allows Remote Code Execution”, is a lot better title than “RFI Injection found in app”. You have articulated in the title just exactly what you have found, where you found it, and the reach of the vulnerability

Include vulnerability type (XSS, CSRF, XXE, SQLi, SSRF, etc)
Include vulnerable (sub)domain and/or endpoint/component (www.site.com/patht/to/file)

Example of good titles:

Reflected XSS in dashboard.bugbountyprogram.com/profiles via name parameter
Remote Command Execution in upload.bugbountyprogram.com/upload.php

Examples of a bad titles:

Stored XSS foundbugbounty.com

Keep in mind that this is the first thing that program owner will see. It’s their first impression of you and your report.

Description:

A vulnerability description must be short, clear, and direct. Program owners don’t want to spend much time reading.

A great way to describe a vulnerability in a short clear way is to give references/links to things that can help them understand, identify, and fix the report. This could be OWASP, CVE references or similar public advisories. (Don’t reference Wikipedia or other less security respected links.)

E.g. if I find a XSS I’ll try to explain what it is — giving the OWASP reference — telling them what type of XSS and so on. Also if it was the first time submitting a report to the program, I’ll present myself and say “hello” — There’s nothing wrong with showing a little politeness.

Don’t copy-paste information from automated tools or other sources into the description. It shows the program that you didn’t even have time to write a few words.

Proof-of-concept:

In the proof-of-concept, I always treat the recipient or program owner as if he/she is a newbie. I do so by giving a clear step-by-step guide on how to replicate the vulnerability.

Example of a XSS proof-of-concept:

Step 1: Go to the following [URL]
           (URL: self explanatory, but important to double check. This is where the client is                                going to be focusing a lot of their time trying to validate your submission.)

Step 2: Put your username and password (If you need an account to do this)

Step 3: On the Search box at the top right insert the following information:

<script>alert(document.domain);</script>

Step 4: Click the “Search” button

Step 5: You’ll see a Javascript popup box showing your domain

Check the attached screenshot to see the actual XSS vulnerability.

Sometimes (depending on the type of vulnerability) I also show the reflected code so the program owner can identify faster where the payload is loading:


Criticality Assessment:

To give the program owner an idea about criticality you can explain how a malicious user could exploit the vulnerability you found. Describe a possible scenario — describing how and what the company (and its clients) can loose with this vulnerability.

Tools:

Share what tools you used when finding the vulnerability. If you only used the browser, tell then what version you tested. On particular type of vulnerabilities the proof-of-concept will only work on some versions so be specific.

Example: Burp, Nmap and Firefox 47.0

Attachments:

Provide screenshots or even a video to improve and add value to your report.


The attached screenshots shows the location of the vulnerability.

Sometimes program owners can’t replicate the vulnerability so helping them with images or a step-by-step video will help them significantly.

If you can’t do a video, just send the program an audio version on how to replicate your report. This will also show the program owners that you took time to create a good report and they may even evaluate you a little higher for the extra effort.

Suggested Fixes/Solutions:

Show the program owners clear solutions for their problem. Give examples, don’t just tell them to sanitize the input, but also give them references and possible ways to do it. They’ll greatly appreciate it. Sometimes the developers don’t know how to fix a vulnerability, and if you provide a great description of a suggested fix it’s a win-win situation. After all, the key mission is to fix the vulnerabilities.

Comments:

Comments are great when/if the program owners need clarification on the report.

Always be polite when communicating with the program owners and don’t continually ask them for updates. You can ask them once or twice every month, and if you are not getting any feedback you can contact the platform support team to help moderate the issue.

Conclusion:

The main goal is to show the program owner that security researchers are there to help– working on their side against the bad guys. The problem is that sometimes that connection is not established. By being professional and writing great reports you can help build a stronger relationship with the program owners.

I hope this blog post will help improve your reports, and benefit your bug bounty programs along the way.