introduction

The rapid development and widespread application of mobile applications have made third-party SDKs an important part of mobile development. With its rich functions and convenient integration methods, third-party SDKs provide developers with a way to quickly develop and enhance application functions. However, due to the black-box nature and widespread use of third-party SDKs, their security has attracted much attention. This article will focus on the security issues of third-party SDKs in mobile APPs, and demonstrate potential security risks and attack methods through actual vulnerability mining cases.

Third-party SDK security status:

Third-party SDKs widely used in mobile apps have some security risks. First, third-party SDKs are integrated into applications in the form of jar packages or so libraries and exist as black boxes, so developers cannot audit their security. Secondly, due to its widespread use, once a vulnerability exists in the SDK, it will affect many applications. In addition, integrating the SDK may increase the attack surface of the application, thereby increasing the security risk of the application.

Umeng SDK override vulnerability:

The Umeng SDK unauthorized access vulnerability was discovered in September 2017. This vulnerability exists in Umeng's message push SDK. An attacker can use this vulnerability to call unexported components without permission, thereby achieving malicious calls to any component of the affected APP, notification of arbitrary false messages, remote code execution and other attacks. Approximately more than 30,000 APPs are affected by this vulnerability, and more than 7,000 APP products are affected by this vulnerability, involving various types of applications.

 

Baidu SDK backdoor exposed

The Baidu Moplus SDK backdoor vulnerability discovered by Trend Micro in November 2015. This vulnerability exists in Baidu Moplus SDK. An attacker can use this vulnerability to silently install applications on rooted Android devices, thereby stealing sensitive user information or controlling the device. The vulnerability affects approximately 100 million Android devices and involves thousands of Android apps.

Risks involved in financial supply chains are severe

Among them, the security risks of third-party SDKs in the Android application supply chain are particularly serious in financial apps.

Vulnerability mining and analysis

basic concept

 Application sandbox

Linux-based permission control mechanism: After the application is installed, UID and GID are assigned, and UID is used to restrict access to files. In theory, applications cannot access private files of other applications. GID is used to restrict access to resources. After the application applies for permissions, other The UID is added to the user group corresponding to the permission. The mapping relationship between permissions and GID is:/data/etc/platform.xml. The required permissions are applied for during installation/runtime, and are controlled by the system/user, etc.

 INTENT

Common IPC forms in Android: It is an IPC message object, used for communication between APP components, same process/cross process

, startActivity()/startService()/bindService()/sendBroadcast(), use Action or ComponentName to specify the target component, and can carry additional data (Extras)

Component security

The basic components of Android APP: Activity, Broadcast Receiver, Content Provider, and Service. For example: declared in the xml file: the component can be declared as external export/application private, and can be protected using permissions

Component export security

Export components: Exported components can be accessed by any application, android:exported=true, registerReceiver(), with The label component will be exported by default if android:export=false is not set. Example:

<receiver android:name=”com.xxx.android.pushservice.PushServiceReceiver” android:process=”:xxservice_v1″>

<intent-filter>

<action android:name=”android.intent.action.BOOT_COMPLETED” />

<action android:name=”android.net.conn.CONNECTIVITY_CHANGE” />

<!– … –>

</intent-filter>

</receiver>

Private components: Private components often contain application-sensitive functions, and have less verification of input data, unauthorized access to other application private components (application sandbox escape), and serious security risks.

Exploit methods

By exploiting vulnerabilities in the SDK, malicious applications do not even require any permissions, bypass sandbox restrictions, access private components of applications, push malicious notification messages, induce access to phishing websites, obtain SMS verification codes, access user private data, execute arbitrary code, etc.

This article provides several actual vulnerability mining cases to demonstrate possible security risks and attack methods of third-party SDKs.

PushSDK vulnerability mining

Pushing SDK is one of the common functions in mobile applications, but there are some security holes in it. By mining vulnerabilities in the push SDK, attackers can bypass application sandbox restrictions, access private components of the application, push malicious notification messages, induce users to visit phishing websites, etc. Specific cases include a vulnerability in the push SDK-A integrated into a city's official subway APP. An attacker successfully pops up a phishing notification by constructing a malicious push message and an exported Receiver.

PUSH SDK

Push SDK – A

• The official documentation guides developers to add an exported Receiver
• The specific functions of the exported Receiver are implemented by developers.
• "Guide" developers to leave attack entrances

<receiver android:name=”您自己定义的Receiver” android:enabled=”true”>

<intent-filter>

<action android:name=”cn.xxxxx.android.intent.REGISTRATION” />

<action android:name=”cn.xxxxx.android.intent.MESSAGE_RECEIVED” />

<action android:name=”cn.xxxxx.android.intent.NOTIFICATION_RECEIVED” />

<action android:name=”cn.xxxxx.android.intent.NOTIFICATION_OPENED” />

<action android:name=”cn.xxxxx.android.intent.CONNECTION” />

<category android:name=”您应用的包名” />

</intent-filter>

</receiver>

In this case, it is a city’s official subway APP integrated push SDK

• ExportReceiverxxxxxCustomerReceiver
• Parse the Intent incoming data in xxxxxCustomerReceiver and open the specified url in the app
• POC

The city’s official subway APP accesses malicious phishing pages

Push SDK – B

• Guide users to add exported Receivers
• The exported Receiver inherits from com.xxx.android.xxxxx.xxxBaseReceiver

<receiver android:name=”com.xxxx.xxdemo.receiver.MessageReceiver”

android:exported=”true” >

<intent-filter>

<action android:name=”com.xxxxx.android.xxxxx.action.PUSH_MESSAGE” />

<action android:name=”com.xxxxx.android.xxxxx.action.FEEDBACK” />

</intent-filter>

</receiver>

Push SDK – B

xxxxx.android.xxxxx. The push message is processed in xxxBaseReceiver. The delivered message is encrypted by RSA and decrypted locally by the App. After the decryption is successful, it is displayed to the user. However..., there is an encryption method in the SDK, and the attacker can call this encryption method. , to encrypt forged messages.

XX Credit Card Manager integrates push SDK-B and adds an exported Receiver. The attacker calls the encryption method in the SDK to construct a malicious push message and uses the exported Receiver to pop up a phishing notification. POC:

Sphere of influence

Sharing categorySDK vulnerabilitydig

Sharing SDKs are often used to implement social sharing functions in mobile applications. However, some sharing SDKs have security vulnerabilities. For example, if there is an exported Activity in a certain sharing SDK-A, an attacker can bypass the application sandbox restrictions and gain unauthorized access to any private Activity. By constructing a malicious input string, an attacker can trigger a general denial of service vulnerability, causing the application to crash. In addition, some sharing SDKs may also cause application password locks to be bypassed, thereby accessing users' private data.

Share SDK – A

There is an exported Activity in the SDK, XxShareXxXxxxxActivity, which takes the input string as the component name and directly starts the specified component without verification. Malicious applications can bypass application sandbox restrictions and gain unauthorized access to any private Activity.

XxShareXxXxxxxActivity receives the incoming string from the Intent. Without verification, the incoming string is saved as ActivityName, and call startActivity in the current application context to start the Activity specified by ActivityName, etc.

Vulnerability Exploitation – General Denial of Service: When the Activity starts, it needs to pass parameters/perform some initialization operations/…, exploit the SDK vulnerability to force the unexported Activity to be called, and improper exception handling, triggering the application to crash.

Write test tools and conduct batch testing on a large number of applications. Among the applications that integrate the SDK, 90%+ has this problem. According to statistics, among the applications that integrate the SDK, 90%+ has this problem. A large number of well-known domestic manufacturers' applications are affected by this vulnerability. .

Vulnerability Exploitation – Application Password Lock Bypass: User private data is saved in the application. When entering the application, you need to enter the correct password. It is common in financial and IM applications. Using this SDK vulnerability, unauthorized access includes resetting passwords, setting passwords, etc. Sensitive functional components and high-privilege components in applications are not strictly authenticated, resulting in password locks being bypassed/reset, etc. Tests have found that many well-known manufacturers’ apps have this problem, such as...

Vulnerability Exploitation - Turning on debugging mode without permission: In order to facilitate locating bugs online, many application release versions contain debugging code, applying log switches, customizing online server addresses, exporting user data and other sensitive functions... The debugging function is generally not available on the UI. Intuitive entrance that ordinary users cannot easily access. For example, the debugging module involves sensitive operations and is essentially like a backdoor. The SDK vulnerability is exploited to traverse all unexported components of the application and discover hidden debugging functions. For example, in an enterprise-level IM application, it was found There are multiple unexported components containing debugging functions. Reverse analysis determined that there is a hidden entrance on the UI to enter debugging. However, to start the debugging component through the UI, you need to enter a password: , and the authentication is not strict. This SDK vulnerability is exploited to bypass password protection. , enable the debugging function without permission.

Ordinary user identity login: exploiting SDK vulnerabilities to open administrator rights functions, the server is not strict about user identity verification, some administrator functions can be called without authority, etc.

Sphere of influence

Summary and thoughts:

The security issues of third-party SDKs in mobile APPs need to be taken seriously and resolved. Developers should audit the integrated third-party SDK to ensure its security and reliability. At the same time, developers are recommended to take the following measures to improve the security of third-party SDKs in mobile apps:

1. Choose a trustworthy third-party SDK supplier: Before selecting and integrating a third-party SDK, developers should fully investigate and evaluate the supplier and choose those suppliers with a good reputation and security record.

2. Regularly update and upgrade SDK versions: Third-party SDK vendors usually release updates and fix versions to address known security vulnerabilities. Developers should promptly update and upgrade the integrated SDK to ensure application security.

3. Conduct security audits and vulnerability mining: Developers can detect potential security vulnerabilities in third-party SDKs through security audits and vulnerability mining. This allows early detection and repair of these vulnerabilities, improving application security.

4. Limit SDK permissions and access scope: When integrating third-party SDKs, developers should review their permissions and grant only necessary permissions. Additionally, limit the SDK's access to private components of your app to reduce potential security risks.

5. Strengthen the protection of users’ sensitive data: When using third-party SDKs, developers should pay attention to protecting users’ sensitive data. Encryption, authentication and other measures can be taken to ensure the security of user data.

Finally, the security issue of third-party SDKs in mobile APPs is an important issue. Developers and security researchers should pay close attention to and strengthen security auditing and vulnerability mining of third-party SDKs. Only through joint efforts can the overall security of mobile APPs be improved and users’ privacy andData Security.