Leakage of App Signature Certificates, How Dangerous Is It?

Android apps (applications) are signed and distributed based on certificates that have been self-generated by their developers. These certificates are used to distinguish developers when apps are uploaded to markets such as the Google Play Store. They act as a valuable method for developers to prove that they developed the apps. Furthermore, they can also protect the apps themselves by only allowing updates to go through if the certificates match. 

 

The reason behind this policy is to let individual developers create and upload apps freely, which is why developers are allowed to manage their certificates independently instead of establishing a separate certificate authority. Although lowering the entry barrier for app development and distribution is an advantage that enables users to enjoy an expanded app experience, on the other hand, this can be used in a complex way creating issues such as leakage of signature certificates. 

 

This report will summarize the attack types and cases of official app signature certificate leakages and introduce AhnLab’s complex response system against such malicious behavior.

 

 

  

 

 

Types of Attacker Behavior After Acquisition of Leaked Certificate

First of all, the malicious behavior that attackers performed after acquiring leaked signature certificates can be divided into two main types.

 

1. Using Certificates to Evade Malware Detection 

This involves signing malware with a signed certificate of the app responsible for the official service. By doing so, they are able to avoid being detected as malware by security solution scans.

 

2. Sharing Official Service App Data of Certificates 

The ‘Content Provider’ in the Android system enables data sharing between applications. If the official app designates the Content Provider’s settings as ‘Share Signature,’ all apps signed by the same certificate can access the Content Provider. Thus, the attacker may acquire internal user data through the malicious app, essentially using it as an app attack technique.

 

  

Figure 1. When the Content Provider setting is set as ‘Share Signatures’

 

The malicious apps that have been attacking official service apps were yet to be found. However, a sample aiming to evade the scans of whitelist-based security solutions and perform malicious behaviors was found. 

 

Next, we will look into cases in Korea where attackers committed malicious behavior after acquiring leaked certificates.

 

Cases of Leaked Signature Usage to Commit Malicious Behavior

1. App with Malicious Features Uploaded to the Play Store

In 2019, there was a case in which an app called "Gwangju Bus" was updated on the Play Store, but an issue occurred as malicious features had been added to the app. For reference, Gwangju Bus was an app developed and maintained by a single individual. The app would show bus routes, estimated arrival times, etc. The app began its service in 2012 and the developer ceased developing and updating the app in 2018. However, they did so without revoking the app's signing certificate information. Later, an attacker got their hands on the certificate and code, along with the developer's ID and password which was used to upload to the Play Store. The attackers then included malware in the app before uploading. 

 

 Figure 2. Comparison between a normal sample and a sample with malware

 

The malware-ridden app was successfully updated, allowing it to steal the Google IDs and passwords of individual users. The attacker also inserted malware into the other apps created by the developer of Gwangju Bus and uploaded them to the Play Store. 

 

*Summary of malicious behavior: The malware adds the library file, ‘libAudio.3.0.so native’, and the library downloads an additional library file ‘libMovie.so’ to steal key information such as Google ID.

 

 

2. NHN Certificate Leakage

This case was discovered in August 2022 while financial apps that had been signed by an NHN certificate were collected. More specifically, the case involved the use of an NHN certificate as a means to evade the malware detection of security solutions rather than an attack against apps developed by NHN. In the case of some whitelist-based Android security solutions, if an app possesses signature information that is registered to the official market, then it can be processed as a normal app since security solutions only extract signature information that is relatively easy to verify. In these instances, the app's malicious behavior will not be scanned and could instead be processed as being "white." 

 

*Summary of malicious behavior: The malware is an existing phishing app related to banking, known as the kaishi. Kaishi is a "downloader" app that can modify sender and receiver phone numbers. It can also download and force-install this malicious sample.

 

 

3. Leakage of Certificates for Smartphone Manufacturer Firmware

On November 12, 2022, Google reported through the Google APVI Report that the leakage of a platform certificate was discovered. For reference, APVI is the acronym for "Android Partner Vulnerability Initiative," which was established with the goal of finding and responding to even the vulnerabilities of Google’s partner company equipment.

 

A platform certificate is an app signature certificate used to sign Android apps within the system image. The apps signed by this certificate can designate "sharedUserId" as "android.uid.system" to acquire system privilege. In other words, if a malicious app signed by the manufacturer’s certificate is installed on the same manufacturer’s mobile phone, then the app is granted the right to access user data as well as system privilege. In short, the app will be able to operate with the same privilege as the actual OS. 

 

The malicious app that was discovered was signed by the firmware certificate authenticated by Google. The fact that it can perform malicious behavior only on the manufacturer's smartphone distinguishes it as another unique attack type.

 

*Summary of malicious behavior: Upon the execution of the malicious app, it acquires system privilege to collect the personal information and phone call logs of users and automatically record their phone calls before sending them to the attacker.

 

 

4. Attacker Deliberately Attempting to Generate "White" Certificate

This case was discovered on December 7, 2021, from a sample analysis of apps registered to the Play Store. This app was registered as an app related to Bitcoin. Its characteristic was that it only had a simple package name and signature information without a dex file or other executable codes. The app was confirmed to not be installable without a dex file inside the app.

 

  

Figure 3. App structure

 

The app was uploaded legitimately after passing Google’s evaluation, and received regular updates where only the version code was changed until February 16, 2022. The signature information used during updates was utilized to sign the kaishi malware from December 5, 2022.

 

As mentioned before, the attacker uploading to the Play Store seems to be a deliberate attempt to evade the whitelist-based security solution scans. It is suspected that after regular updates were provided through the Play Store long enough to gain user trust, the app was used to obtain the signature for malware.

 

AhnLab Response Status

Fundamentally, AhnLab operates a system that uses both the "whitelist" based on permissions and the "blacklist" based on blocks. To be more specific, the system manages apps that are clearly normal with its whitelist, while it collects and supervises the characteristics of malicious samples with its blacklist. If the system detects malicious behavior in white samples due to its blacklist, an analyst immediately conducts a detailed analysis to take appropriate measures. 

 

AhnLab has responded to the above cases based on this system, and the details are as follows.

 

#1. App with Malicious Features Uploaded to the Play Store: 

This case was managed as a white sample that had originally been uploaded successfully on the Play Store. However, the libAudio.3.0.so file was detected as a "downloader" and the sample was classified as malicious after an analyst examined it and determined that its certificate had been leaked. 

 

#2. NHN Certificate Leakage: 

This sample was identified as a typical kaishi malware as soon as it was collected. Its information was then immediately shared with NHN while also being classified as a sample with malicious features. We are still collecting apps that have been signed with this signature information for additional analysis and malicious behavior classification.

 

#3. Leakage of Certificate for Smartphone Manufacturer Firmware: 

LG no longer manufactures mobile phones, but the apps that have been signed by their certificate are still in use. Therefore, the apps that "possess malicious features" are categorized as being malicious. The latest devices from companies such as Samsung, Lenovo, and MediaTek have been confirmed to be unaffected because they had already revoked the certificate in the past, and the app was classified as malicious.

 

Conclusion

Due to its OS and market nature, Android developers enjoy a very high level of freedom in developing and uploading apps. However, that does not mean the weight of app management should be taken lightly. No institutional involvement during authentication and management means that developers are solely responsible for the maintenance and security management of their apps.

 

The following improvements are required to handle this matter. 

 

#1. Raising Awareness of Certificate Management and System: 

The reliability of the app developers possess and manage should be proportionate to the trust established between them and their users. As mentioned before, the absence of a separate authentication institution means that individual developers must take precautions in their app management. We cannot emphasize enough how much a higher management standard is required for app signature certificates compared to the ones with separate authentication institutes. Furthermore, measures to perform this systematically must also be prepared. 

 

#2. Preparing a Security Solution Improvement System: 

If security solutions trust the signatures of individual and company developers easily, then they will have limitations when it comes to responding to existing risks. Users of security solutions must acknowledge this fact and utilize a complex method of classifying harmful samples based on their features to prevent malicious behavior.