Deliverables In order to address the identified issues, we will submit a report to PETRONAS and a recommended mitigating action plan. Include descriptions of the types of reports used to summarize and provide detailed information on the risks, vulnerabilities and countermeasures required for information security and the recommended corrective actions. The plan will be included I. II. III. IV. V. VI. Introduction - The project summary about the task that had being done. Vulnerabilities - The list of proven or very plausible vulnerabilities on the project and the level of severity of it. Recommendations - The recommendations of activities that need to be done to enhance the security Detailed Findings - The list of detailed finding that we found on the project during the test is been done Test Period and Duration - The period and duration of the test been conducted. Conclusion Deliverable Example This is the penetration sample that we had done with other company. I. Introduction The purpose of this test is to determine security vulnerabilities in the server configuration and web applications running on the servers specified as part of the scope. The tests are carried out assuming the identity of the attacker or user with a malicious intent. At the same time due care is taken not to cause damage to the servers. Information security consulting firm has been assigned the task of carrying out. This penetration testing had been done on XXX Company. This is the testing report. It was performed during date DD.MM.YY. The approach that we had done during the tests are: Perform broad scans to identify potential areas of exposure and services that may act as entry points. Perform targeted scans and manual investigation to validate vulnerabilities. Test identified components to gain access to <IP Addresses>. Identify and validate vulnerabilities. Rank vulnerabilities based on threat level and loss potential. Perform research and development activities to support analysis. II. Enhance security by developing long term recommendations. Transfer knowledge Vulnerabilities Severity levels result from the combination of their impact with their probability of occurrence, which is quantified according to the following scale: Low (L) –yellow Medium (M) –orange High (H)–red. However, only proven or very plausible vulnerabilities are listed. When the tests were not able to highlight significant security holes, those will not be mentioned unless the test was explicitly part of the request. Ref. Title AP.1 Stored XSS Risk(s) User impersonation Severity level H AP.2 User impersonation L AP.3 AP.4 AP.5 AP.6 III. Target(s) Description XXX Malicious JavaScript code can be injected. It will be then executed on the victim’s browser. Reflected XXX Malicious JavaScript code can XSS be injected. It will be then executed on the victim’s browser. Vertical XXX An authenticated simple user privilege can have access to some admin escalation menus. Concurrent XXX Concurrent sessions are sessions allowed for a single user. allowed No XXX Authentication system can be account brute-forced. lockout policy No XXX As no password policy is password enforced when using the local policy database for storing user credentials, users can set weak passwords (e.g.: containing only one character). Facilitates L session usurpation Facilitates L session usurpation Facilitates user L impersonation Facilitates user L impersonation Recommendations Action Ref. Severity Target(s) 1 AP.1 H XXX & AP.2 Improvement Suggestions Difficulty If possible, use a white list at the application 3 level by defining the expected characters rather than refusing he dangerous ones. If that’s not a possibility, the application should filter metacharacters from user input. When performing IV. 2 3 AP.3 L AP.4 L XXX XXX 4 5 AP.5 L AP.6 L XXX XXX input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, and consistency across related fields, and conformance to business rules. Deny access to admin pages to non-admin users. Only allow one session per user at any given time. Enforce an account lockout policy. Implement a password policy or use LDAP or AD authentication and ensure your LDAP/AP enforces a password policy. 2 2 2 2 Detailed Findings In this section we would like to highlight findings of the critical issues found during testing. We also will provide the screenshot as a prove for any vulnerabilities happen. the AP.1 Stored XSS XXX Company is vulnerable to two HTML and JavaScript stored injections also known as Stored Cross-Site Scripting vulnerabilities. They could be used by authenticated users to elevate their privilege by hijacking an admin’s session for example. The vulnerabilities are located in the Observables functionality and in the Observable management. AP.2 Reflected XSS XXX Company are vulnerable to many HTML and JavaScript stored injections also known as Reflected Cross-Site Scripting vulnerabilities. They could be used by authenticated users to elevate their privileges by hijacking an admin’s session or by anonymous users to impersonate an authenticated user’s session for example. The vulnerabilities are located in the new analysis functionality for XXX and in the handling of error messages at XXX’s level. However, the latest is very unlikely as it needs Internet Explorer 11 with compatibility mode enabled. AP.3 Vertical privilege escalation An authenticated user with read-only access can use admin functionality and list users created in the database. AP.4 Concurrent sessions allowed Concurrent sessions are allowed. If an attacker finds a way to hijack a session, it could be unnoticed by the legitimate user. AP.5 No account lockout policy An attacker could brute-force the authentication system without being stopped or even slowed down. AP.6 No password policy No password policy is enforced in XXX Company website when using the local database for storing user credentials. Users can thus set weak passwords (e.g.: containing only one character) when changing their password. This could help an attacker find valid credentials. VII. Schedule The pentest was performed in 4 man-days spanning several weeks starting from DD.MM.YY. and ending on DD.MM.YY. VIII. Conclusion During the time allotted for this penetration testing we found critical and high risk vulnerabilities that put both XXX Company and the users of the XXX Company platform at risk. Cross-site request forgery vulnerabilities pose a high risk in this scenario as they may be used to force users to transfer part of their funds unwillingly and unknowingly. Other Medium and Low risk vulnerabilities were found, which should be addressed by XXX Company’s staff in order to tighten the security posture of their web application. After the reported issues are fixed we recommends performing further security exercises such as a Source Code Audit of the application to help finding other vulnerabilities that were not covered in this engagement.
