Continuous Integration (CI) has been widely adopted for automated software building and testing. In CI workflows, various third-party services can be integrated to enhance functionalities. During the integration process, secrets such as tokens and credentials are often used for authentication and authorization. Unfortunately, secret leakage regularly occurs, potentially causing serious consequences. Existing secret scanners detect secrets by matching tokens and credentials through regular expressions, which suffer from low recall rates. In this paper, we identify several issues in regular expression-based secret detectors and propose SecretScout, a new method for scanning hard-coded secrets by detecting their names. SecretScout contains carefully designed detectors to extract candidates. It considers special flags where secrets might exist, and further applies filters to reduce false positives. SecretScout can detect secrets in both structured files (e.g., CI configuration files) and unstructured files (e.g., log files). To demonstrate the effectiveness, we evaluate SecretScout and different versions of GitLeaks and TruffleHog using labeled configuration files. The results show that SecretScout achieves$7.3 \times$and$100 \times$higher recall rates compared to the default versions of GitLeaks and TruffleHog, respectively. We also conduct a measurement study on open-source projects' configuration files, and demonstrate that many true secrets might be leaked.

Mainstream Continuous Integration (CI) platforms have provided the plugin functionality to accelerate the development of CI pipelines. Unfortunately, CI plugins, which are essentially reusable code snippets, also expose new attack surfaces as plugins might be developed by less trusted users. In this paper, we present an in-depth study to understand potential security risks in existing CI plugins. We conduct a comprehensive analysis of plugin implementations on four mainstream CI platforms (GitHub Actions, GitLab CI, CircleCI, and Azure Pipelines), and investigate several weak links in existing plugin distributions and isolation mechanisms. We investigate seven attack vectors that can enable attackers to hijack plugins and distribute malicious code without plugins users being aware, and further exploit hijacked plugins to manipulate the workflow execution. Additionally, we find that plugin dependency (a plugin references other plugins) might further amplify the attack impact of our disclosed attacks. To evaluate the potential impact, we conduct a large-scale measurement on GitHub and GitLab, covering a total of 1,328,912 repositories using the aforementioned CI platforms. Our measurement results show that a large number of repositories and existing plugins, including many widely used ones, are potentially vulnerable to the proposed attacks. We have duly reported the identified vulnerabilities and received positive responses.

Mini-programs are lightweight apps running in super apps (such as WeChat, Baidu, Alipay, and TikTok), an emerging paradigm in the era of mobile computing. With the growing popularity of mini-programs, there is an increasing concern for their security and privacy. In essence, mini-programs are WebView-based apps. This means that they may be vulnerable to the same security risks associated with web apps. In this work, we discovered a new mini-program vulnerability called MiniCPRF (Cross-Page Request Forgery in Mini-Programs). The exploit of this vulnerability is easy, and the attack consequences are severe, leading to unauthorized operations, such as free shopping, and the exposure of confidential information, such as credit card numbers. The root causes of MiniCPRF can be attributed to multiple design flaws in both mini-programs and their super apps, including the insecure routing mechanism, lack of message integrity check, and plain-text storage. To evaluate the impacts of MiniCPRF, we designed an automated analysis framework called MiniCAT. It can automatically crawl mini-programs, perform static analysis on them, and generate detection reports. In large-scale real-world evaluations with MiniCAT, we identified that 32.0% (13,349/41,726) of analyzable mini-programs are potentially vulnerable to MiniCPRF, including some famous ones with millions of users, such as Sohu and Wenjuanxing. Following the responsible disclosure principle, we have reported verified vulnerable mini-programs to the corresponding vendors and developers, and three real-world cases have been confirmed by CNVD. Additionally, we suggest mitigation strategies to resolve the security issue related to MiniCPRF.

Continuous Integration (CI) platforms have widely adopted caching to speed up CI task executions by storing and reusing dependent packages. Unfortunately, CI cache also exposes new attack surfaces when cache objects are shared across trust boundaries. In this paper, we systematically investigate potential security threats of CI cache features in seven mainstream CI platforms (CIPs). We find that existing CIPs have isolation issues in their cache sharing and inheritance strategies, potentially raising cache poisoning and data leakage problems. By exploiting these vulnerable mechanisms, we further uncover four attack vectors enabling attackers to stealthily inject malicious code into the cache or steal sensitive data. Even worse, many CIPs provide vulnerable official cache templates that will mistakenly store and expose sensitive data in the cache by default. To understand the potential impact of our disclosed threats, we develop an analysis tool and conduct a large-scale measurement on open-source repositories. Our measurement results show that many popular repositories are potentially affected by these attacks. We also identify 78 repositories that expose their high-value secrets in cache objects and are at risk of secret leakage. We have duly reported identified vulnerabilities to corresponding stakeholders and received positive responses.

Continuous Integration (CI) is a widely-adopted software development practice for automated code integration. A typical CI workflow involves multiple independent stakeholders, including code hosting platforms (CHPs), CI platforms (CPs), and third party services. While CI can significantly improve development efficiency, unfortunately, it also exposes new attack surfaces. As the code executed by a CI task may come from a less-trusted user, improperly configured CI with weak isolation mechanisms might enable attackers to inject malicious code into victim software by triggering a CI task. Also, one insecure stakeholder can potentially affect the whole process. In this paper, we systematically study potential security threats in CI workflows with multiple stakeholders and major CP components considered. We design and develop an analysis tool, CInspector, to investigate potential vulnerabilities in seven popular CPs, when integrated with three mainstream CHPs. We find that all CPs have the risk of token leakage caused by improper resource sharing and isolation, and many of them utilize over-privileged tokens with improper validity periods. We further reveal four novel attack vectors that allow attackers to escalate their privileges and stealthy inject malicious code by executing a piece of code in a CI task. To understand the potential impact, we conduct a large-scale measurement on the three mainstream CHPs, scrutinizing over 1.69 million repositories. Our quantitative analysis demonstrates that some very popular repositories and large organizations are affected by these attacks. We have duly reported the identified vulnerabilities to CPs and received positive responses.

Package registries host reusable code assets, allowing developers to share and reuse packages easily, thus accelerating the software development process. Current software registry ecosystems involve multiple independent stakeholders for package management. Unfortunately, abnormal behavior and information inconsistency inevitably exist, enabling adversaries to conduct malicious activities with minimal effort covertly. In this paper, we investigate potential security vulnerabilities in six popular software registry ecosystems. Through a systematic analysis of the official registries, corresponding registry mirrors and registry clients, we identify twelve potential attack vectors, with six of them disclosed for the first time, that can be exploited to distribute malicious code stealthily. Based on these security issues, we build an analysis framework, RScouter, to continuously monitor and uncover vulnerabilities in registry ecosystems. We then utilize RScouter to conduct a measurement study spanning one year over six registries and seventeen popular mirrors, scrutinizing over 4 million packages across 53 million package versions. Our quantitative analysis demonstrates that multiple threats exist in every ecosystem, and some have been exploited by attackers. We have duly reported the identified vulnerabilities to related stakeholders and received positive responses.

Android allows apps to communicate with its system services via system service helpers so that these apps can use various functions provided by the system services. Meanwhile, the system services rely on their service helpers to enforce security checks for protection. Unfortunately, the security checks in the service helpers may be bypassed via directly exploiting the non-SDK (hidden) APIs, degrading the stability and posing severe security threats such as privilege escalation, automatic function execution without users’ interactions, crashes, and DoS attacks. Google has proposed various approaches to address this problem, e.g., case-by-case fixing the bugs or even proposing a blacklist to block all the non-SDK APIs. However, the developers can still figure out new ways of exploiting these hidden APIs to evade the non-SDKs restrictions. In this article, we systematically study the vulnerabilities due to the hidden API exploitation and analyze the effectiveness of Google’s countermeasures. We aim to answer if there are still vulnerable hidden APIs that can be exploited in newest Android 12. We develop a static analysis tool called${{\sf ServiceAudit}}$to automatically mine the inconsistent security enforcement between service helper classes and the hidden service APIs. We apply${{\sf ServiceAudit}}$to Android 6$\sim$12. Our tool discovers 112 vulnerabilities in Android 6 with a higher precision than existing approaches. Moreover, in Android 11 and 12, we identify more than 25 hidden APIs with inconsistent protections; however, only one of the vulnerable APIs can lead to severe security problem in Android 11, and none of them work on Android 12.

System services and resources in Android are accessed through IPC-based mechanisms. Previous research has demonstrated that they are vulnerable to the denial-of-service attack (DoS attack). For instance, the JNI global reference (JGR), which is widely used by system services, can be exhausted to cause the system reboot (hence the name JGRE attack). Even though the Android team tries to fix the problem by enforcing security checks, we find that it is still possible to construct a JGR exhaustion DoS attack in the latest Android system. In this article, we propose a new JGR exhaustion DoS attack, which is effective in different Android versions, including thelatest one (i.e., Android 10). Specifically, we developed JGREAnalyzer, a tool that can systematically detect JGR vulnerable services APIs via a call graph analysis and a forwarding reachability analysis. We applied this tool to different Android versions and found multiple vulnerabilities. In particular, among 148 system services in Android 10, 12 of them have 21 vulnerabilities. Among them, 9 can be successfully exploited without any permissions. We further analyze the root cause of the vulnerabilities and propose a new defense to mitigate the JGRE attack by restricting resource consumption via global reference counting.

Android system applies a permission-based security model to restrict unauthorized apps from accessing system services, however, this security model cannot constrain authorized apps from sending excessive service requests to exhaust the limited system resource allocated for each system service. As references from native code to a Java object, JNI Global References (JGR) are prone to memory leaks, since they are not automatically garbage collected. Moreover, JGR exhaustion may lead to process abort or even Android system reboot when the victim process could not afford the JGR requests triggered by malicious apps through inter-process communication. In this paper, we perform a systematic study on JGR exhaustion (JGRE) attacks against all system services in Android. Our experimental results show that among the 104 system services in Android 6.0.1, 32 system services have 54 vulnerabilities. Particularly, 22 system services can be successfully attacked without any permission support. After reporting those vulnerabilities to Android security team and getting confirmed, we study the existing ad hoc countermeasures in Android against JGRE attacks. Surprisingly, among the 10 system services that have been protected, 8 system services are still vulnerable to JGRE attacks. Finally, we develop an effective defense mechanism to defeat all identified JGRE attacks by adopting Android's low memory killer (LMK) mechanism.

In order to effectively detect malware in Android, dynamic analysis techniques with Android emulators are widely adopted. Emulators can be deployed for large-scale malware detection and restored to an ensured clean state in a short period after each app analysis process such that dynamic analysis upon emulators can effectively detect malware. Moreover, emulators significantly reduce the detection cost compared to real devices. However, emulator-based analysis has limited capability in detecting evasive malware that can detect the presence of the emulator-based environment and hide its malicious behaviors. In this paper, we propose RealDroid, a dynamic and emulator-based analysis system that can capture Android evasive malware and is capable of large-scale malware detection. RealDroid completely simulates a real device such that it can't be identified by evasive malware. Thereby, evasive malware can exhibit its malicious behaviors in RealDroid. Moreover, we propose an automated exploration mechanism, i.e., Android Test Engine (ATE), to improve the code coverage of dynamic analysis in RealDroid, such that it provides efficient and effective automatic detection of large-scale apps. Our experimental results demonstrate that ATE in RealDroid achieves much better exploration effects compared with state-of-the-art automatic exploration tools in large-scale malware detection. In particular, it can successfully detect evasive malware.

Nowadays, the popular Android is so closely involved in people's daily lives that people rely on Android to perform critical operations and trust Android with sensitive information. It is of great importance to guarantee the usability and security of Android which, however, is such a huge system that a potential threat may arise from any part of it. In this paper, we focus on the Free Floating window (FF window) which is a category of windows that can appear freely above any other applications. It can share the screen space with other FF windows, dialogs, and activities. An FF window is flexible in both its appearance and behaviour features. We analyse the behaviour features of FF windows, including the priority in display layer and the capability of processing user-generated events. Three types of attacks via FF windows with delicate design in their appearance and behaviour features are demonstrated, i.e., DoS attack against Android system, GUI hijacking by targeting overlap, and input inference using FF windows as a side channel. To address the threat caused by FF windows, we design a priority framework for FF windows, which protects a sensitive activity/FF window declared by developers from being attacked by any malicious FF windows. A complementary solution is proposed to mitigate the confusion attack from malicious activities. Finally, we provide Android with suggestions on how to manage FF windows.