From a little research experiment to an essential component of military arsenals, malicious software has constantly been growing and evolving for more than three decades. On the other hand, from a negligible market share, the Android operating system is nowadays the most widely used mobile operating system, becoming a desirable target for large-scale malware distribution. While scientific literature has followed this trend, one aspect has been understudied: the role of native code in malicious Android apps. Android apps are written in high-level languages, but thanks to the Java Native Interface (JNI), Android also supports calling native (C/C++) library functions. While allowing native code in Android apps has a strong positive impact from a performance perspective, it dramatically complicates its analysis because bytecode and native code need different abstractions and analysis algorithms, and they thus pose different challenges and limitations. Consequently, these difficulties are often (ab)used to hide malicious payloads. In this work, we propose a novel methodology to reverse engineering Android apps focusing on suspicious patterns related to native components, i.e., surreptitious code that requires further inspection. We implemented a static analysis tool based on such methodology, which can bridge the “Java” and the native worlds and perform an in-depth analysis of tag code blocks responsible for suspicious behavior. These tags benefit the human facing the reverse engineering task: they clearly indicate which part of the code to focus on to find malicious code. Then, we performed a longitudinal analysis of Android malware over the past 10 years and compared the recent malicious samples with actual top apps on the Google Play Store. Our work depicts typical behaviors of modern malware, its evolution, and how it abuses the native layer to complicate the analysis, especially with dynamic code loading and novel anti-analysis techniques. Finally, we show a use case for our suspicious tags: we trained and tested a machine learning algorithm for a binary classification task. Even if suspicious does not imply malicious, our classifier obtained a remarkable F1-score of 0.97, showing that our methodology can be helpful to both humans and machines.

A mobile banking app just started up, and the notification "App updated, click here to restart" appears. The graphic theme is the same as the bank. Can we trust it? What if we cannot even trust that tapping an app actually loads the original one? More generally, what if Android notifies an attacker when her victim has just launched the target app of her phishing campaign so that she could cast the hook at the perfect moment?In this paper, we abuse inotify APIs, a mechanism for monitoring file system events, to mount a state inference-based phishing attack from a malicious app installed on the victim's smartphone. We also verified the novelty of our work analyzing 10,000 recent Android malware, and although we found some cases where malware uses inotify for their petty purposes, our attack seems to be publicly unknown.However, since Android constantly evolves year after year, we studied its feasibility over different Android versions and attacker's capabilities. By analyzing 4, 863 of the most popular apps, the most disconcerting finding is that if the attacker knows the installation path of the target app, all Android apps are vulnerable, regardless of the system version. Getting the installation path of an app is a capability that is only protected by a normal permission, and to make matters worse, there are workarounds to get it even without such permission.Even if this capability is denied, we propose different attack models under which this attack is still possible; however, at the end of our work, we provide the remediation to eradicate once and for all these attacks. Through this work, we reported three vulnerabilities to Google. Two were acknowledged as bugs of moderate severity, while the last one was already known but not public.

Nowadays, more than two billions of mobile devices run Android OS. At the core of this success are the open source nature of the Android Open Source Project and vendors’ ability to customize the code base and ship it on their own devices. While the possibility of customizations is beneficial to vendors, they can potentially lead to compatibility and security problems. To prevent these problems, Google developed a set of requirements that must be satisfied for a vendor to brand its devices as "Android," and recently introduced Project Treble as an effort to partition vendor customizations. These requirements are encoded as part of a textual document (called Compatibility Definition Document, or CDD) and various automated tests. This paper performs the first longitudinal study on Android OEM customizations. We first built a dataset of 2,907 ROMs, spanning across 42 different vendors, and covering Android versions from 1.6 to 9.0 (years 2009–2020). We then developed an analysis framework and pipeline to extract each ROM’s customization layers and evaluate it across several metrics. For example, we analyze ROMs to determine whether they are compliant with respect to the various requirements and whether their customizations negatively affect the security posture of the overall device. In the process, we focus on various aspects, ranging from security hardening of binaries, SELinux policies, Android init scripts, and kernel security hardening techniques. Our results are worrisome. We found 579 over 2,907 (~20%) of the ROMs have at least one violation for the CDD related to their Android version — incredibly, 11 of them are branded by Google itself. Some of our findings suggest that vendors often go out of their way to bypass or "comment out" safety nets added by the Android security team. In other cases, we found ROMs that modify init scripts to launch at boot outdated versions (with known CVEs and public POCs) of programs as root and reachable from a remote attacker (e.g., tcpdump ). This paper shows that Google’s efforts are not enough, and we offer several recommendations on how to improve the compliance check pipelines.

In the context of mobile-based user-interface (UI) attacks, the common belief is that clickjacking is a solved problem. On the contrary, this paper shows that clickjacking is still an open problem for mobile devices. In fact, all known academic and industry solutions are either not effective or not applicable in the real-world for backward compatibility reasons. This work shows that, as a consequence, even popular and sensitive apps like Google Play Store remain, to date, completely unprotected from clickjacking attacks. After gathering insights into how apps use the user interface, this work performs a systematic exploration of the design space for an effective and practical protection against clickjacking attacks. We then use this exploration to guide the design of ClickShield, a new defensive mechanism. To address backward compatibility issues, our design allows for overlays to cover the screen, and we employ image analysis techniques to determine whether the user could be confused. We have implemented a prototype and we have tested it against ClickBench, a newly developed benchmark specifically tailored to stress-test clickjacking protection solutions. This dataset is constituted by 104 test cases, and it includes real-world and simulated benign and malicious examples that evaluate the system across a wide range of legitimate and attack scenarios. The results show that our system is able to address backward compatibility concerns, to detect all known attacks (including a never-seen-before real-world malware that was published after we have developed our solution), and it introduces a negligible overhead.