Almost all organizations today have some form of automated security testing apparatus. This may include static code analysis tools and may even include scanners that perform dynamic application testing.

Now just imagine a scenario where you have performed your scans, fixed the vulnerabilities from the scanner, and your latest scans show no more vulnerabilities. At this point, you should be relieved and ready to go-live with your application because no vulnerabilities were found, right?

Wrong. Relying solely on automated scanners and/or inexperienced penetration testers is akin to locking your front door whilst living in a glass house. Nothing inside would be confidential and is at risk even though the front door is locked.

This article shows real-world examples of the chilling reality of false security and showcases the important role that highly skilled professional penetration testers play in safeguarding your business from potentially catastrophic financial losses.

In the following case studies, we will explore the penetration testing techniques employed by our professional penetration testers who uncovered vulnerabilities that would have otherwise exposed the businesses to serious financial impact. We will also briefly discuss why automated scanners would fail to detect such vulnerabilities and why relying on automated scanners alone is insufficient and extremely dangerous.

Investment in a well-scoped professional penetration test alongside automated scans is the best solution to protect your business against financial catastrophe.

Note: All 3 case studies use mocked images to demonstrate the vulnerabilities and none of these are screenshots of the actual applications.

Case Study 1: Money Transfer from Any Account

In this case study, our penetration tester was testing a banking mobile application. It discovered that an attacker was able to transfer money from any account to its own account, as the mobile application failed to authenticate whether the transfer made was from the owner of the account.

The following screenshot shows the attacker, user “Horangi” with a balance of $140, attempting to make a $10 transfer to a user called “Benjamin."

The attacker then triggers a transfer but intercepts the request made to the server with a proxy tool such as Burp Suite.

By utilizing tools such as Burp Suite the attacker can modify the request before it is sent to the application server. The attacker can manipulate the request to include a new source account number (ending with “618) and new beneficiary account matching their own account (ending with “221”), as seen below.

Following the attacker sending the manipulated request to the application server, the attacker “Horangi” successfully receives $10 from an account called “Victim”, as seen below. This clearly demonstrates that as part of the request for transfer, no access checks were performed to validate the ownership of the source account, which, in this case, was not controlled by the attacker.

Pitfall #1: Automated Scanners Cannot Validate Users’ Permissions

Unlike professional penetration testers, automated scanners cannot detect access control flaws in an application. While testing applications, penetration testers take time to understand how the application is intended to work, and then attempt to abuse any false assumptions present during development. Imagine if the above vulnerability was not detected, an attacker would have the ability to randomly transfer funds from any account to their own account, which would cause potentially catastrophic financial and reputational damage to the bank in question.

Case Study 2: Stripe Payment Misconfiguration

In this case study, our penetration tester discovered an attacker could edit the payment amount sent to Stripe and complete the required transaction with a smaller payment. The financial impact of this is significant, just imagine an attacker having the ability to successfully check out any number of items whilst simply paying one dollar.

With a similar request interception technique used above, our penetration testers changed the payment amount from the original amount to just a dollar by simply changing the amount parameters. Below is a snippet of the changes made in the request body.

 

The following screenshot shows the actual amount payable for the gaming console before redirecting the user to stripe payment, as well as Stripe payment page where the attacker has successfully changed the amount to a dollar and the payment made was reflected as successful.

Pitfall #2: Automated Scanners Cannot Validate Application Logic Misconfigurations

Most automated scanners are unable detect cases where application logic that is present on the client is not enforced on the server, as they are simply unable to understand the expected logic flow of the application. In this case, a scanner would not have been able to detect that the cross-domain payment request to Stripe was being handled on the client, where the best practice would have been to simply process the payment on the server.

Case Study #3: Negative Price on Menu Items

In our last case study, our penetration testers discovered that the value of an item can be set to a negative value, even though the front-end graphical user interface was configured to restrict such actions, through bypassing the front-end GUI restriction.

Imagine if an attacker was able to add a high-valued items to their basket totaling ($255) and offset the cost by adding similar priced items with a similar negative-value (-$254) into the basket. This would result in a successful purchase but with a value ($1) which is significantly lower than the true value of the items in the basket. The following screenshot shows that an attacker has managed to perform exactly that.

Pitfall #3: Failure to understand and contextualise business requirements.

Experienced penetration testers understand how applications and their functionality should behave, which automated scanners and inexperienced penetration testers lack. An automated scan would not be able to detect such a vulnerability because it would have no way to know that the amount is not supposed to be a negative value. Similarly, an inexperienced penetration tester may not think to test for such an edge case scenario, as the application’s GUI does restrict against negative prices.

Bottom Line

The above case studies show that even though automated security testing is a good practice and cost effective, it is not perfect. The human ingenuity and expertise from experienced and professional penetration testers’ meticulous approach can uncover vulnerabilities and detect what automated security testing would not, allowing businesses to avoid potential losses and harm to their reputation.

It is important to remember that prevention is far more economical than the cure, and investment in regular professional penetration testing is an important step towards keeping your business resilient against hackers and cybercriminals.