Security Vulnerability Detection Analysis Research
The Android system’s market share among various mobile smart device operating systems is increasing, leading to a geometric increase in user demand for applications on the Android platform. To improve the quality and efficiency of Android application development, many developers will perform secondary or multiple developments based on software development tools (Software Development Kit, SDK) provided for free by software companies or commercial companies. These SDKs encapsulate complex logical structures, request-response processes, and functional modules in various professional fields, significantly shortening development time, ensuring program functionality reliability, and improving development efficiency.
In Android applications, external SDKs have prominent advantages. First, they can ensure that the program obtains high-quality resources provided by the platform; second, they can execute complex, secure, and efficient online functions. In cases of insufficient developers, these SDKs significantly shorten the development cycle of software vendors’ applications while ensuring the security and stability of software functionality. Some SDK platforms may even have advertising revenue, which is very attractive to program developers. However, some SDKs are outdated, slow to update, or even contain other purposes, posing a potential threat to user data security and privacy protection without developers’ knowledge.
The reliability of external SDKs directly affects the secure use of Android applications. However, the comprehensive vulnerability detection and security analysis of SDK platforms with existing technology require a lot of time and effort. Currently, developers can only use the latest version of SDKs for development, but this still cannot change the fact that many applications based on older versions of SDKs continue to operate. Additionally, the functions, logic, architecture, and differences among many SDKs are vast, making it unrealistic to expect a single tool to analyze all SDKs. Some external SDKs, driven by their own platform interests, store critical code in .so files, further complicating reverse engineering and analysis detection.
From the perspective of numerous mainstream Android application functionalities, an increasing number of SDKs integrate embedded clients from software companies, such as user comments, authorized logins, one-click forwarding, and other functions; when the program development process calls these SDK platforms, it actually sends request information data to remote servers to obtain services. Therefore, it is essential to understand the operational rules and motivations of such SDKs before conducting vulnerability detection.
External SDKs with network communication capabilities can be classified into two categories: one type establishes a local server on the terminal device after the Android application is installed, collecting device hardware and software information such as software lists, IMEI codes, and GPS data for the SDK platform provider. The remote server will send request information and obtain data from the local device, including controlling the application’s operational status on the local device. This type of SDK’s communication channel may be susceptible to hijacking, allowing malicious attacks to illegally obtain local server data and cause privacy leaks. The operational rules of this type of SDK are shown in Figure 1.
The other type of SDK’s application program only receives messages pushed from remote servers. An increasing number of mainstream applications have incorporated SSL/TLS security authentication functions into transmission protocols, forming a new HTTPS protocol; as long as the correct configuration is added, data loss and information hijacking can be prevented. However, ordinary HTTP protocol pushed information is not specially encrypted, and direct transmission can lead to information miscollection or incomplete reception, posing significant security risks. The reality is that Android applications developed using HTTP protocol SDKs are still actively used.
During the development process of some Android applications, there is an excessive emphasis on program functionality, treating SDKs as black boxes while ignoring internal security vulnerabilities. If the SDK has technical vulnerabilities or backdoors, all applications calling this SDK will be exposed to security threats, and illegal attacks can obtain the core code of the application through vulnerabilities or backdoors, gaining insight into the overall operation details and injecting malicious code, resulting in significant losses.
When analyzing the manifest file of device applications, it is found that when a user’s Android device starts and calls an application using a certain SDK, it triggers the behavior of obtaining permissions for the related application and autonomously establishes a local HTTP server without the user’s knowledge. The built-in HTTP server continuously scans and detects TCP ports, receiving and parsing data from remote servers and local devices to obtain location, user identity, and other privacy data. Illegal HTTP requests can replace the built-in actions of the local server and execute malicious code, resulting in user information being hijacked. Attackers may even privately add contacts to the user’s device, scan device files, collect, and upload specific data, and all these operations can be easily completed by sending illegal HTTP requests.
To gain advertising revenue, some application programs are developed based on SDKs released by certain advertising companies. Analyzing the relevant documentation of this SDK reveals that it uses HTTP protocol to communicate with remote servers; if attackers use proxy servers to detect and analyze the data transmission and response of the HTTP channel, they can easily obtain the user’s Android device IMEI, advertising information, image pushes, etc., and can modify the information content into malicious threat virus websites. When users click on the pushed information, they access preset virus URLs, causing user information leakage and greater losses through information hijacking and replacement. Some phishing websites use this method to induce users to click on advertising links to enter target URLs for deception.
SDK Selection and Analysis
This SDK analysis research process mainly includes three steps:
Dynamic taint analysis (as shown in Figure 5) focuses on network connections and function calls involving privacy information (such as obtaining geographic location information, reading contacts, verification codes, etc.), which will help avoid false positives and negatives caused by the program’s operational mechanism during subsequent dynamic analysis stages, thus inferring potential security risks of the analyzed SDK.
Due to the privacy of the server-side source code of the SDK developer, only static analysis and dynamic binary instrumentation (using Frida to inject code) can be combined to conduct black-box testing, reading and modifying parameters collected from the server side to verify the SDK’s security. The specific execution process is shown in Figure 6.
Experimental Results
This study systematically analyzed external SDKs with network communication capabilities, first summarizing them into two basic types: SDKs that establish local servers in the application segment and SDKs without local servers; then conducting static analysis on 35 collected external SDKs, extracting relevant information such as components, permissions, and network connections from SDK description documents and source code, detecting possible vulnerabilities, and verifying through dynamic testing.
After analysis, the security issues found in external SDKs were categorized into four types: local server vulnerabilities, open HTTP protocol, sensitive permissions, and improper SSL/TLS configurations. Table 1 describes the specific types and quantities of security vulnerabilities present in various types of collected SDKs, providing a basis for developers and service providers to analyze external SDK security risks.
External SDKs that establish local servers can collect device information and execute system commands to gain control over the device. If the local server has vulnerabilities in access control, attackers can retrieve sensitive data or even control the device in the background through access. Additionally, attackers may use sediment commands to send instructions to the user’s device, download programs in the background, and collect specific program files. All these malicious operations can be completed by sending HTTP requests. Although many new versions of SDKs have removed these vulnerabilities, many devices still operate old versions of programs because users have not updated in a timely manner.
It is well known that establishing network connections using the HTTP protocol poses significant security risks. However, many SDKs still use this channel to communicate with servers, and some SDKs transmit user privacy data such as IMEI information through HTTP in plain text or encrypted form.
HTTPS is an HTTP protocol with an added SSL layer, which must be appropriately and correctly configured to ensure the security of the communication channel and upgrade network connection safety. During application runtime, the hostname and server must be verified for matching to determine the validity of the hostname, and the validity of the certificate chain must also be checked. If the hostname matches the server’s domain name, it is considered valid; if none of the certificates in the certificate chain have expired or been revoked, and the root certificate was initiated by a CA in the client’s keystore, and these certificates are all signed by CA in the chain, then the certificate link can be deemed valid.
The X509TmstManager interface is the certificate information manager of the Android system, which performs security socket checks. Malicious attackers can rewrite the certificate verification process through this interface and clear the verification method routine, allowing illegal verifications to pass. When the SDK performs certificate verification, if it detects expiration, revocation, or illegality, it may not raise any abnormal alerts even if the application discovers illegal certificates. Such threats are prevalent in some unknown SDKs.
From the perspective of application developers, it is easy to understand that most Android programs request more permissions than necessary for operation as a backup. When the program calls the SDK, data, components, and permission information are added to the manifest file, and permissions not essential for operation are used to obtain user device information and personal privacy. For example, some information push SDKs request permissions for taking photos, video recording, and SMS reading. After analyzing similar advertising and information push SDKs, it is found that these permissions are entirely unnecessary for core functionality. Some SDKs share permissions from the host application’s manifest file; if the manifest file declares it, it can use these permissions, determining whether the host has obtained a certain permission by calling the host code in the SDK (as shown in Figure 8), while there is no description of requesting these permissions in the documentation of applications developed based on this SDK, leading to unnecessary security threats due to excessive permission requests.
Summary and Recommendations
To reduce risks associated with the use of external SDKs, the following summaries are proposed:
