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.
As compliance mandates, this financial services customer conducts tests yearly on any applications and networks that handle PCI data.
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.
We uncovered several potential issues after conducting an initial assessment:
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.
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:
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.
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.”
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.
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.
Chai is an engineer turned product marketer passionate about delivering value to customers. He has worked in the AppSec, cyber security, and data management industries for over 15 years.