This blog post provides insights about the novel phishing attack technique developed in the context of an academic collaboration between EURECOM and the University of Genova.

This is not the first time this collaboration has led to significant findings in this research field. In 2018, our team (at the time) was able to trick some password managers into entering valid login credentials into phony apps [link]. While, back then, we abused at-the-time modern features of Android to mount phishing attacks, in this work, we exploit a feature available since the very first version of this operating system.

Since the objective of this article is divulgation, we will not delve into too many technical details about our attack and the vulnerabilities it exploits. If you want a more thorough and scientific description, you can look at our paper (to appear) at the IEEE EuroS&P 2023 conference, whose preprint is available here.

A picture video is worth a thousand words

The best way to get familiar with our attack is to watch it unfold.

The video above captures everything a user sees on their device’s screen when they launch one of the apps they installed. You might find it peculiar that we showed the same scene twice. In reality, the two scenes are far from being the same. A malicious app has hijacked the user interface in one of the two.

Can you tell with certainty which of the two scenes this happened? Watch the video till the end to find the solution. If you want to understand how this was possible, read on.

Introduction

Being based on Linux, Android inherits many of its features. One of those is inotify, a service provided by the kernel that makes it very convenient for a program to keep track of file system changes like file creation, modification, or deletion. You can think of inotify as a personal assistant that keeps an eye on all your files and alerts you whenever something happens. As you can expect, backup services rely on inotify to catch new or modified files for synchronizing them with the cloud.

While security measures limit what inotify can monitor, this service has already been abused in the past. In 2018, Google security researchers revealed that the popular game Fortnite for Android was vulnerable to Man-in-the-Disk (MitD) attacks [link]. The app distributed on the marketplaces did not contain the game code directly. Instead, it downloaded the data from the publisher’s website. During the download phase, the app stores partial data in the device’s shared storage, moving it to its private directory only once the download is completed. The researchers showed that attackers could tamper with this partial game code file. This was made possible by inotify, which signaled the exact moment the game download started. As a result, an attacker could effectively fool the Fortnite app into installing fake code instead of the intended one, gaining the code execution privilege in the context of the original app.

From inotify to phishing

Like fishing, phishing is all about hiding the hook and placing the bait in the right place at the right time. Following this metaphor, in modern Android phishing schemes, “hiding the hook” means convincing the user to install a malicious app on their device.

Luckily – and thanks to the developers of the Android operating system’s extensive efforts to secure it – just installing a malicious app is not enough for an attacker to access and exfiltrate sensitive data, such as credentials. That’s where “placing the bait” comes into play. In most cases, the malicious app acts like a sort of digital chameleon, being able to imitate the look and feel of another app. If the resemblance between the two apps is high enough, the user may willingly provide the valuable information that the attackers long for so much.

Even this, however, is not necessarily effective on its own. In fact, randomly presenting the user with (something that resembles) their banking service login form will only raise suspicion. That is why the final ingredient to the perfect phishing attempt consists “in placing the bait at the right time,” that is, exactly when the user expects to see the app that the malware imitates. In most situations, the best time to perform a phishing attack on Android is when the user launches the target app. At that time, the user not only expects to see that app appearing on the screen, but they are also more prone to provide credentials or other login information.

Ever since the first malware capable of mounting such timely attacks was documented, the Android security research community has striven to uncover and counter any mechanism to “figure out” when a certain app is starting or running.

Our project fits in this line of research. When we started it, we were wondering:

What if some Android apps during startup perform a certain file operation that precisely determines the startup of that specific app?

In other words, we wanted to find out whether creating a sort of file-system footprint unambiguously characterizes what happens on an Android device when the user launches a certain app. If that happened to be the case, an attacker could abuse inotify to seize the right moment to perform a phishing attack against the vulnerable app.

To test this hypothesis, we built an automated system that tracks the file-system activity of an app right after the user starts it. Our system is capable of filtering only those events that can be effectively monitored by means of inotify. Moreover, it can cross each app’s activity with other apps we analyzed. This way, we can filter out common activities, saving only those specific to one app and to that app only. These two capabilities ensure that any app for which our analysis system can build a file-system footprint can be indeed targeted by phishing attacks.

Findings

In our study, we analyzed 4,863 of the most popular Android apps on the Google Play Store.

What we discovered was disconcerting: ALL ANDROID APPS ARE VULNERABLE against an attacker knowing their installation path. This is true even for all apps, not only those we analyzed in our study.

In fact, what makes this possible is a flaw in the Android operating system that we uncovered and reported to Google. This vulnerability allows monitoring the installation path of any app without any restriction {1}.

To carry out the attack successfully, an attacker must still find out where the targeted app is installed. After all, on Android, the app’s installation path is generated randomly and should be impossible to guess. While this is true in theory, in practice, an attacker can circumvent this obstacle by requesting one permission only (namely, QUERY_ALL_PACKAGES). This permission is labeled as normal, meaning it is granted to an app at installation time without the user being warned.

To make matters worse, during our study, we also found a second vulnerability of the Android operating system that an attacker can leverage to find any app’s installation path without any permission at all {2}.

Of course, we reported the problem to Google, also proposing a remedy. Naturally, we kept on with our investigation. Assuming Android developers will fix the issues reported so far, would there still be room for attackers to leverage inotify for phishing?

The short answer is: YES. In fact, we found out that, under a few conditions, the inotify attack is still possible, though with a smaller impact.

One such condition is related to scoped storage. This is a new file system model – introduced in Android 10 – in which the device’s persistent memory is divided into a private and a shared portion. By inspecting this new model, we uncovered an information disclosure vulnerability {3} that allows getting (at least) a partial list of the apps installed on the device. We realized that our inotify attack could be further refined in light of this new discovery.

In fact, in the original version of our attack, we built the file system signature of an app by comparing it to that of all the ~5k apps we analyzed. In a sense, by doing this, we are assuming that all these apps are installed on the device at the same time. While unrealistic, this is the soundest way of computing an app file system’s signature when we have no knowledge of the apps installed on a device.

This, however, is no longer the case if an attacker can leverage this information disclosure vulnerability. The attack refinement consists of comparing an app’s file system activity with respect to the apps known to be installed on the device. The success of this final refined attack depends on which and how many other apps are installed on the device — the more there are, the harder it is.

Through a statistical approach, we estimated that on devices with an average number of installed apps (35, according to Google) running recent Android versions, an attacker could successfully target half of the apps, EVEN WITHOUT DECLARING ANY PERMISSION.

Responsible Disclosure

We reported three vulnerabilities to Google through the official issue tracker.

{1} The possibility of using inotify in the installation folder of another app (reported in May 2022, acknowledged the same month).

{2} The package visibility bypass that, among other things, allows querying for the installation folder of other apps instead of explicitly declaring the proper permission (reported in July 2023).

{3} The information disclosure in the scoped storage (reported in July 2023, acknowledged in September 2023).

Vulnerabilities {1} and {3} were acknowledged as bugs of moderate severity, while {2} was previously reported by other researchers but was not public.

The team

• Antonio Ruggia (University of Genoa)
• Andrea Possemato (EURECOM)
• Alessio Merlo (University of Genoa)
• Dario Nisi (EURECOM)
• Simone Aonzo (EURECOM)