mailing list archives
Google Play In-Billing Library Hacked
From: Dominik Schürmann <dominik () dominikschuermann de>
Date: Tue, 29 Oct 2013 15:28:28 +0100
HTML Version with Screenshots:
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
All Google Play Billing Library v3 versions before Oct, 8 distributed
via Android SDK and marketbilling on Googlecode.
- 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 (“”).
Browse the diff
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
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
“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.
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!
Description: OpenPGP digital signature
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia - http://secunia.com/
- Google Play In-Billing Library Hacked Dominik Schürmann (Oct 29)