This article is compiled from the sixth issue of OPPO Technology Open Day - "Application and Data Security Protection" event, with the sharing guest being Xiang Bo.

The main content is as follows:

Current Situation of Third-party SDK Security

Third-party SDK security case

Security detection methods for third-party SDKs

Practice of third-party SDK security assurance in SDL

1. Current Situation of Third-party SDK Security

It is widely known that a key focus in the field of application and data security protection is the security issues of third-party SDKs. As a fundamental security issue, SDKs are widely used in APPs, which leads to the fact that security issues of third-party SDKs may have a more profound impact.

Third-party SDKs are widely used in daily life now, encapsulating very rich functions. They are very convenient for developers to use directly. At the same time, they also contain various types of information collected, which bring many challenges to security analysis. At the 2020 315 Consumer Rights Protection Day Conference, a certain SDK was exposed for collecting personal privacy information.

The characteristics of third-party SDKs can be simply summarized into four points:

Share APP permissions.The forms of SDKs include jar, aar, and so on, which encapsulate rich functions, and also have the characteristic that they can share APP permissions.

Black box cannot be detected.Developers may be more concerned about whether the SDK is convenient to use, but whether the SDK collects users' privacy information, whether there are security vulnerabilities, and whether there is malicious behavior, developers do not know.

Many attack surfaces.Introducing an SDK is equivalent to introducing more attack surfaces, and in our actual testing, we have found that security issues in third-party SDKs are often more than those in APPs themselves or self-developed SDKs.

Wide impact. The installation volume of commonly used SDKs may be counted in billions or even tens of billions. If a security issue occurs, it may affect hundreds of millions or even billions of users or terminals.

In actual testing, it can be found that the common threats brought by third-party SDKs are roughly divided into eight aspects:

First: Private or symmetric key hard-coded;

Second: Violating regulations to collect users' personal privacy information;

Third: Transmission of sensitive data in plain text;

Fourth: Unsecure certificate verification;

Fifth: Unstandard use of WebView;

Sixth: Bypassing sandbox restrictions to access application private components;

Seventh: Downloading and installing malicious usage;

Eighth: Permission abuse.

Components can generally be divided intoExported componentsAndPrivate components.

Exported components can be accessed by any application, while private components can only be accessed by their own applications, and private components often contain some sensitive operations, such as changing passwords, modifying accounts, setting passwords, and accessing sensitive data, etc.

At the same time, developers generally think that private components are not exposed to the outside, so they are sufficiently secure, and therefore do not perform strong validation on external user inputs.

If there is a vulnerability, it may pose a serious threat.

Malicious applications themselves cannot directly access some private components in the APP, but they can do so through a bridge, by using some exposed components in the SDK. These exposed components can directly access private components, thus achieving the principle of bypassing.

Second,Third-party SDK security case

Next, let's look at an example, which consists of three parts: the first is the exported component;

The second is to receive external data, and then save it as ActivityName without any validation;

The third is to start ActivityName in the current application, which achieves the result of bypassing the sandbox.

The solution is to ensure that components not requiring export are turned off, and external inputs are strictly validated.

The SDK also has common ZIP directory traversal vulnerabilities.

The paths in this ZIP compressed package contain strings such as https://www.freebuf.com/articles/, and attackers can use multiple https://www.freebuf.com/articles/ to jump to other places.

Imagine if jumping to another place, and the file has the same name as the file to be loaded by the user, it can directly overwrite the latter.

If the replacement is an executable program, the executable program after replacement, when loaded, can cause denial of service at best and code execution vulnerabilities at worst, which can seriously harm the security of the user's device.

When considering the solution,The most important thing to pay attention to is that when obtaining the absolute path of ZipEntry, you need to ensure that there is no https://www.freebuf.com/articles/ inside.Check whether it is a normal access directory at the same time, and if it is, you can execute it; otherwise, you need to throw an exception.

Summarize these two vulnerabilities.

If there is access to a private path and path traversal, then for the attacker, the operations they can perform are limited only to their imagination.

Compared to the first vulnerability, the construction method of this vulnerability may be slightly more complex. First, this is an exported component that sets the external data to v0_1, creates a Message through JsonObject, and this Message is also not checked.

Attackers can overwrite some executable files during the plugin loading process, achieving the result of malicious code injection and code execution.

Let's look at another type.

This type is also a significant vulnerability; this method is to create an http server Socket in the local APP, which runs when the APP starts, binds to any address, and then listens to the network port.

In addition, powerful commands can be executed, such as uploading and downloading files, adding contacts, and even determining whether the phone is rooted. If it is rooted, more programs can be silently installed.

One of the risk points of using Socket is weak verification. Our recommendation for the fix isProhibit binding to addresses such as 0.0.0.0 via SocketChange to binding to 127.0.0.1, and filter and verify the incoming data.

Another common risk with a significant impact is the dynamic loading of plugins.

Most of the time, SDKs use this method for self-upgrades, and from the cases we can see, although the package name and class name information is checked during the loading process, there is no check on where the executable program to be loaded comes from. Attackers can construct executable programs by forging the same class name and method name, leading to execution by the classloader.

It is recommended that everyone check the signature information of the APP.

Some third-party SDK developers may also adopt some methods to bypass the detection of conventional security tools to obtain user privacy.

The hard-coded string on the left side of the figure is a sensitive operation method getLocation used to obtain the user's address information and is Base64 encoded. It is decoded into the getLocation method using Base64 on the right, and then called using reflection, thus achieving the purpose of bypassing the detection of conventional security detection tools.

Three,Security detection methods for third-party SDKs

So, how should third-party SDKs ensure security?

Firstly,Components should not be exported as much as possible, and if it is necessary to export, the protection level must be set properly, and external data传入 must be verified and the identity of the caller confirmed.In terms of communication, it is necessary to prevent man-in-the-middle attacks and encrypt the transmitted content.

In addition,Ensure the minimum data permissions, to prevent path traversal. The loaded content must be trustworthy, and it canUse encryption and verification methods.

The security check of third-party SDKs is very important.

Our detection content includes three aspects:First, privacy compliance detection,Second, vulnerability detection, third, malicious behavior detection.

Combining practical work, starting from these three dimensions, the goal of ensuring the security of user-side applications as much as possible can be achieved.

In terms of detection, static taint analysis methods can be used.

Taint analysis is divided into three stages.

Firstly, mark the source point (i.e., sensitive information), then track it, using specific rules to track and analyze the taint information, and finally detect and record the access path.

Let's take an example.

For sandbox bypass, it is first necessary to determine whether an intent has been passed. If another component is opened without validation, this poses a security risk.

For the third-party SDK detection process, there are many aspects to pay attention to, includingThe checklist for security detection, reflection call detection, blacklist library construction, and security detection reportetc.

Four,Practice of third-party SDK security assurance in SDL

So, how is the security detection of third-party SDKs integrated into the SDL process?

First, let's give a brief introduction.SDL.

SDL (Security Development Lifecycle) stands for 'Security Development Lifecycle'.,It mainly refers to a development process that helps developers build more secure software and meet security compliance requirements while reducing development costs.

In principle, it is required to solve security issues as much as possible from the source, and avoid common security errors in development from happening again.

SDL can be simply divided into three major blocks.The first block is security training.The second block is the process of marking before the SDK goes online (the green part in the figure above), and finally the emergency response..

Let's mainly take a look at the point process in the second part.

Demand assessment aspectAt the design stage, it is not only necessary to consider the implementation of functions, but also to pay attention to whether the security is compliant and whether it violates the security red line.

WhileProduct design phaseAttack surface analysis and threat modeling should be carried out.

ToImplementation phaseStatic security scanning can be executed, and insecure implementations can be abandoned. And dynamic scanning and fuzz testing of the APP integrated with the SDK can be performed during the verification.

So when the final version is safely launched, you can see the security score of the APP, if it is below the required level, it cannot be launched, and at the same time, the event response plan must be handled properly.

For mobile terminal security personnel, the difficulties in SDK detection mainly focus on two aspects, one isSDKs are large in quantity and frequently updated, increasing the difficulty of detection work. Additionally,How to calculate the input-output ratio.

The three-party SDK security assurance process can be closed looped from four aspects.

The first isSecurity reviewAt the design stage or during the SDK introduction stage, evaluate the security capabilities of the introduced SDK and perform threat modeling directly.

The second isQuickly scan the blacklist libraryIf it is within the blacklist, there is no need to proceed with the next process.

The third isSecurity scanning.

Finally, for important SDKs, it is recommended to adopt manual expert analysis.

There are several aspects that need to be paid attention to in the three-party SDK security quality assurance process.

The first is the security review aspect,Threat modeling should be carried out at the initial stage to reduce the security and privacy risks of the SDK.

The second is black list detection, at the same time,Ensure that the SDK accessed by the APP is always the latest version, and if there are existing vulnerabilities, ensure that the vulnerability patches are applied in a timely manner.

The third is the platformization and automation of security detection,The scanning results cover the entire scope, and help the business side discover and solve typical security vulnerabilities in advance., avoiding a large amount of repair and upgrade work from the business side before going online or final version review.

At the same time, the scanning results should be as detailed as possible, freeing up the security team members from redundant work, studying better technology, and bringing users more security experience.

The fourth is to suggest organizing expert in-depth analysis for key projects,At the same time, develop and reuse secure coding libraries, and use secure coding libraries to improve consistency, thus improving work efficiency.

Through the practice of the above three-party SDK security quality assurance process, the security of the SDK is better guaranteed with less investment, protecting the security of user terminals.