I have been checking and verifying vulnerability reports on CTF365 for more than a year, and the number of reports I had to reject because of the poor writing and structure is way too large, so here is a quick article on how to write a proper vulnerability report.
Why do you need to learn how to write reports?
Well, this should be obvious, but discovering a vulnerability and keeping it for yourself is kind of a useless thing to do, unless you want to use that vulnerability in malicious ways which is an entire different story. However, in ethical hacking and penetration testing fields, you are required to write reports and to write them well. You can’t communicate your assessment results orally or in half a page of badly written text, it will affect your work quality and might cause some issues with your clients.
In the context of CTF365, we can’t really give you points based on your claim that you found a vulnerability on one of the hosts, we need to make sure you found that vulnerability and verify its existence, and that’s why we need well written vulnerability reports. Writing those reports helps you in many ways, including –but not limited to –:
- You develop a deep understanding of the vulnerability since you need to explain to us in your report.
- You learn a valuable skill for your future career in the information security field.
- You get points in case your report was approved.
What do we expect from You?
A very important step in writing great reports is knowing your audience, and what they are expecting to read in your reports, so here is what we expect from you:
- We expect you to show us that you did the work needed to find this vulnerability, we aren’t impressed by automated scanners and neither should you.
- We expect an easy to follow PoC steps that our team can use to reproduce the vulnerability.
- We are expecting a technical report, please don’t add any non-technical sections that might fit into normal reports (executive summary, conclusions, …).
- We aren’t paying you a bounty, so we don’t expect you to give us an assessment on how critical the vulnerability you are reporting is.
Now that we agreed on the general expectations, let’s talk about what a proper report structure looks like.
Vulnerability Report Structure
You report must include all the following:
Title: What vulnerability are you reporting? Yes, we know that you pick its type from a list when you submit the report, but please give us a clearer title, something along the lines of “Stored XSS vulnerability in display parameter at admin.php”.
Description: A short, clear explanation of what is this vulnerability about? A perfect description will be customized to the specific vulnerability you are reporting and to how it works inside the application itself. However, we do accept public exploits, OWASP descriptions or CVE entries as valid descriptions for your vulnerability.
Reproduction Steps: This is the most important part of your reports. In simple, clear, and organized way explain to us how this vulnerability can be reproduced. The clearer your steps are, the faster we can verify your report so please spend some time writing this part.
- If the vulnerability you are reporting is web related, please mention the URL and parameters.
Attachments: Show us the results of your work, did you pop an alert box for your XSS? Share a picture of it with us. Do you have some HTTP requests/responses saved to a file? Attach it to your report. Have any other files that can help us verify your report, please attach them to the report.
Please follow this structure in your future reports starting from today.
An Example of Good Vulnerability Report
Title: SQL Injection in view parameter at admin.php on 10.194.0.5
Description: Application X suffer from unauthenticated sql injection flaw due to insufficient sanitization of "view" parameter.
A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system. SQL injection attacks are a type of injection attack, in which SQL commands are injected into data-plane input to affect the execution of predefined SQL commands.
- Browser to the URL (mention the url).
- Insert a SQL injection payload in the infected parameter to verify it is vulnerable to SQL injection.
- Use SQLmap to exploit the vulnerability (mention all commands used).
- Mention any other attack steps you took, and why you did them.
We have extracted usernames, passwords, and session information from the database, those were:
- Username: user
- Password: 123456
Attached are pictures of the exploitation progress, usernames and passwords list, and the sessions information from the database.
Examples of bad vulnerability reports
Want to know more about writing vulnerabilities reports from some of the best people in this field? Here are some articles and blog posts for your own reading and refence, check them, they are great:
- How to write a great vulnerability report (cobalt.io).
- How do I report a vulnerability? (Link).
- Report a Computer Security Vulnerability (Microsoft).
- The Art of Writing Penetration Test Reports (Link).