Hello, loyal readers of Saello Write Up!
Today, I’m sharing a finding that demonstrates a bypass of the credit limit on a specific mobile application, App Z. This bug allowed me to repeatedly gain 20 credits, despite the system’s intended policy.
Summary
App Z offers a subscription service that grants users valuable credits for features like receiving SMS messages or purchasing phone numbers. Like many service providers, App Z likely has a mechanism to ensure fair credit distribution and prevent abuse. However, my investigation revealed a significant flaw in how these credits are provisioned and managed after subscription changes, allowing users to effectively bypass the intended credit limits.
Steps to Reproduce
Here are the precise steps that led to the successful bypass of the credit limit in App Z:
- Start by downloading “App Z” from the Google Play Store and install it on your device.
- Open App Z and complete the account registration process.
- Navigate to the subscription section within App Z and purchase the “Account Subscription” (or similar tier) that grants you 20 credits for services like receiving SMS and buying phone numbers. Confirm that your 20 credits are added in-app.
- Immediately after purchasing and receiving your credits, head to your Google Play Store subscription management page and cancel your newly acquired App Z subscription.
- Without opening App Z, attempt to subscribe to the App Z “Account Subscription” again directly from the Google Play Store subscription management interface. (These subscriptions often remain active until the end of the billing period you’ve paid for, such as a 1-month subscrition).
- Now, open App Z. You will observe that your account has been credited with another 20 credits, despite having cancelled and re-subscribed.
- By repeating steps 4, 5, and 6, an unauthorized user can continue to accumulate 20 credits per cycle, effectively gaining an unlimited supply of App Z credits without making continuous payments.
Impact of the Vulnerability
The ability to repeatedly gain credits in App Z, while not a direct data breach, can have several significant impacts:
- Financial Loss for the Company: Each time a user exploits this bypass, they’re consuming resources (SMS reception, phone numbers) that the company typically monetizes, leading to direct financial losses.
- Service Degradation: A large number of users exploiting this could lead to an excessive demand on App Z’s services, potentially degrading performance or exhausting resources for legitimate, paying users.
- Policy Violation & Fairness Issues: The system isn’t functioning as intended, creating an unfair environment where some users pay for services while others obtain them for free through this loophole. This undermines the value proposition for paying customers.
- Reputation Damage: If widely known, this vulnerability could severely damage App Z’s reputation, leading to a loss of trust among its user base and discouraging new subscriptions.
- Potential for Abuse: While this PoC focuses on credits, similar subscription management flaws could potentially be exploited for more severe issues if the application handles other sensitive entitlements or features.
Recommendations
To address this credit bypass, the following steps are crucial for App Z:
- Robust Server-Side Entitlement Management: Implement strict server-side checks for subscription states and credit provisioning. Credit grants should be tied directly to active, valid, and newly initiated subscriptions, not just re-subscriptions after cancellation.
- One-Time Credit Provisioning per Unique Purchase: Ensure that the 20 credits are only granted once per unique, paid subscription event. Subsequent re-subscriptions, especially immediately after cancellation, should be carefully validated.
- Comprehensive Transaction Validation: Before provisioning credits, the backend system should thoroughly validate the subscription status with the Google Play Store API, checking for cancellations and refunds, and ensuring it’s a net new, active purchase.
- Strict State Management: Properly manage the state of user entitlements on the backend. A user who cancels and re-subscribes should be treated as a new subscription, but only if the previous cancellation and its associated credit usage have been fully reconciled.
Conclusion
Findings like this serve as a stark reminder that even seemingly straightforward features like subscription management require robust security validation. When not properly enforced, these mechanisms can lead to significant resource abuse and fundamentally undermine a service’s intended functionality and business model.
Stay vigilant and happy hunting!
Regards, Saello
