312-50 EC Council CEH – Website Hacking – Discovering Vulnerabilities Automatically Part 2

4. Writing a Pentest Report

Throughout the course we learned a number of methods to discover bugs and vulnerabilities in different types of software and infrastructure. Usually at the end of the Pen test, you will need to inform the client with all of the vulnerabilities that you found or with all of the findings. This is done using a Pen test report. So basically what we mean by a Pen Test Report report, it’s just a document that includes everything that you found through your engagement so that the client or the admin can go ahead and fix all of the vulnerabilities and the weaknesses that you found. These reports are also read by executives a lot of the time, therefore you would need to account for that. So a good report should be easy enough, but it’s also easy to understand.

Now, if you’re working as a Pen tester, then the company that you’re working for will probably have their own template and their own standards that you have to follow when writing a report. And in many cases you won’t even be doing that. You’ll simply be forwarding your findings to another member in your own team and they will be filling the blanks properly in the report. Therefore, you probably will not need to write one from scratch and in many cases you won’t even write the actual report that the client sees. With that being said, I still want to show you how this is done just to give you an idea of what a Pen test report looks like. Now, first of all, before I show you the sample that I have, I’m going to include this repository which basically contains a large number of Pen test reports.

So you could actually look through these for inspiration and just to see the different styles that different companies follow when making a Pen test report. So you can click on any of these and you’ll find the report and you can actually go through it to learn how this specific company writes the reports. And maybe you find something that you like that you would start including in your own reports. So I’m going to include this in the resources of the lecture so you could come back to it for inspiration. But what I really want to do is walk you through a sampler report that we use here in the security, just to give you an idea of the main sections that most reports have. I will also include this in the resources, so feel free to modify it and use it or take some elements of it if you want to. So you’ll notice from the repository in here, each company has its own style of writing reports. But in general, there is always a few main sections that you will find in every report.

So starting with the first page right here, we have the covering page. So again, you can style this as you want. You usually have the company logo, you have the title and then you’ll have the date of the report and the version. This is very important. And then we have the company, our company information. So this report is written by us. This is our company information. And then you have in the four field, you have the company that you’re writing this report for. So you’d have the company name, you’ll have a specific ID for this company. This is the idea that you identify this company within your own records. Again, this is probably not something you’ll be doing yourself.

You’ll be given this ID by your own company. And then we have contact information for both companies. So you can see in this company we have Pentester One and Pentester Two with their email addresses. This could be obviously a bigger list with all of the team that is doing the Pen test and similar to the company that you’re doing the Pen test for, again, you have their names, their position in the company and their contact information. Now again, keep in mind you don’t always have to style the first page like this, but more or less usually in the first page you’ll have the title, the date, the version and the contact information. This is how we do it. But again, you can do it the way you want and you can draw inspiration from the resource that I’m going to include here. Next, we usually have the table of contents. Again, as you can see, simple stuff usually would have in any kind of document. This will help you navigate throughout this whole document. And like I said, in here we can see the main sections of any Pen test report. So it’s very important to have an executive summary. This is a summary of the whole engagement that is designed for less technical people.

So it’s supposed to give them an idea of your findings without diving too deep into technical details. Then we have an engagement summary where we detail the scope. So this is what you tested, which parts of their system that you tested, the risk ratings that you used and an overview of everything that you found. So again, so far we’re not diving deep, we’re simply this is just a summary of the whole engagement. You’ll get a better idea of all of this as I go through the report. And then in the technical details section, this is where you dive really deep in everything that you found. So we basically have a section for every finding.

So as you can see, this is just a sample site, only made three findings. We have an SQL injection, a cross site Request Forgery Sdsrf and an information disclosure. So as you can see in the first section, we basically just had a summary of everything that we found, whereas in the technical details we’re basically breaking down every single finding and we’re going to talk about how we found it in details, how to replicate it. You’re going to include screenshots if you can, so that the technical team can understand exactly the severity of this vulnerability and how to fix it. You’ll notice other companies will include appendix at the end they will include recommendations where they will tell you exactly how to fix vulnerabilities. Like I said, it really depends on the company. Every single company have their own style and every single company have their own format.

So what I’m showing you right here is just a sample of how we do it. You can draw inspiration from the resources and in many cases you’ll just have to follow the template that your company has because they don’t want you to do it your own way. So let’s go to the next page and you’ll see in this page we have the legal information. And that’s why I actually said you’ll probably not do this yourself. You’ll never need to do this yourself because you’ll have parts of the report like this you’ll never have to modify. And they’ll actually be written by the legal team in your company.

So they’ll account for anything that could go out of control to make sure that you will not be sued if anything goes wrong. It will contain stuff like disclaimers, GDPR, privacy, legal stuff and all of that stuff that we don’t really know very well as pen testers and legal people usually write. And then we have the change log of the document. So every time a change is made to the document, you can see we have the date, we have the version and we have a comment why did we do this change?

Or what’s so significant about this change? So this was the initial report when we made it on January 1 and then on the 10 January we made the second version where we are done with the recon stage. Again, this is just samples, but just to give you an idea that keeping a change log of all of the changes that this document goes through is very, very important. Not all of the companies do it, but again, that’s just our own choice to add it in our report. I keep saying this just to give you an idea that there is no set rules to making these kind of documents.

You can add or remove anything you want, but the main parts would be the legal part, the executive summary and then the technical part. These would be the main parts of the report. So now we have the executive summary and you could read through this. This is not supposed to be long, so in my opinion it needs to be a page maximum two pages if you really have to. And it basically just says we were instructed to test X system. It will explain how this document is organized, where the first section is less detailed, just to give you an idea of the risk. And then the second one is detailed for the technical people to understand these risks and fix them. And then we’re given the risk rating. So we’re assuming this is at high risk based on the vulnerabilities we found.

It will detail the methodology that we followed. And then we have some charts in here. Remember, this part is being read by the executives. These are people that are not very technical most of the time and they also don’t have a lot of time. So we’re including graphs in here to show them the amount of vulnerabilities we found. So we can see we have five vulnerabilities that are high, we have ten that are medium and eight that are low. So this will give them a really good understanding of the threats that they face. And then we’re going to go into the summary. Again, this will still be read by the less technical people. So, first of all, we’re detailing the scope to make sure that we tell them what we tested, even though they already told us what to test.

Just so that in case in the future, if something was discovered outside of our scope and they come back to us, we can say, well, this was outside of the scope. We did not test this. Next, we’re including the risk ratings. So you’ll have this in every document, you won’t need to modify it. We’re basically just saying how we would classify a certain vulnerability as low, medium, high or critical. And we’re saying in our opinion, how you should handle the low, medium, high and critical vulnerabilities you can see for the critical, we’re saying you need to fix immediately, whereas for the low you need to fix in the next update cycle. Again, this is just our own opinion. Next, we have the findings overview. So we’re still in section one. This is still for the executives, we don’t need to dive too deep.

So we’re just given the vulnerability ID. And you can see for the first vulnerability it’s critical, it’s an SQL injection. And in many cases, in many reports, they’ll actually stop at saying it’s just an SQL injection. We like to actually show the impact in this section because like I said, these guys are not technical. So if they read SQL injection, they might not know what an SQL injection is. What they care about is the impact of this vulnerability. Again, they don’t have a lot of time, so you need to be straight to the point. So what we’re doing is we’re saying it’s an SQL injection that could lead to unauthorized database access. So now they know with this vulnerability, a hacker can access their database. This is probably pretty bad. Another vulnerability that we found is medium and it’s a CSRF. Again, many reports will stop here, doesn’t really explain anything to non technical people.

So we’re saying clients can be forced to submit certain non critical requests. That’s why it’s a medium, not critical requests, but they can be forced to submit stuff and then we have one low vulnerability where the PHP version is disclosed. So this is not really very critical because it’s not an actual vulnerability that can be exploited to gain access or expose user data. But this information could be useful for hackers to chain with other attacks or discover vulnerabilities for this specific PHP version. And that’s why it’s a low, that’s why it doesn’t need to be taken care of very urgently like the critical ones, as we mentioned above in here, and feel free to read the text in here.

You’ll see a lot of it is basically just to clear our bags and make sure that they understand everything that is in the report and that would be the end of the summary. And now we’re into the technical details. So in this section we’re basically having, like I said, a subsection for every single finding that we have and we’re diving really deep into the details of this finding. So you can see this is the SQL injection that we mentioned earlier in the summary, but this time we’re actually giving them the URL that is vulnerable, we’re giving them the vulnerable parameter, we’re giving them references to understand what SQL injection is in case they don’t understand it. We’re giving them the exact request and the exact response that we got, which made us determine that this particular page is vulnerable to an SQL injection.

Then we’re giving them the impact here in details, not just saying that they can access the database, that we’re saying they can access the database, they can retrieve data, we got access to the user’s table. So you’re going to dive in details and you should even include screenshots in here if you think they’ll be useful. In the Mitigation section, we’re just giving them a quick recommendation. Like I said, some companies give detailed recommendations, this really depends on the engagement as well. So in this example we’re basically just saying use prepare statements with parameterized queries and we’re giving them a reference to learn how to do that or to understand how it works and that’s pretty much it. So you’re going to repeat that for every single vulnerability you found.

I’m leaving the rest empty as this is just a sample, but you get the idea. So you’re going to have a subsection for every finding that you have, explaining everything in details so they understand the vulnerability and then they can go ahead and fix it at the end. Many companies would have an appendix and they might have a bigger recommendation section. Like I said, this is our style of writing reports, but each company has their own style.

If you like this, maybe spend some time going through the sample reports that we have in this repository. Obviously I’ll include both links for my sample and for the other samples in the resources so you can go through them yourself and get an idea of what Pen test reports look like. But like I said, in many cases, you’ll simply be filling a sample similar to what we have in here, so you’ll never be asked to come up with one from score.

• Category: Uncategorized