Google Play Billing Bypass

2013.10.30
Risk: Medium
Local: No
Remote: Yes
CVE: N/A
CWE: N/A

HTML Version with Screenshots: http://sufficientlysecure.org/index.php/2013/10/29/google-play-billing-hacked/ I successfully exploited two bugs in Google Play Billing Library, which allows to impersonate the Google Play billing service and circumvent the signature verification. I was able to retrieve unlimited amounts of in-app items in games like Temple Run 2, which uses this library. This blog post was released earlier than previously negotiated with Google, because Google was unable to provide proper attribution (they even stated ?we recently discovered? in an email sent to Android developers). Additionally, they ignored questions regarding other bad security practices in this library. More information can be found before the conclusion. Vulnerable libraries -------------------- All Google Play Billing Library v3 versions before Oct, 8 distributed via Android SDK and marketbilling on Googlecode. Problem description - Any app can define a new intent-filter with a high priority to impersonate the official in-app billing service. See my AndroidManifest.xml how to do that. - Signature verification returns true if given INAPP_DATA_SIGNATURE is an empty String (??). Proposed fixes -------------- Browse the diff https://code.google.com/p/marketbilling/source/detail?r=7bc191a004483a1034b758e1df0bda062088d840 and merge the modifications into the appropriate parts of your code. Proof of concept - Clone https://github.com/dschuermann/billing-hack, compile the project, and install the APK on your device. - Then install Temple Run 2 or similar apps, and go to the in-app items and ?buy? some items. Remarks about the vulnerabilities --------------------------------- The impersonation vulnerability is quite interesting, because it shows that an Android principle regarding IPC with Intents was ignored. If an app, e.g., Google Play Services, register an Intent filter providing an AIDL remote service, any other app can also do that using the same name. To prevent collisions, the simplest fix is to restrict the scope of of the Intent used for binding to that service from client side by setting bindIntent.setPackage(?com.android.vending?). The other bug is a typical crypto implementation fail, but there is also a take-home message here. The verify method checks if the signature String is empty before going on to the actual verification. Unfortunately the method returns true per default at the bottom of the method. In my opinion verification methods should be always programmed with this in mind: always return false, return true only on success! Remarks about Responsible Disclosure Process After reporting the vulnerability and some emails back and forth, I got an email to my Google Play developer email account, informing me about the following: ?If you previously used the In-app billing sample code to build your in-app billing system, please use the recently-updated sample code as it addresses an exploitable flaw we recently discovered (note that this only affects the helper sample code; the core system and in-app billing service itself was not affected).? I think it?s unfair that they were unable to provide attribution, especially as I explicitly asked about mentioning me as a security researcher in prior communication with them. Additionally Google payed no bug bounty, although this library is quite important as many app developers rely on it for in-app billing. Advertisement ------------- If you are a programmer, consider working with us on OpenPGP Keychain to provide secure emailing for Android. I will help on pull requests and be happy about every commit!

References:

http://sufficientlysecure.org/index.php/2013/10/29/google-play-billing-hacked/


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top