How to correctly report a vulnerability
Everyone who participated in bug bounty programs knows that the found “hole” is not a reason to demand money and fame. Description of the problem, tools for its detection - all this is important to describe in a competent report.
We have translated the current article from the blog of the American company Cobalt, which provides pentesting services as a service. Researcher David Safop talks about what mistakes users make and how to actually write reports in order to earn real money, not bonus cents.
In practice, bug bounty program participants sometimes receive reports of the following kind:
“Guys, you do not have an SPF record on your mail server.
Check for yourself: http: // ".
Or there are requests to increase the premium:
“The researcher [such-and-such] received $ 100 for the same report.
Can you pay me 50 more?
Please, I deserve more! ”
Any program curator will classify such reports as 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 that you are trying to sell your services, therefore you must show the program owner that you are really interested in the safety of his product, and at the same time be able to present yourself correctly.
A good report of the vulnerability found significantly affects the success of all work.
Preparation before the study
First, carefully read the tasks and rules of the program. This is one of the things that must be done BEFORE you start searching for vulnerabilities. Imagine your disappointment when, after receiving your quality and suffering report, the owner of the program will answer 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.
Once you find a serious vulnerability, the next step should be to report on the results. Below is a list of recommendations that will allow you to write a quality report.
Title for found vulnerability
Write about the nature of the vulnerability. No need for loud "tabloid" headlines.
Example of a good name: Reflected XSS on the product page
Example of a bad name: CRITICAL - XSS in your program
Remember that the name will be the first that the curator or program owner sees. So he will make the first impression of you and your report on this point.
The description of the vulnerability found should be concise, understandable 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 easily is to provide links to projects that will help the owner understand its essence, identify and eliminate it. 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 evidence).
For example, if I find an XSS vulnerability, in the report I try to explain what I specifically found (with reference to OWASP) and what it could turn into. In addition, if this is my first time participating in this program, I will certainly introduce myself and start the report with a welcome. A little politeness has not hurt anyone.
You do not just need to copy information from the logs of automated testing tools and similar sources into the report. So the program manual may decide that you did not have the time (or desire) to describe everything yourself.
Experimental Vulnerability Verification
In this part, you should try to write as if the recipient of the report and / or the curator of the program is a beginner in 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 an XSS vulnerability discovered:
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.
Please see the attached screenshot, which shows the XSS vulnerability that I discovered.
Sometimes (depending on the type of vulnerability found), it is recommended to send part of the page code so that the program owner can quickly find the place in which it appears:
In order for the program owner to better understand the degree of criticality of the vulnerability found, it is worthwhile to give a concrete 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 customers) may lose.
Tell us what tools and programs you used to identify the vulnerability. If you used only a browser, be sure to indicate its version. Some vulnerabilities can be reproduced only on certain software versions, so it is worth giving the most complete information here.
Example: Burp, Nmap, and Firefox 47.0
The attached screenshots (and in some situations even video files) will help to make the report clearer and increase its value.
Sometimes the owners cannot reproduce the vulnerability you found, so a 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 show the owners of the program that you really made an effort in preparing the report, that is, it will give you an advantage in evaluating it.
Suggested Vulnerability Fixes
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 step. Sometimes the developers themselves do not know how to fix the vulnerability, so a detailed description of your vision may well help. And this is beneficial for both parties, because the main thing is to deal with vulnerabilities.
Comments is a great tool that will come in handy when / if the program owner needs some clarification on the information in the report.
In the process of communication, you should always remain polite. You do not need to be constantly interested in whether there is 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 have not been answered for a long time, you can always contact the platform support service and ask to understand the situation.
Our main goal is to show the owner of the program that pentesters and security experts primarily want to help. We are all on the same side and we 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 relationships with program owners.
Together with the author, we hope that after reading this article your reports will become better, and the premiums for identified vulnerabilities will increase!
If you want to start working with bug bounty programs or take tasks more complicated, you need to have reliable knowledge of web application pentesting. Self-picking other people's sites can turn into sad consequences. Ethical hacking is a delicate matter that requires careful training and compliance with security policies. To learn how to look for vulnerabilities, write reports on them, and confidently use the entire arsenal of an ethical hacker, take a look at our Professional Pentester course . The second qualifying course starts in April.