Structure of Documentation and Reporting

Looking back at the beginning of our journey as a penetration tester, let’s remember that our client asked us to find vulnerabilities in their IT systems. The results from our penetration test should thus be noted down in a final report. This report constitutes the document that our client will be holding in his or her hands. And this is why we need to pay special heed to the reporting aspect.

If we have identified a vulnerability, the client’s management will have to make a decision on how to deal with the presented risk. In the best case scenario, the hole will be patched by software developers or IT administrators. This means that our report must be geared towards persons with a lot of IT knowledge as well as those with little IT knowledge. This is generally accomplished by splitting the document into a management overview and a technical report. Furthermore, the report should include the framework conditions of the performed penetration test, as well as a list of the target systems and the period during which pentesting was carried out, because a pentest only constitutes a snapshot of the state of security. The report could be structured as follows:

• Cover sheet
• Table of contents
• Change history
• Contact person
• Project overview (scope, classification, time period)
• Management overview
• Technical report
• Appendix (methodology, risk assessment...)

The cover sheet basically states the most important information about the document. In our case, this should at a minimum include the pentest identification (e.g. Penetration Test Report - Dubius Payment Ltd. IT Infrastructure), the name of the author, date of creation and the version of the report. The version of a pentest report is important, as it is highly likely that the report will be revised at a later time. We must also highlight the successfully resolved risks in the report at the latest when we conduct a review of the identified vulnerabilities. This is also why the above structure includes a change history.

The most important part of a pentest report is the management overview and the technical report. Both list all identified vulnerabilities, but they are distinguished by the author’s intent. The management overview should highlight the risk of the vulnerabilities, whilst the detailed description of a vulnerability should comprise the following aspects in the technical report:

• Description of the vulnerability
• Description of the effects
• Proof of concept
• Recommendation

It is recommended that you list the vulnerabilities according to risk from high to low in descending order. Naturally, critical security gaps should always be listed before notes. The target group must of course also be considered when writing the report. The management report is usually read by an IT manager and the technical report by IT administrators or software developers. So when writing the management overview, we can assume that the reader has basic IT knowledge, whilst saving technical terms for the technical report. Let’s take the following scenario as an example: we were able to extract content from the database in the appointments calendar of Dubius Payment Ltd. by using a GET parameter. This could be formulated as follows in the report:

Management overview

Database queries can be injected due to the lack of input validation.

• Risk: Immediate action required (medium probability of occurrence, high damage)
• Fixed: no
• System: manager.dubius-payment.com

Technical report

Heading: Time-Based Blind SQL Injection

Description of the vulnerability: The failure to verify user inputs enables exploitation of an SQL injection. An attempt is made to inject database commands via the parameters. If no error is displayed with invalid SQL syntax, this is a blind SQL injection. Time-based attacks identify SQL injections using delay functions or procedures.

Description of the effects: Using the period_time GET parameter, the MySQL Sleep function can be executed when edit appointments in the appointment calendar (http://manager.dubius-payment.com/edit_period.php?period_id =1). A time delay can be observed with the attack string period_id=1 AND SLEEP(5), for example. Using time delays, database contents can be extracted as shown below. With this procedure, all characters of a database entry are iterated through individually. As soon as it is the correct letter’s turn, a time delay is triggered.

Proof of concept:

 +---------+----------+---------------------------------------------------+ 
 | user_id | fname    | lname   | level         | username  | passcode    | 
 +---------+----------+---------------------------------------------------+ 
 | 5       | Jaiden   | Pitts   | User          | jpitts    | v4orPzn9 [..]

Recommendation: Prepared statements should be used to prevent SQL injections.

Pentest reports naturally contain sensitivity data and should thus be treated confidentially. For this reason, the handover of the report should also be agreed with the client. This may take place via an encrypted email via GPG or S/MIME.

Now that you have practically cleared the last hurdle by completing the report, we want to give you a leg up on the final stretch: You may send your final pentest report for Dubius Payment Ltd. GPG-encrypted via e-mail to training@binsec-academy.com to get our feedback. The corresponding public key is stored on a publicly accessible key server for this purpose.

Philip Baker is a student trainee at Dubius Payment Ltd. and is very interested in IT security. Currently, he is performing vulnerability scans of networks pursuant to the PCI DSS requirements. By the next PCI DSS certification, he will also be responsible for carrying out the penetration test, and he has already created a report template. Can you find it in the lab? ;)