Tech tales: Achieving PCI compliance with application security testing

In our new tech tales series, we discuss how Synopsys customers use our products and services to uncover security risks in their organization.

Synopsys customers span every industry—from small to large enterprises across financial services, automotive, public sector, medical and healthcare, and much more. One thing they all have in common is building trust into their software. Synopsys offers integrated solutions that transform the way organizations build and deliver their software, accelerating innovation while addressing business risk.

In this tech tales story, we spoke with members from the Synopsys consulting team to understand how one financial services industry customer used Synopsys application security testing tools and services to address Payment Card Industry (PCI) compliance.

What was the security program/testing history for this customer (Are they new to security, do they have a mature program in place, which tests did they perform in the past/now, etc.)?

As compliance mandates, this financial services customer conducts tests yearly on any applications and networks that handle PCI data.

What made them reach out to us (security breach/close call, peer/industry pressure, immature program, new CISO/management, etc.)?

They wanted to scale their application security testing program and replace their current penetration testing vendor with a more experienced vendor. We did some proof of concept testing for them and demonstrated superior quality of testing and results vs. the incumbent vendor.

What was the task at hand?

We uncovered several potential issues after conducting an initial assessment:

• Unauthenticated Remote Code Execution (RCE). A hacker exploits a new vulnerability that enables remote code execution. This exploit typically occurs in a scenario where the hacker does not require prior authentication.
• SQL injection. The application executes SQL queries generated by dynamically concatenating user-supplied data to static SQL query strings. In this implementation, the database has no way of distinguishing between the developer’s intended SQL syntax and any SQL syntax coming from user-supplied input. As a result, any user-supplied data containing SQL syntax inserted into the static query will be interpreted and executed, leaving the application vulnerable to SQL injection since an attacker can inject SQL query syntax to intentionally alter the target query’s structure.
• Login page enumeration. The application’s login functionality returns different responses depending on whether the entered username is valid or not. The difference in responses may be as straightforward as “invalid password” vs. “user [username] does not exist,” but the responses can be even more subtle. The application may return a generic failed login message that differs slightly depending on whether a valid username and invalid password are supplied vs. an invalid username, or the application may display a single error message, but some other (potentially non-visible) aspect of the response’s content is different.

How did you find the issues?

The unauthenticated RCE issue was discovered because the unauthenticated arbitrary file upload attacks via ELFinder, a PHP-based file manager embedded in the TikiWiki instance.

The SQL injection issue was discovered using a proxy tool, which was able to detect a SQL error.

The login user enumeration issue was exploited by compiling a list of valid users through automated brute force guessing attempts. Once the list of valid usernames was compiled, password guessing was automated and resulted in a large list of valid credentials for the application.

What was the potential impact of the issues that were uncovered?

The unauthenticated RCE issue was discovered on the customer’s wiki page. The machine was running an older OS that facilitated easier privilege escalation, password dumping, etc., after the initial exploitation. The machine was also connected to an Active Directory (AD), providing it with easy lateral network connectivity to other systems in the AD.

SQL injection allows an attacker to modify the structure of a SQL query executed by the application. Depending on the type of SQL server in use, the attacker may be able to modify existing queries or append entirely new queries to the existing query. The modified query can access any portion of the database with the same entitlements that the database connection is granted, potentially leading to: 

• Loss of confidentiality when an attacker gains access to unauthorized information
• Loss of integrity through modification of other users’ information, log files, and any other sensitive information
• Loss of availability when an attacker deletes other users’ data, executes commands that take down the database server, or performs a denial-of-service attack that fills the database and subsequently exhausts the database server’s storage
• Authentication bypass through modification of SQL queries that verify a user’s credentials
• Authorization bypass from gaining access to or altering data in ways the application’s business logic does not allow

By automating guesses, an attacker is able to retrieve a large list of valid usernames for an application. Once the attacker has a list of valid usernames, they can begin guessing passwords in an attempt to steal credentials and impersonate other users. Password guessing attempts may be done manually or via automated means depending on what login anti-automation mechanisms (if any) the application has in place. Valid usernames may also be used in phishing exercises as well as large-scale account lockout denial-of-service attacks. In this particular case, many of the harvested accounts were found to have the same password as the login, making this instance of this issue even riskier than usual.

What was the remediation advice to the customer?

As soon as it is identified that the service version is vulnerable to an attack, preventative measures should be taken to mitigate the vulnerability until an upgrade or patch is released. To address the unauthenticated RCE, we recommended upgrading or patching the software service to a version that does not currently have any known vulnerabilities.

For the SQL injection issue, we recommended that the customer rewrite all SQL queries constructed through dynamic concatenation to use an injection-safe query mechanism such as prepared statements with parameterized queries. Most modern programming languages provide a feature called “parameterized queries” that allow user-supplied data to be inserted safely as values in dynamic SQL queries. Rather than construct the dynamic SQL query by concatenating user-supplied data to static SQL query string fragments, data values are identified in the query by parameter markers or variables. Dynamic data is then passed through a mechanism provided by SQL that prevents the supplied data from changing the meaning of the query.

For the username enumeration issue, the application should return the same response whether or not the supplied username is associated with a valid account. An example response for all combinations of invalid credentials could be, “The username and password entered do not match.”

What were the outcomes/results?

The customer is in the financial services industry, and the applications tested contain customer data, thereby qualifying the applications for PCI compliance. The PCI compliance mandate requires rigorous third-party testing, and we were able to test the applications to ensure compliance and meet the stringent requirements set by auditors.

What are we doing for them now/in the future?

As the customer acquires new companies, we test the applications that they inherit on demand with a short turnaround time—currently, we are testing around 200 applications a year for them. In addition to penetration testing these applications, we also perform mobile, network, and API testing for them.

Learn how to accelerate and scale application security testing with on-demand resources and expertise

Learn more