Bad Certificate Management in Google Play Store

Following a recent study of apps in the Google Play Store, let’s discuss several security risks caused by the bad certificate management practiced in many Android apps, from social to mobile banking.

All Android apps must be digitally signed with a certificate from the developer. As described in Google’s official document, the app developer is required to create a keystore with a set of private keys, and then use the private key to generate a signed version of apps. This key has to be valid for at least 25 years. These certificates do not have to be generated by a certificate authority and can instead be self-signed. Because this is simpler and allows the author to retain the private key, the majority of Google store apps use self-signed certificates. This means it is the developer’s responsibility to keep the private key safe, whether that developer is a 13-year-old or a multi-national company. As this means the security protecting private keys varies widely, the security risks of bad certificate management cannot be ignored and must be identified, and where necessary, mitigated.

Security researchers are starting to take note and publish on this subject. For example, BlueBox recently revealed the Fake ID vulnerability, which exploits an app’s certificate verification process within the Android OS. If they haven’t already, soon attackers and malware authors will turn their attention to exploiting vulnerabilities surrounding Android app certificates.

When an app is published to the Google Play Store, the certificate information is included within the APK file. To view the certificate information just open the given APK file as a zip file. The certificate information is stored within the certificate’s  “/META-INF” folder. You can use keytool or openssl tools to view the certificate information. An example taken from the popular Angry Birds app is shown in Figure 1. The certificate fingerprints (circled in red) are what can be used to uniquely identify a certificate.

Figure 1

These digital certificates, self-signed or not, are the keys to updating apps in the Android ecosystem. It is a primary reason the expiration dates are set so far into the future and developers are able to self-sign certificates. The only way to update an app is for the developer to sign the update with the same digital certificate originally used to publish the app. If a developer wants to use a different certificate, they must publish the update separately as a new app.

Furthermore, all Android apps published using the same certificate have a trust relationship between them. Android allows apps signed by the same certificate to run in the same process and treats them as one single application instead of separate ones. It also allows multiple apps with the same certificate, if using signature-based permission checks, to expose functionality and exchange code and data amongst themselves. This is convenient for developers, which is great, but it is also convenient for hackers, which is not.

Security risks of bad app certificate management

Losing control of a certificate’s private key, or using an insecure private key, can have severe security consequences. For example, if an attacker obtained the private key of an app, he or she could create a fake APK file, sign it using the same certificate as the legitimate app, and replace the targeted app with fake app on the device silently using the “Application upgrade” procedure. In addition, if the attacker can’t create an app with the same name as the targeted app, he or she can still check the “SharedUserId” option. This allows apps with different package names but signed with the same certificate to share permissions and stored data.  Because of this, app developers should be extremely careful about re-using certificates when signing their apps.

Bad certificate management observed in the Google Play Store

Ideally, an app developer should generate a unique private key for each unique app they post in the Google Play Store.  Unfortunately, during our study of apps posted in the Google Play Store we collected approximately 246,000 Android apps but only 11,681 certificates. The distribution of the number of apps sharing the same key is shown below. The X-axis is the number of apps sharing the same certificate. The Y-axis is the number of certificates. For example, the number of certificates used by only one app is 1,323. About 6,925 certificates are used to sign between 6 and 19 different apps.

Figure 2

As we see in this distribution, a lot of developers sign different apps with the same certificate. We further investigated the following cases:

1. Signing apps with a publicly known private key

Many key pairs are well known in the development community. The most famous set of key pairs would be the key pairs included within the AOSP source files (in Table 1, below).  More key pairs can be found in developer forums and academic research.

Table 1

If one app is signed using the publicly known private keys, it is easy for other apps on the same device to replace this vulnerable app with another APK file, silently with no user knowledge or interaction.

We scanned our inventory of APK files downloaded from the Google Play Store and found at least 87 apps using the “testkey” in Table 1. According to the Google Play Store, these 87 apps have been downloaded more than 1.6 million times. For security reasons we are not posting the names of any of these apps. Under no circumstances should developers ever use private keys that are publicly available, nor should users download them. However, it isn’t easy for users to know the app they’re downloading is using a compromised private key – the onus for this is squarely on developers.

2. Mobile banking apps sharing one single key

Mobile banking apps are particularly sensitive with significant security concerns, which is why we were surprised to discover one certificate was used to sign more than 300 mobile banking apps in the Google Play Store. This practice is not necessarily dangerous, as long as the developer does not share the key with the various banks that contracted the applications.

We’ve contacted the developer to confirm they have retained sole custody of the keys. Of course, even with out-sourced application development, app owners should prefer to hold their own key. Whoever controls the key controls updates for the application forever, and a key shared between applications in this way can never be transferred to a financial institution without compromising the security of all of the other apps signed with it. The developer is aware of this concern and plans to encourage more of its customers to sign their own applications in the coming year. In addition to our research, the Baidu Security team in China recently found 23 mobile banking apps sharing the same certificate hosted by a third party app developer and reported the discovery to the CNCERT in China.

3. Third party app developers using the same key for all apps generated for all customers

The app developer industry is booming. These developers help customers build mobile apps for their businesses easily and quickly. They serve an important role for the majority of businesses that do not have in-house developers. Unfortunately, we uncovered some of these developers using the same certificate for every app. Again, using the same private key is probably due to the convenience in app management. But as we noted earlier, apps signed by the same certificate can automatically grant sharing relationships amongst themselves.  This means all of the apps created by these developers, regardless of intended use, could be used maliciously. Table 2 shows select top app developers using the same certificate in signing all their apps.  For security reasons, we have masked the names.

Table 2

Conclusion

Digital certificates are a critical component of the security of Android apps. Unfortunately, many app developers in the Google Play Store have ignored these concerns in favor of convenience. While in some cases that may be justified – the app may not contain any important or identifying information – in many of the cases we discovered it is not. This poses great potential security risks to both app users and app owners. We encourage developers to reconsider their stance on this issue and where necessary make changes before a significant security event happens.