Vulnerability Detection on Android Apps–Inspired by Case Study on Vulnerability Related With Web Functions

Nowadays, people’s lifestyle is more and more dependent on mobile applications (Apps), such as shopping, financial management and surfing the internet. However, developers mainly focus on the implementation of Apps and the improvement of user experience while ignoring security issues. In this paper, we perform the comprehensive study on vulnerabilities caused by misuse of APIs and form a methodology for this type of vulnerability analysis. We investigate the security of three types of Android Apps including finance, shopping and browser which are closely related to human life. And we analyze four vulnerabilities including Improper certificate validation(CWE-295:ICV), WebView bypass certificate validation vulnerability(CVE-2014-5531:WBCVV), WebView remote code execution vulnerability(CVE-2014-1939:WRCEV) and Alibaba Cloud OSS credential disclosure vulnerability(CNVD-2017-09774:ACOCDV). In order to verify the effectiveness of our analysis method in large-scale Apps on the Internet, we propose a novel scalable tool - VulArcher, which is based on heuristic method and used to discover if the above vulnerabilities exist in Apps. We download a total of 6114 of the above three types of samples in App stores, and we use VulArcher to perform the above vulnerability detection for each App. We perform manual verification by randomly selecting 100 samples of each vulnerability. We find that the accuracy rate for ACOCDV can reach 100%, the accuracy rate for WBCVV can reach 95%, and the accuracy rate for the other two vulnerabilities can reach 87%. And one of vulnerabilities detected by VulArcher has been included in China National Vulnerability Database (CNVD) ID(CNVD-2017-23282). Experiments show that our tool is feasible and effective. For the convenience of researchers in related communities, We make our data and tool available at https://buptnsrclab.github.io/blog/2020/01/03/vularcher-site-launched.


I. INTRODUCTION
With the rapid growth of functional requirement of mobile Apps, the development iteration of Apps is more and more rapid. In this circumstance, developers focus on how to quickly implement the logical functions of Apps and make it more user-friendly. Nevertheless, they spend little time on security issues of Apps.
The security issues of Apps are complex and challenging. Related research on Android security has been proposed, The associate editor coordinating the review of this manuscript and approving it for publication was Kashif Saleem .
including static [1]- [8] and dynamic [9], [10] methods. Wei et al. [11] just analyzed Android vulnerabilities which are assosiated with JavaScript. Mutchler et al. [12] and Chin and Wagner [13] analyzed a large-scale of mobile web Apps, and found that vulnerabilities are presented in all corners of the Android ecosystem. They did not propose methods for vulnerability verification. Li et al. [14] analysed a small set of Android music Apps and focused on the issue of data leakage during client and server communication.
Li et al. [15], [16] proposed a solution to quickly identify Android source code vulnerability ignoring to analyse Apps' vulnerabilities. Mu et al. [17] contributed to how to quickly VOLUME 8, 2020 This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ reproduce the vulnerabilities by combining the vulnerability reports with widely crowdsourced information. In 2019, Diao et al. [8] analyzed one vulnerability caused by the usage of the accessibility API. Amin et al. [9] focused on proposing a detection tool for Android vulnerabilities, they did not give out a methodology for analyzing Android vulnerabilities. Luo et al. [18] was concerned about the vulnerabilities of the Android Framework and adopt a symbolic execution method to detect vulnerabilities. Wu et al. [19] conducted a systematic study for Android system vulnerabilities. Aforementioned vulnerabilities researches are related to the web vulnerabilities [20]. Although these vulnerabilities have been reported for a long time, they have received little attention. Moreover, researchers did not consider how to analyze the vulnerabilities of these Apps if it is packed [21]- [23]. To the best of our knowledge, there is little effective analysis on aforementioned vulnerabilities. There is a very serious problem that many vulnerabilities reported early still exist in latest Apps, even in the same App. The main reason is that there is no feasible and complete vulnerability verification workflows for developers. In additional, more and more web functions are used in Apps [24], these functions may also increase new vulnerabilities of Apps. Users send their information through the network in the process of Apps,which makes it is particular important for Apps to ensure(assure) their security.
In this paper, our target of vulnerabilities are related to web functions. By manual analysis of 400 Apps, we find the vulnerabilities caused by the misuse of APIs accounted for the majority, and the most of vulnerabilities caused by API misuse are WRCEV, WBCVV, ICV and ACOCDV. So we chose these four vulnerabilities as our study goals. At the same time, we divide the above four vulnerabilities into three categories based on their behaviors: Overridden method(Cat1:OM), Use unsafe settings(Cat2:USS) and Data leakage of sensitive information(Cat3:DLSI).
Contributions. Based on the above analysis, we explore the severity of these vulnerabilities and perform the comprehensive study on the four vulnerabilities caused by the misuse of APIs and form an analysis methodology for each category of vulnerabilities. In order to mitigate them, we propose corresponding improvement recommendations. Based on the methodology, we propose a vulnerability verification workflow for each vulnerability. In order to verify the effectiveness of our analysis methodology in large-scale Apps on the Internet. Based on our findings, we propose a vulnerability detection tool, named VulArcher. It can detect the above four vulnerabilities in packed or unpacked Android Apps,and the average accuracy rate is 91%.The main contributions are as follows: (1) For the four vulnerabilities that are caused by the misuse of APIs, we divide them into three categories based on their behaviors. we perform the comprehensive study on them and form an analysis methodology for each vulnerability, which can help researchers to discover other vulnerabilities in the three categories. Based on the analysis, we provide improvement recommendations to mitigate the vulnerability threat.
(2) Based on the methodology, we propose a vulnerability verification for workflow for each vulnerability, relevant researchers can verify corresponding vulnerabilities following them.
(3) In order to verify our methodologies in large-scale Apps, we propose a static and scalable vulnerabilities detection tool based on our findings for vulnerability analysis,VulArcher. We download 6,177 Android Apps containing transactions from the Internet, which are the latest version in 2018. After our random manual verification of the results of VulArcher, it shows that the average accuracy rate is 91%. In addition, VulArcher can also detect the vulnerabilities on packed Apps. By adding rules in a configuration file, VulArcher can detect other categories of vulnerabilities. We will share VulArcher at https://buptnsrclab.github.io/blog/2020/01/03/vularcher-sitelaunched.

B. ANDROID API AND ANDROID SDK
An Android API is an interface provided to developers to invoke system services, making App development more efficient and convenient. Here are a few Android APIs related to this paper.   WebView is an Android component that displays webpages and supports the execution of JavaScript. And its APIs are designed to customize WebView for developers. SDK is a set of tools provided by an organization, and are used to develop Android applications. For example, SDK provided by Alibaba help developers use the company's services. HTTPs is an extension of the Hypertext Transfer Protocol (HTTP). It is used for secure communication over a computer network, and is widely used on Apps. In the use of such a network transmission protocol, the App verifies whether the certificate on the server side is a compliant certificate, so that both sides of the communication can be trusted. Apps use the X509TrustManager class to trust certificates. The weakness that the App improper certificate validation is described in CWE-295, when a certificate is invalid, it might allow an attacker to spoof a trusted entity by using a man-in-the-middle (MITM) attack. The weakness code is shown in Fig 1. TABLE 4. Statistics of Vulnerabilities in the 100 Apps ('ICV' refers to 'Improper certificate validation, 'WBCVV' refers to 'WebView bypass certificate validation vulnerability', 'WRCEV' refers to 'WebView remote code execution vulnerability' and 'ACOCDV' refers to 'Alibaba Cloud OSS credential disclosure vulnerability'). We extract 100 Apps in the dataset, After manual analyzing, we find that 81 of these Apps with the weakness, as shown in Table 4. Hence we analysis this weakness in the paper.

2) WebView BYPASS CERTIFICATE VALIDATION VULNERABILITY (WBCVV)
The WebView component supports certificate verification when loading webpages with HTTPs protocol. As described in CVE-2014-5531, when an App is displaying data through WebView, at the same time, the function of verifying the validity of the certificate in this component does not work. In this case, the App will be vulnerable to man-in-the-middle attacks, And attacks can obtain sensitive information via a crafted certificate. As shown in Fig 2, the WebView is used to load the webpage, when the certificate verification fails, it still allows the data exchange between the App and the server side of the crafted certificate. Table 4 shows that we find 86 Apps in 100 have this vulnerability, so it is worthwhile to analyze the vulnerability in detail.

3) WebView REMOTE CODE EXECUTION VULNERABILITY (WRCEV)
According to Google [25], there are 2 billion active devices on Android monthly, and close to 10% are running in Android 4.3 or lower versions and more than 4% are running in Android 4.1 or lower versions. That indicates that JS-to-Java interface vulnerabilities may still affect hundreds of millions of users.   to bridge between JavaScript and Java. It is equivalent to inject a Java object into the environment of JavaScript. So the JavaScript code running in the WebView can call all the public methods of the Java object by the object name. However, in this scenario, proper security measures are not used, which can lead to WRCEV as described in CVE-2014-1939, an attacker can fake a malicious JavaScript script to attack an App. The code shown in Fig 3 that uses this Javato-JavaScript, but it does not have security restrictions, so it causes the vulnerability. Table 4 shows that the vulnerability exists in current App Stores, and we should analyze why this vulnerability still occupies a high proportion.

4) ALIBABA CLOUD OSS CREDENTIAL DISCLOSURE VULNERABILITY (ACOCDV)
ACOCDV is a new vulnerability with wide influence in 2017. Alibaba cloud Object Storage Service (OSS) is a massive, safe and highly reliable cloud storage service provided by Alibaba. As shown in Fig 4, when developers use Alibaba cloud OSS service framework by the SDK, sensitive information, such as AccessKey and AccessKeySecret, is directly written into the code (for data protection, we perform sensitive information erasure processing). An attacker can easily get sensitive information through reversing the App, it causes data leakage from developers on cloud services. The data in Table 4 shows that the vulnerability the existence rate of the vulnerability is 20%, so the vulnerability of data leakage should be taken seriously.

B. CASE STUDY 1-WebView REMOTE CODE EXECUTION vulnerability(WRCEV) 1) VULNERABILITY TO EXPLAIN
java/android/webkit/BrowserFrame.java in Android 4.4 and earlier uses the addJavascriptInterface in conjunction with creating an object of SearchBoxImpl class, which allows attackers to execute arbitrary Java code by leveraging access to the SearchBoxJavaBridge_ interface at certain Android version.
An App in the above environment, when the WebView component uses the addJavascriptInterface(Object object, String name) API to establish the connection between JavaScript and Java without security restrictions. JavaScript in the webpage not only has permission to call Java object's methods in its runtime environment, but to execute Android system commands.
The above description of the vulnerability is summarized that when the App runtime environment belongs to Android version 4.4 or below, if the WebView addJavascriptInterface(Object object, String name) API is used in the App and the developer has not added security restrictions, an attacker can build malicious JavaScript code perform instruction execution on the App.   webpage. Also, it uses addJavascriptInterface(Object object, String name) API to make the JavaScript code can call the b object by string a method in the called HTML page. However, this App does not limit the vulnerability through some protection methods, so the App has the vulnerability.
We install the App on an Android emulator, we open the browser to tap an url, such as https://www.yahoo.com. As is shown in Fig 6a, the App correctly displays the page passed by the url. Viaing a MITM attack, we forged malicious JavaScript code into the webpage. Malicious JavaScript code executes the command ''ls -al /MNT/sdcard/'' to read file information in sdcard. As shown in Fig 6b, malicious JavaScript normally runs on the vulnerable App, which reads the file information from the sdcard directory of the Android device. It indicates that this vulnerability exists and can be exploited in the App.

3) INSIGHT
When developers use the addJavascriptInterface (Object object, String name) API to call a web page. As summarized in Table 5, the functions of removing the risk interface should be added to limit the permission of JavaScript code. They can eliminate the WRCEV in Apps.   SDK of the service need to be called in the App. However, developers usually simply copy the official sample code and don't consider the security weekness of programming. Fig 7 is the demo code provided by the Alibaba cloud. Attackers can obtain this set of credentials by using the OSS management tool to get the data in the service easily. It will result in information leakage and constitute a serious security weekness.

2) VULNERABILITY POC
(1) File MD5: fea5226fdf7a1a1ed95d6c24a6e30f06 (2) version: 4.37 (3) Exploit: In order to facilitate the manual analysis and reading of the source code of the App, we use the Jeb [26] tool to reverse the App when manually verifying the vulnerability. Because the App is packed, we use our unpacking tool [27] to get the source code of the App. As shown in Fig 8, it is the source code which is obtained after unpacking the App. Fig 9 is the code which contains sensitive information in the App. In onCreate method, we find construct the object Alibaba cloud storage service initializes the object. When constructing an object, this method directly invoke the accessKeyId and accessKeySecret, and both of these sensitive values are hard coded by the developer in the program, thus it causes the weakness of sensitive information.

3) INSIGHT
Inorder to prevent data leakage of sensitive information of accessKeyId and accessKeySecret. Developers should encrypt sensitive information when using the Alibaba OSS SDK.

D. VULNERABILITY CHARACTERISTICS
As shown in TABLE 6, the characteristics of vulnerabilities are summarized after a comprehensive case study of each vulnerability. In addition, after a lot of manual analysis of Apps of above vulnerabilities. We divided the four vulnerabilities into three categories, and generalized the analysis methods and characteristics of each type of vulnerability based on the four specific vulnerabilities. The details are described as follows.

1) IMPROPER CERTIFICATE VALIDATION (ICV)
An App uses the method of checkServerTrusted. No certificate verification operation is performed in it, or in this method, only the expiration time of the certificate is verified, and no other information is verified.

2) WebView BYPASS CERTIFICATE VALIDATION VULNERABILITY (WBCVV)
An App uses the WebView API for certificate verification, but the method onReceivedSslError(WebView view, SslErrorHandler handler, SslError error) which is for handling the exception certificate does not perform any processing. This causes the abnormal certificate to pass the verification.
Vulnerability in overridden method (OM). The functions that lead to the above two vulnerabilities have common characteristics in analytical methods. These are subclass methods provided by the Android system to developers to customize the strong validation logic, and the parent class methods they inherit have the vulnerable logic in default. Developers don't strictly follow the security specifications to customize the security policy code. The analysis method for this type of vulnerability is described in TABLE 6. An App has a overridden method that is to do the security validation, and its inherited parent method is a weak logic in default. If the method of the App is not written with strong verification, then the App is vulnerable.

3) WebView REMOTE CODE EXECUTION VULNERABILITY (WRCEV)
There are three elements that can cause an App to have this vulnerability. First, the App needs to support to run on Android version 4.4 or below. Second, the App uses Web-View's API addJavascriptInterface(Object Object, String name) to allow JavaScript to run Java. Finally, the App does not add an API as shown in TABLE 5 to remove the weekness interface in the context of using the above API.
Vulnerability of using unsafe APIs (USS). For an App, it uses a potentially vulnerable API, and the developer does not perform codes to protect against the vulnerability in the calling link and the context of it. Because some vulnerabilities are related to the Android environment, API level required for Apps is also one of the elements to identify the vulnerability. We can combine the above elements to determine whether the vulnerability exists.

4) ALIBABA CLOUD OSS CREDENTIAL DISCLOSURE VULNERABILITY (ACOCDV)
For an App that uses the API OSSPlainTextAKSKCre-dentialProvider provided by the Alibaba OSS SDK to create credential information with server, its secretKey needed in the method is hard coded in the program. This causes the existence of information disclosure vulnerability.
Data leakage of sensitive information (DLSI). The analysis and characteristics of this category vulnerabiliy is shown in TABLE 6. An App has an invoke method that uses sensitive information. The object of the sensitive information is traced to determine whether it is hard-coded in the App. If it is hard-coded in it then the vulnerability exists. Fig 10, the working process of VulArcher can be divided into the following steps:

1) DECOMPILATION
For an App, VulArcher decompresses it to obtain the classes.dex file which contains the source code, the Android-Manifest.xml file which contains component information, permissions and the resource files. VulArcher reverses the classes.dex based on Androgurd [28]. Through this process, It obtains the classes and methods in the source code of the App. Also it decompiles the AndroidManifest.xml file to obtain registered component information and configuration information.

2) PACKER IDENTITION
VulArcher recognizes whether an App is packed according to formula (1) and (2). AC indicates the number of all components registered by the App, and CC indicates the number of classes in classes.dex which can obtain from the AC. Because the packed App almost hides all components and other logic codes, classes.dex does not contain these information. Some packing methods have signature files, ie. libexe*.so and libexecma**.so. In order to further clarify packing methods, VulArcher uses the fingerprint to identify the detailed packing type and version of the App.
3) UNPACKING At present, more and more Apps are packed. Static analysis can not directly get the real code of the packed Apps. This causes static detection to fail to analyze vulnerabilities of such Apps. Therefore, the analysis of packed Apps should be carried out by unpacking method, for extracting the original code of Apps. The unpacking method used in this system DexX [27] is a result of our previous research. It can handle the six packers, such as Ali [29], Baidu [30], Bangcle [31], Tencent [32], Qihoo 360 Mobile [33], and ijiami [34]. This paper does not elaborate too much for the method.

4) BUILDING TAINT PATH
VulArcher creates a taint control flow graph(TCFG) of a classes.dex, the algorithm is shown in Algorithm 1. VulArcher creates a control flow graph(CFG) of the classes.dex. the set V of p nodes in CFG is shown in formula (3). Each v k contains the package name(pkg k ), class name(c k ) and method(m k ). As shown in formula (4), the set IA of m interested APIs is a subset of V . For each iA j , we follow the heuristic method to find its taint path tp j , it's shown in formula (5). V is a subset of V , the points in V are related to the control flow of iA j . If v k has a control flow to v w , VOLUME 8, 2020 BuildG(TCFG, tp j ) {Building the TCFG with tp j .} 7: end for 8: return TCFG we think there is a taint control flow relationship from v k to v w <v k , v w >, we denote the set of all the above relationships as E . As shown in formula (6), TCFG is composed of all tp j (j = 1, . . . . ., m).

5) DETECTION
VulArcher uses the rules of above vulnerabilities and the TCFG of an App generated in the Building Taint Path for vulnerability judgment. In order to detect vulnerabilities faster, we propose a heuristic vulnerability search algorithm as described in Algorithm 2, so that we can avoid matching vulnerability rules of all App code. For tp j , VulArcher extracts its context slices(cs j ). R is a set of vulnerability rules.
We just need to find interesting points directly in the paths of the vulnerabilities. In this way, the entire vulnerability search process is fast and accurate.

B. EXTRACT SUSPICIOUS CODE SEGMENT
An App contains many classes and methods, if we iterate through each method to search vulnerabilities and weaknesses, it will certainly affect the efficiency of detection. So we first built the TCFG of the App, recording classes and methods that contain suspicious interesting paths. When we are looking for vulnerabilities, we can use the heuristic-based approach described in Algorithm 2 to find out if a vulnerability exists. The interestSet in the algorithm represents all sensitive APIs and methods that may cause vulnerabilities in the App. FR represents a collection of rules for vulnerability fixes and TR represents the set of rules that trigger the vulnerability. The algorithm first obtains a suspected vulnerable point in interestSet, then in the already constructed TCFG, it constructs the relevant slice content of all objects and path ⇐ FindPath(TCFG,ti) 6: contextSlice ⇐ GetContextSlice(path) {Geting detailed function information by the path.} 7: if (FR = ∅) and (TR = ∅) then 8: if HeuSearch(contextSlice,TR) == True and HeuSearch(contextSlice,FR) == False then 9: output(path,contextSlice) 10: end if 11: end if 12: if FR = ∅ then 13: if HeuSearch(contextSlice,FR) == True then 14: continue 15: else 16: output(path,contextSlice) 17: end if 18: end if 19: if TR = ∅ then 20: if HeuSearch(contextSlice,TR) == True then 21: output(path,contextSlice) 22: else 23: continue 24: end if 25: end if 26: end for 27: return output(path,contextSlice) variables in the point, that is, contextSlice. It uses a heuristic search algorithm to search in contextSlice. If there is a rule for repairing the vulnerability in the slice, then the App does not have the vulnerability. Otherwise, if it finds the rule for triggering the vulnerability in slice through the search algorithm, then it records the complete path information and slice of the vulnerability of the App.

C. VERIFY METHOD AND WORKFLOW
Nowadays there are more and more vulnerability detection tools. To some certain extent, they can detect some vulnerabilities and weaknesses. But they do not provide developers with some way to reproduce vulnerabilities. This is the reason why more and more vulnerabilities are ignored by developers, as a result, many Apps still have vulnerabilities that have  been reported for a long time. In this paper, we provide semi-automated verification methods and workflow for the vulnerabilities and weaknesses we analyzed. This work can verify the detection results of VulArcher and provides readers with clear methods of vulnerabilities' verifications. Fig 11 depicts the attack architecture for this weakness. First, we set up the environment to enable Burpsuite [35] to block all network traffic from mobile. We write a script based on Burpsuite, which is mainly responsible for analyzing the traffic information of mobile, extracting the Host and body and sending it to the server. The web service module is mainly responsible for auto installing Apps and recycling the results of analyzing network traffic, also, determining whether the App is attacked by MIMT automately.

2) A VERIFICATION METHOD FOR WRCEV
As shown in Fig 12, our verification method is mainly to inject malicious JavaScript code in to the App's network traffic by MIMT. We use Burpsuite to block all traffic sent by the mobile and injecting the written malicious JavaScript code in the response. If the JavaScript can successfully execute malicious code, the code will send a record to the web service to record whether the App exists the vulnerability. The distribution of three types of Apps from January to August 2018('S' refer to 'Shop', 'F' refers to 'Financial', 'B' refers to 'Browser' and 'T' refers to 'Total').

TABLE 9.
All types of vulnerability of the Apps test results manually('N' refers to 'Numbers of Samples' and 'NFP' refers to 'Numbers of False Positives';'ICV' refers to 'Improper certificate validation, 'WBCVV' refers to 'WebView bypass certificate validation vulnerability', 'WRCEV' refers to 'WebView remote code execution vulnerability' and 'ACOCDV' refers to 'Alibaba Cloud OSS credential disclosure vulnerability').

3) A VERIFICATION METHOD FOR ACOCDV
We use the Jeb to reverse the App, and we look for the code module initialized by OSSClient in the reverse smali code. We find out whether initialize method by using plaintext accessKey and secretKey. We get these keys, and use the OSSUtils to connect the service.

V. EXPERIMENT
Our experiments are performed in the following environment: The CPU is e5-2640v4, the memory is 32G, system is Linux 64 and python 2.7.

A. COLLECT ORIGINAL SAMPLES
In this paper, the main types of Apps we focus on are financial, shopping, and browser. We downloaded a total of 6177 Apps from the Baidu [36], Wandoujia [37], Qihoo [38] and Huawei [39] App Stores, which were released from January to August 2018. Of these, 3,160 Apps are in the financial category, 2,954 Apps are in the shopping category, and the remaining 63 Apps are in the browser category. Table 7 shows the distribution of three types of Apps from January to August 2018. It includes classification by sample category of Apps, classification by time. Table 8 shows the distribution of three types of Apps' size.  according to whether or not is packed. It can be seen that even if the App is packed, vulnerabilities cannot be fixed. Through the results, WBCVV and ICV have a high ratio, because most of the Apps' network communication protocols now use HTTPs, developers use APIs to develop these functions, and ignore the security of certificate verification for the convenience of the development process. WRCEV is the least, there may be a direct relationship with the current Apps that rarely supports version of Android 4.4 and below.

B. ANALYZE THE RESULTS
Finding 1: Although the WRCEV was first reported in 2014, there is still a 4.7% Apps in the currently released browser Apps.
Finding 2: When the JS-to-Java reflection function in WebView is used in Apps, it is able to strictly limit the Android version to be greater than 17, and use the interface function shown in TABLE 5.
Manually Verfify. We randomly select samples with and without vulnerabilities in the detection results. We manually analyze those samples. For those which need a user account to use, and these accounts are not free to register externally, these are not the scope we consider. The analysis results are shown in TABLE 9, it is showed that VulArcher detects ACOCDV with high accuracy.
Finding 3: When we do the MITM, we find that many Apps not only do not carry out certificate verification, but also transmit sensitive data such as user name and password in plaintext. It is very easy to cause the leakage of sensitive information. So it is necessary to encrypt sensitive information.
Finding 4: The detection accuracy for ACOCDV can reach 100%, and for WBCVV can reach 95%. Also the accuracy is lightly lower and can reach 87% for the other two vulnerabilities. VulArcher can help developers detect vulnerabilities before Apps are released. It can avoid releasing Apps with the above vulnerabilities.
The irrelevance of vulnerabilities and sizes of Apps. Fig 13 shows the number of vulnerabilities in Apps with different sizes. It can be seen that the same category of  The relationship between vulnerabilities and categories. Fig 14 shows the probability of vulnerabilities for each of the categories of Apps. ACOCDV does not exist in the browser Apps, because they do not need to use this service to store a large number of images. The reason that the percentage of WRCEV in these Apps is slightly higher than the other two types of Apps is most of these Apps use the WebView component and many of them support for the Android 4.4 version.
Finding 6: More and more Apps face the vulnerability of MITM, because developers do not validate certificate for convenience. So certificate validation must be done strictly in the development.
Finding 7: Although Alibaba OSS SDK has released new instructions to circumvent this credential information leak [40], results in Fig 14 shows that many Apps still have this vulnerability. This means that Apps should be timely updated the SDKversion to fix the vulnerability.
The trend of the vulnerability. Fig 15 shows the trend of probability of vulnerabilities for Apps in each month from January to August in 2018. It can be intuitively reflected that there are vulnerabilities and weekneses in the monthly release of Apps, and the number of vulnerabilities does not decline over time.
Finding 8: As shown in Fig 15, the trend of vulnerabilities tends to be in a stable state. This shows that various vulnerabilities still exist in Apps and developers do not mitigate these vulnerabilities.

C. VulArcher PERFORMANCE
Efficiency. VulArcher takes an average of one minute to analyze an App. However, if the analysis App is packed, then the time to unpack it is an average of 50 seconds.
Computing cost. For an App, the memory consumption is 400M, CPU utilization is 40%.
Scalability. VulArcher supports the rules of vulnerabilities to detect them. Hence, for a new vulnerability, VulArcher only need to konw the vulnerability rule to complete the detection of the new vulnerability.

VI. DISCUSSIONS AND LIMITATIONS
We download the Apps to analyze the four types of vulnerabilities, but the Apps was two years ago. We should use the latest data for analysis. However, the latest Apps compared with the previous ones, the Android system versions they support has not been updated much, the APIs used in them has not been updated. Our findings are not biased. The vulnerability results detected by VulArcher contain both third-party components and the App itself. At present, we regard these two aspects as all the vulnerabilities of the App. If we want to distinguish the vulnerability results. We can organize a third-party component library, which contains information such as the package name of the component. The vulnerability results detected by VulArcher contains the package name and class name of a vulnerability, so we use the package name and the class name to go back to the component library to check whether the vulnerability belongs to the App itself or third-party components.

VII. RELATED WORK
The study of Android vulnerabilities can be divided into two aspects, one is about the Apps and the other is about the Android OS.
Li et al. [14] just conducted a detail analysis of the vulnerabilities that will occur in the music Apps. The music Apps that are analyzed mainly produce man-in-the-middle hijacking attacks when communicating with servers. Qian et al. [23] proposed a structure called app property graph (APG) for Android vulnerabilities. Based on this feature representation method, a detection tool is proposed for five common vulnerabilities. But they did not give workflows for the verification of the vulnerabilities. Chen et al. [41] manually analysed several OAuth providers for Apps and determined how differences between the Apps and browser environments lead to the OAuth vulnerability. Wu et al. [1] proposed a detection method for the confused deputy vulnerability in Android applications based on features of AndroidManifest.xml file and Control Flow Graph (CFG). Fang et al. [5] studyed an input validation vulnerability in Android inter-component communication. This kind of vulnerability is caused by the incomplete security verification mechanism of Apps developers. Yang et al. [10] used a combination of static and dynamic methods to analyze the App's dynamic loading vulnerability. This kind of vulnerability is caused by the insecure verification on the loaded executable file. Yang et al. [20] studyed about security issues caused by mixed postMessage Origin Stripping Vulnerability(OSV) in Apps. Ranganath and Mitra [42] proposed a detection tool for supporting large-scale Android vulnerabilities, they didn't conduct analysis method for vulnerabilities. Farhang et al. [43] focused on how different when vendors deal with Android vulnerabilities.
Other studies explored different vulnerabilities from we studied. Feng and Shin [44] analyzed some vulnerabilities related to Binderin Android, and proposed an automated tool for detecting this type of vulnerabilities from the analysis of   the causes of the vulnerabilities. Linares-Vásquez et al. [45] analyzed Android system vulnerabilities by using the Bulletin resource. Zhang et al. [21] mainly studyed the Android system-level vulnerabilities. Through analysis rules and results, they proposed a detection tool for this type of vulnerabilities.

VIII. CONCLUSIONS
We deeply analyzed the four kinds of vulnerabilities on a data set with more than 6000 Android Apps. The aforementioned vulnerabilities are ACOCDV, WRCEV, WBCVV and ICV. We found that webview and HTTPs are existed in most of finance and shopping apps. According to this, attackers can easily perform MITM. As for WRCEV which has been disclosed for a long time, it still exist in browser Apps, because developers lack the methods of vulnerability identification and security development awareness. Apps that use Alibaba Cloud OSS services, information leakage vulnerability of Alibaba cloud OSS credentials is caused by the weak secure awareness of developers. We developed a vulnerability detection tool, VulArcher. The experiments show that it can automatically detect the above vulnerabilities, and has good scalability. One of vulnerabilities which VulArcher detected had been included in China National Vulnerability Database (CNVD) ID(CNVD-2017-23282). It detected more than 6000 Apps and found nearly 3000 Apps with the above vulnerabilities. and we have manually verified the accuracy of results among nearly 300 Apps. The source codes of VulArcher and sample data presented in this paper can be utilized by further researchers. We incentivize this by making our data publicly available [46]. Table 13 gives the the attack results of ''Alibaba Cloud OSS credential disclosure vulnerability ''. Table 14 gives the attack results of ''WebView remote code execution vulnerability''. Since there are no more than 100 Apps for the above two types of vulnerabilities, we have all analyzed. Table 11 gives a detailed description of 98 Apps randomly selected which were detected ''WebView bypass certificate validation vulnerability''. As Table 12 shown, we selected 99 Apps that were taged as ''Improper certificate validation'', and we recorded whether or not it can be attacked for each App.