How Far Should You Let Penetration Testers Go?

How far should you let penetration testers go once they have a finding or foothold on a penetration test of your organization?

As far as they can!

The goal is to help improve your organization’s security posture. The more opportunities for improvement that can be identified during a penetration test, the better.

Choosing a trusted independent third-party penetration testing firm is important because a consultant's experience can go a long way to minimize potential impacts to an organization. If there happens to be an incident impacting operation during testing, firms typically will have errors and omissions and/or cybersecurity insurance coverages that can protect your organization.

It does not really make business sense to allow bug bounty program participants to have unrestricted exploitation permission, however. While some programs allow for background checks and such, most do not have any idea on the skillset or experience of participants. By explicitly not allowing anything more than a bare minimum Proof-of-Concept for a program, it may dissuade seasoned testers from participating.

While there are cases where it may not make sense to allow unlimited exploitation, such as a bug bounty program, we will examine two (2) web application example cases illustrating potential benefits.

1. SQL Injection (SQLi)
2. Weak Credentials

In the first case, let’s suppose an application has an unauthenticated instance of SQL injection identified. If a simple error message of “Unclosed quotation mark near” is identified and the tester must stop, there are only two (2) findings: SQLi and the verbose error messages. If the tester continues and is able to retrieve data from the backend MS SQL database, other issues could be potentially uncovered.

Next, suppose a table named “Users” is identified with plaintext passwords or with MD5 password hashes and enumerated through error messages. Furthermore, the tester may find that other databases or data could be retrieved relating to other applications. Aside from data access, the SQL login is assigned the “sysadmin” role, allowing it to utilize the xp_cmdshell extended stored procedure, a method to execute operating system commands on the SQL server itself. That is done in the security context of the “SQL Server” service, which is determined to be running as “Local System”, which is typically not necessary. In this case, the opportunities for improvement identified were:

• SQL Injection
• Verbose Error Messages
• Plaintext Passwords/Weak Hashing Algorithm in Use
• Authorization Failure (Cross-application data access via SQL login)
• Excessive Permissions
  • SQL Login (Allowed OS Command Execution via xp_cmdshell)
  • SQL Server Service (Allowed for Underlying Operating System Full Compromise)
• Enhance Monitoring and Detection

Rather than a simple SQLi Proof-of-Concept with an error-based screenshot showing the issues, there were five (5) other issues uncovered.

Now for the second case, suppose an ASP.NET web application has credentials guessed of test:test and post-login has file upload functionality on it. The uploaded file extension is being checked against a denylist; however, it is easily bypassed by using “.asPx” instead of “.aspx” since the developer made the mistake of not considering case sensitivity. Once an aspx webshell is uploaded and its location identified within the web root, operating systems commands are then executed in the context of the web application. The application pool that the ASP.NET web application was running as had excessive permissions on the underlying operating system. A Web.config file was read and sensitive information, such as a database connection string, was viewable. A reverse shell was established to another system listening on the public Internet for persistence. In this case, the following opportunities for improvement were identified:

• Weak Credentials
• Unrestricted File Upload
• Deny List File Extension Bypass
• Excessive Permission (ASP.NET Application Pool)
• Sensitive Information Unencrypted in Web.config File
• Egress Filtering (Reverse Shell)
• Enhance Monitoring and Detection

Six (6) additional items were identified in addition to the original weak credentials. There could be many more opportunities uncovered in these scenarios as well. The presence of many of these technical vulnerabilities suggest other issues exist as a root causes. For example, the principle of least privilege and defense in depth were likely not taken into consideration during the design phase of the example applications or may also suggest an ineffective application security program.

For your next penetration test, consider the potential benefits of allowing your penetration testers to continue beyond the bare minimum proof of concept to maximize the value that you receive.