7 Terms Should be in Mind While Writing A Report
Description is the introduction part of the report. This can be considered as a short explanation of the report title, where the reporter gives general information of the vulnerable endpoint or component, followed by the type and causes of the vulnerability found.
Reproduction is the most important part of the report. Written in the attacker’s perspective, this includes detailed steps for the security team to follow. Attached images, proof-of-concept files or captured video links can be used to help explain some of the complicated steps. Make sure all required steps are included so the report can be checked and fixed in less time.
Attack vector or payload contains tools or commands used to perform the attack; this is usually included in the reproduction or can be a separate section. Reports like XSS or RCE must provide working input strings or commands as demonstrations, but they must be safe to execute. For example, a simple command showing an alert box is enough for an XSS report.
For a more complex vulnerability, the reporter may provide an exploitability section that tries to explain example cases and conditions for the attack to work. Most reports on privilege escalation or access control bypass need explanations and are more complex than reports on SSRF or SQL injection, as they depend on various endpoints and require users’ interaction.
The impact of the vulnerability reflects the severity of the report. By referring to the result of the attack, try to explain what the attacker can do, what information they can access and how this affects other users in the system. The higher the severity, the higher the awarded bounty.
The Recommendation section optionally provides possible solutions for the security team to resolve the vulnerability. It also shows the causes of the vulnerability, if not being discussed elsewhere in the report.
Reference is located in the bottom of the report, and it contains links to external sites related to the vulnerability. This section is optional, and is often included only if the report contains new or complex attack techniques.
General rules
Be polite! Yes there are humans behind computers and they are not your enemies. Be nice, say hi/hello, please, sorry, thank you, bye/best regards etc… Use the basic words as you would do in real life. At the end, they are supposed to give you some money, plus you can be totally wrong at any point, so this is the minimum you can do.
Use markdown formatting. Many platforms use Markdown as a text formatter. Use his easy syntax to make your report clear. — create paragraph and skip lines to break the text — use bold to highlight important things — use inline code for parameters names and values - use block code to take advantage of the language colorizer
Oops! If you notice afterward that you forgot to mention an important detail or if you finally discover that the bug is not a bug at all but an intentional behaviour, then feel free to add a comment to explain the situation. The team will thanks you million times for all extra infos you provide saving their precious time.
Don’t be “too much”. Being friendly doesn’t mean that they really are your friends, avoid things like “Sup mate!”. Remain professional!
Avoid multiple issues in a single report It’s confusing for you and the triager and could possibly leads to smaller rewards than separated reports. Unless you can chain several vulnerabilities of course (for example: OR + CSRF + XSS) and then submit a report with a bigger impact (and so increase the bounty).
Note that all information's are important, however the first things that triagers see are: date, title, status and criticity. Since you don’t have any control regarding the date and the status, title and criticity deserve your attention.
Rating
Take time to rate the issue, in an obvious way. Too low, there is a chance that the secteam pass over it, but you could be happy if finally the bounty is higher than your expectations. Too high, the secteam could think that you overrated in order to increase the bounty, they will notice, lower the rating, lower the bounty and you will be disappointed.
Sometimes optional, sometimes mandatory, if available, try to fill the CVSS score. Even if it’s not perfect and context dependent, it gives a good idea of the criticity of the issue in a technical point of view. Note that some platforms award bonus points for that.
Title
It has to be simple but clear, explain what about is the report in one single line. It should contain the type of the vulnerability, the potential impact and what asset is concerned. If the program is big enough and many assets are in scope, consider to add the name of the asset as a prefix, this will help the team to sort the reports.
Good:
Open redirect + Stored XSS in profile lead to account takeover on www.example.com
[192.168.1.1] Public Jenkins instance leads to RCE
So so:
XSS on www.example.com
PHP errors reveal webapp full path
Forget it:
XSS
local file inclusion
critical bug on www.example.com
Introduction
The introduction is basically a reminder of the title a little bit more verbose, but no technical details at all. You can also write a quick explanation of the class of the vulnerability. Yeah some vulnerabilities are not so famous, and sometimes triagers are not InfoSec people. Perhaps they don’t know about Appcache and never heard about that ImageTragick bug.
Description
In a nutshell, the full explanation of the vulnerability. Name the variables, their values, provide endpoints and all conditions required to trigger the issue: what, when, where, who etc… The whole everything.
Steps to reproduce
The goal here is to help the team to reproduce the bug in an easy way. Give them the whole process step by step using an ordered list so you could reference any step at any moment.
1/ Connect to your account: https://www.example.com/login
2/ Click on the “profile” tab
3/ Enter value payload in the input input
4/ repeat step 2
…
If you use a local proxy like Burp Suite, you can provide the request in a http block code. It’s very easy to reproduce the issue that way, you simply need to copy/paste it back to the software, update the cookie or any auth token and that’s it, simple and efficient.
GET /directory_traversal_1.php?page=/etc/issue HTTP/1.1
Host: bwapp.test.net
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Cookie: _ga=GA1.2.1344627302.1544974513; _gid=GA1.2.395150311.1544974513; PHPSESSID=cfpt3iskot4sfbjhjvf192je2f; security_level=0
Connection: closeProviding the response is also a good thing to show the team the difference between a legit result and an unexpected behavior.
PoC
As we often say, a picture speaks a thousand words. Provide everything that can prove the bug. One of my previous article about Colorize your hunt can help to visualize things. Also, keep in mind that the report can be publicly disclosed in the future, so take care of hiding personal information's you want to keep private.
Videos that replays the whole drama that leads you to this great report.
Screenshots that you can quickly modify with an image editor in order to highlight payloads and data's extracted. No need to be a great designer here.
Mitigation
Trying to stay obvious and honest, if you think that some technical details make the issue very hard to exploit then it’s important to let the team know about it. For instance a RCE that can only be triggered in January, between 12h and 2am at full moon night (don’t laugh this is how I was imagining bug bounty when I started :x).
Remediation
Do you have any idea on how to solve the problem ?
This is greatly appreciated by companies, they will be happy to read your tips/recommendations. Remember that bug bounty is also about learning (for both parts).
Impact
It’s the job of the hacker to prove the criticity of the vulnerabilities he finds. Try to create a possible scenario showing the potential risks of the issue. But take care to not fall to the “Hollywood syndrome”. there is only a few chance that a Full Path Disclosure leads to an earthquake followed by a tsunami, stamping out the human race. Seriously, it’s not gonna happen.
Additional notes
Sometimes you have to provide small details that can be helpful to the team to better understand the issue, why it works most of the time but fails in a specific case. Some weeks ago I reported a P1 to a program regarding their user permissions. The developper was not able to reproduce the issue. I simply added a tiny detail in my report about a minor change that occured some days before and they immediately understood the bug.
The faster they reproduce the issue, the faster your report will be triaged, the faster you will be payed :)
References
This is where I put links to external resources: owasp, blog articles, CVE, disclosed reports, real study case or whatsoever that can support my reports. The goal is to help the team to understand and fix the issue but also show her the criticity.
What’s next?
Do not harass. Do not ask for update every single day. You’re probably not the only hacker working on this program, they probably receive alot of reports. They have to prioritize the tasks. Acting like a kid does not only discredit yourself but the whole community.
Do not harass more! Do not spam the company over and over with the same report closed as informative or N/A in order to change their mind about it. They won’t unless you give important additional information's. If you really feel that something is going wrong with this report/program then consider to request an intervention from the platform itself.
Be patient :) I personally ping every 2 weeks when no news. One of my report has been fixed and rewarded 2500$ after 1 year… Patience is a virtue in bug bounty.
Conclusion
As I said in the intro, the report is just as important as the pentest itself. You better to spend time on it trying to show the real severity of your bugs in order to get bigger bounties. Remember that non accepted reports (oos, duplicate…) can be rewarded if you are able to improve the security of the company whatever the way (by telling them something they don’t know for example).
