Case study: Payment processing API penetration testing

Penetration test: complete compromise of the transaction processing API, which allowed to initiate unsolicited payments on behalf of other registered customers.

Introduction

Our penetration testing team was tasked with an external penetration test for an undisclosed payment processing company. The test included both black box testing without a predefined scope or any additional information about the company and simulating a malicious registered customer. 

We were able to achieve a complete compromise of the transaction processing API, which allowed us to initiate unsolicited payments on behalf of other registered customers.

PAYMENT PROCESSING API PENETRATION TESTING

Black box penetration testing phase

The first phase of the test started with OSINT (Open source intelligence) and active reconnaissance and resulted in the discovery of an external-facing staging environment for a currently unused merchant portal. It was open to registration and the team created a couple of accounts and projects for testing. After manual evaluation of the application, it was possible to retrieve the GraphQL schema used for request processing. The schema was examined, and a vulnerability in the request authorization mechanism was discovered that allowed us to retrieve metadata and other information about all projects and transactions in the underlying database, which was, as it was later confirmed, the production DB of the currently used portal. The vulnerability itself was incorrect validation of filter objects that were used to display partial results of API requests. The back-end application correctly validated ownership of the requested objects but failed to correctly process filter expressions with string comparisons, which allowed to retrieve all objects with UUIDs either alphabetically preceding or succeeding ones the team had access to. 

The natural next step was discovering possibilities for object modification or API authorization retrieval, but object CRUD API on the staging environment was deemed to properly control object modification requests.

Grey box penetration testing

After the team was provided registered merchant access to the production application, the first attack that was tried was invalidation and generation of API keys to access other projects via an IDOR vulnerability, which was successful. The application security model did not focus on IDOR vulnerabilities, as it was assumed that UUIDs of other application objects were not accessible to the attacker. By using information retrieved during the black box testing stage, we were able to completely take over any project in the system and initiate payments with tokenized cards.

Conclusion

This case study demonstrates the necessity of the black box stage and initial reconnaissance. Often enough, the scope is predetermined by the Customer, which eliminates the possibility of discovering an external asset that can be used by an attacker to compromise critical applications or infrastructure. We at Tenendo always allocate additional time to conduct in-depth information gathering and can help our Customers to correctly scope external engagements, optimizing security, costs, and project time. If you are interested in Web Penetration Testing in general, please refer to Application penetration testing.

Related services:

Adversary simulation

Adversary simulation

Adversary simulation can provide a different insight into a security infrastructure. While penetration tests are used to test potential vulnerabilities with no regard to stealth, evasion, lateral movement and the Blue Team’s ability to detect…

Read More
Social engineering assessments

Social engineering assessments

Social engineering is an attack that requires human interaction, persuading employees of the target company to act, such as opening a malicious document or providing authentication credentials. While the social engineering delivery method is usually…

Read More
Case study: Internal adversary simulation

Case study: Internal adversary simulation

The adversary simulation activity allowed the security team to demonstrate a complete compromise path while not using any usual, “exploitable” vulnerabilities. Instead, the attackers relied on human factor, weak password policies and password reuse, service…

Read More

Need more information?

Post navigation