Breaking and Fixing Third-Party Payment Service for Mobile Apps

Abstract

Riding on the widespread user adoption of mobile payment, a growing number of mobile apps have integrated the service from third-party payment service providers or so-called Cashiers. Despite its prevalence and critical nature, no existing standard can guide the secure deployment of mobile payment. Thus, the protocol designs and implementations from different Cashiers are diverse. Given the complicated multi-party interactions in mobile payment, either the Cashiers or the apps may not fully consider various threat models, which enlarges the attack surface and causes the exploits with severe consequences, ranging from financial loss to privacy violations. In this paper, we perform an in-depth security analysis of real-world third-party payment services for mobile apps. Specifically, we examine the mobile payment systems from five top-tier Cashiers that serve over one billion users globally. Leveraging insecure protocol designs and practical implementation flaws, e.g., vulnerable backend SDKs for mobile apps, we have discovered six types of exploits. These exploits enable the attacker to violate user privacy and shop for free in the victim apps, affecting millions of users. Finally, we propose the fixings to defend against these exploits. We have shared our findings with the affected Cashiers and got their positive responses.

Appendices

A More Details on Order Replacement

Figure 7 shows a snippet of the log during the verification process within Cashier2’s Android app, which consists of two steps:

• 1. getAppInfo: the CA extracts the app identifier, i.e., retailer, from the received payment order and requests for the related app information from its backend server.

• 2. verifyAppInfo: the CA compares the package name and signature of the MA against the received app information.

Notably, getAppInfo will only occur for once because the CA will locally store the mapping between retailer and the related app information. Nevertheless, we find that the CA in Cashier2 suffers a software bug in getAppInfo. Consequently, this bug will enable the repackaged MA to bypass the checking from the Cashier in the first payment attempt, even if it does not have a benign signature.

Remark: This exploit can be persistent once the repackaged MA injects the order from a new Merchant, with an unknown retailer , in each payment. We have done the Proof-of-Concept (PoC) experiment, reported the issue to Cashier2 , and got its confirmation.

Fig. 7.

Running log from Cashier2’s app

B More Details on Cross-merchant Notification Forgery

Figure 8 details the Cross-Merchant Notification Forgery mentioned in Sect. 5.3, which works as follows.

Fig. 8.

Cross-merchant notification forgery

1–4:

The attacker purchases products in the victim Merchant, namely, MA, until Step 4. Then, the attacker suspends the payment session and identifies necessary information, namely order$\_$num, trade$\_$amount, and backURL, from the payment order.

5.:

Using the payment credentials from another app, i.e., MS’, the attacker forges a payment request with the same order$\_$num and trade$\_$amount. Besides, the backURL is set to the host controlled by the attacker.

6.:

After paying for the forged order in MS’, the attacker receives the signed payment notifications from the Cashier, which contain the app identifier of the MS’, order$\_$num, and trade$\_$amount.

7.:

The attacker refunds the order to get the money back.

8.:

The attacker resumes the payment session in the MA and injects the forged synchronous notification (from Step 6) into the CA. Meanwhile, he sends the asynchronous one to the MS according to the backURL in Step 4.

9.:

The CA propagates the forged notification to the MA.

10.:

The MA sends the forged notification back to the MS and queries the payment status of the related order.

Finally, the victim Merchant verifies the digital signatures in the forged notifications and extracts the order$\_$num and trade$\_$amount. Then, it compares their values with the local record (generated before Step 3) and passes the checking due to the setting in Step 5. Nonetheless, the MS overlooks the app identifier, i.e., retailer, inside the received payment notifications, trusts the settlement of order payment, and delivers the products to the attacker.