How to make a report on the identified vulnerability

Everyone who participated in bug bounty programs knows that the “hole” found is not a reason to demand money and fame. Description of the problem, tools for its detection - it is important to describe all this in a competent report.

We have translated an actual article from the blog of the American company Cobalt, which provides pentesting services as a service. Researcher David Sopas talks about the mistakes that users make and how they actually need to write reports to earn real money, not bonus kopecks.

About sore

In practice, reports about the following look sometimes come from bug bounty program participants:
')
“Guys, you have no SPF record on your mail server.
Check for yourself: http: // ".

Or there are requests for increasing the premium:

“A researcher [such and such] received $ 100 for the same report.
Can you pay me 50 more?
Please, I deserve more! ”

Any curator of the program will assign such reports to the category of WTF. Not because of the vulnerability itself, but because of the lack of detailed information and attempts to properly convey it from the pentester. Do not forget, you are trying to sell your services, so you must show the program owner that you are really interested in the safety of his product, and at the same time know how to apply yourself correctly.

A good report of the found vulnerability significantly affects the success of the entire work.

Preparation before the study

To get started, carefully read the tasks and rules of the program. This is one of the things that you definitely need to do BEFORE you begin to search for vulnerabilities. Imagine your disappointment when, after receiving your high-quality and experienced report, the owner of the program will respond that the search for such vulnerabilities was not included in the list of tasks.

If you have specific questions about the tasks of the program, it is better to contact its owner / curator by e-mail or ask your question in the comments to someone else's report.

After you have found a serious vulnerability, the next step is to report on the results. Below is a list of recommendations that will allow you to write a quality report.

Title for the found vulnerability

Write about the essence of the vulnerability. No need for loud "tabloid" headers.

An example of a good name: Reflected XSS on the product page
Bad name example: CRITICAL - XSS in your program

Remember that the name will be the first that the curator or the owner of the program will see. So the first impression about you and your report, he will make it on this point.

Description

The description of the found vulnerability should be short, clear and clearly formulated. Program owners do not want to spend a lot of time reading reports.

A great way to describe a vulnerability quickly and clearly is to give links to projects that will help the owner to understand its essence, identify and eliminate. For example, you can find links to OWASP, CVE or other similar security projects (links to Wikipedia and other not very reliable sources are better not to use as confirmation).

For example, if I find an XSS vulnerability, I try to explain in the report what I specifically found (with reference to OWASP) and how it can turn around. In addition, if I take part in this program for the first time, I will definitely introduce myself and begin the report with a greeting. A little politeness has not hurt anyone.

No need to just copy the information from the logs of automated testing tools and similar sources to the report. So the program management can decide that you did not have the time (or desire) to describe everything yourself.

Experimental evidence of vulnerability

In this part, you should try to write as if the recipient of the report and / or the program curator are new to this field. Therefore, it is better to make a short list of the steps necessary to reproduce the identified vulnerability.

An example of experimental confirmation for a detected XSS vulnerability:

Step 1: follow this link [Link Address].

Step 2: Enter your username and password (for this step you will need a valid account on the site).

Step 3: In the search field in the upper right corner, enter the text:



Step 4: Click on the “Search” button.

Step 5: You will see a Javascript popup window with your domain.

Please see the attached screenshot, which shows the XSS vulnerability I discovered.

Sometimes (depending on the type of vulnerability found) it is recommended to send a part of the page code so that the program owner can quickly find the place in which it appears:

Criticality rating

In order for the program owner to better understand the degree of criticality of the found vulnerability, it is worthwhile to give a specific example of how an unscrupulous user can use it for his own purposes. Describe a similar situation and indicate how, what and why, as a result, the company (and its clients) may lose.

Tools used

Tell us what tools and programs you used to identify vulnerabilities. If you used only the browser, be sure to specify its version. Some vulnerabilities can be reproduced only on certain versions of the software, so here it is worth giving the most complete information.

Example: Burp, Nmap and Firefox 47.0

Attachments

Attached screenshots (and in some situations even video files) will help make the report clearer and increase its value.

Sometimes the owners fail to reproduce the vulnerability that you found, so step-by-step video or screenshots with an illustration of the process can be very useful.

If for some reason you cannot capture the process on video, you can send an audio file with a description of the process to the program. This will help to reproduce the identified vulnerability and will show the program owners that you have really made efforts in the preparation of the report, that is, it will give you an advantage in evaluating it.

Suggested mitigation techniques

Offer program owners specific and understandable solutions. Do not just advise them to “clean” the code, but give links to resources that indicate how this can be done. Believe me, they will appreciate such a move. Sometimes the developers themselves do not know how to fix the vulnerability, so a detailed description of your vision may well help. And it is beneficial for both parties, because the main thing is to fight vulnerabilities.

Comments

Comments are a great tool that will come in handy when / if the program owner needs some explanation about the information in the report.

In the process of communication, it is always worth being polite. No need to constantly ask if there is any new information on the report you sent. One or two messages per month with a request to provide feedback is quite enough, but if you don’t respond for a long time, you can always contact the platform’s support service and ask you to sort out the situation.

Conclusion

Our main goal is to show the program owner that pentesters and security specialists first of all want to help. We are all on the same side and can work together against the "bad guys." The problem is that not everyone agrees with this opinion. That is why professionalism and quality reports are important for building normal relations with program owners.

Together with the author, we hope that after reading this article, your reports will become better, and the premiums for the identified vulnerabilities - more!

---

If you want to start working with bug bounty programs or take tasks more difficult - you need to have a confident knowledge of web application pentesting. Independently picking other sites can have sad consequences. Ethical hacking is a delicate matter that requires careful training and adherence to security policies. To learn how to look for vulnerabilities, write reports on them and use the entire arsenal of an ethical hacker with confidence, take a closer look at our Professional Pentester course. The second qualifying course starts in April.