Simple Spyware
Androids Invisible Foreground Services and How to (Ab)use Them

We found out that foreground services do not show any visual notification when the service’s execution time is shorter than five seconds¹¹1The exact duration is depending on the phone.. We use this loading time and combine it with another flaw in Androids Job Scheduler API to continuously execute tasks from a background context. Exploiting these flaws allows apps to use the device’s resources, even when the app is closed or on standby. Furthermore, we show that we can use these flaws for continually spying on users and allowing malware developers to create spyware without the need for complicated exploitation.

We start in Section II with some basic introduction to Android’s components and then we explain how we spawn a foreground service on Android Pie combined with some basic background schedulers. We then use this basic example to show how we can use these API’s to implement a simple spyware app. At the end of the paper in Section V we discuss some limitations as well as ideas to prevent such attacks.

Android defines two basic types of service classes for apps, background and foreground services [3]. The difference between these services is how they appear in the user interface and under which constraints they are executed. We can start Foreground services even when the user interface is closed; in contrast, background services cannot do so. The operating system prevents background services to start when the app’s user interface is closed by throwing an IllegalStateExeception. If we want to run a task when the app is closed, we can use Android’s scheduling classes instead. For example, the JobScheduler [4] and AlarmManager [5] classes.

Those schedulers’ idea is that apps can synchronize or process data even when the user interface gets closed. We can use this, for example, to set an alarm clock or to upload a file when the user interface is not needed. If misused, schedulers often use a lot of battery power. For example, when an app is continuously uploading data in the background. Since Android Oreo and app can no longer run endless background services when its user interface is not shown. Usually, the operating system stops all services some minutes after the app was closed. Moreover, access to sensors like microphones and cameras should no longer work when the app is closed. In case an app tries to access one of the restricted sensors from a scheduler, the operating system throws an IllegalStateException, and the access is thereby not granted. However, in order to access the sensors from the background context, foreground services can be used. Schedulers are allowed to start foreground services, and as mentioned, foreground services do not have any restrictions when it comes to sensor access. The only limitations foreground services have is that they need to show a permanently visible notification and that the app spawning the foreground service needs to have the permission to access the sensor. Listing 1 shows an example code to start a foreground service in Java.

What we can see in Listing 1 is that we extend the service class and that we define a onStartCommand method in Line 6 as we would do with a regular foreground service. To start a foreground service, we have to define a notification. On Lines 20 to 31, we define the notification and set an example icon and text. As shown, we can customize the appearance of the notification as we would like it to be. Figure 1 shows how such a foreground service in the user interface could look.

The notification is sticky, and we cannot dismiss it until we stop foreground service or the user manually disables the notification. Attempting to cancel the notification within Java will not work since the notification manager will not allow it. An attacker could hide its intention by showing some typical notification like an update, announcement, or loading screen. In many cases, as long as the notification does not stay too long in the notification bar, it will not raise the user’s suspicion. Nevertheless, users could get suspicious or annoyed when the notification shows them some unwanted content or the notification stays too long in the notification bar. In such cases, the user can stop the app or disable the notifications for the app.

As attackers, we wanted to go a step further and see if we could stop the notification from showing up at all, so that the users would not get alarmed. So we search for possibilities to dismiss or cancel the notification but could not find an easy way to do it. Instead, we found out that the notification manager does not show a notification when the foreground service’s lifetime is shorter than five seconds. We can use this race condition to execute any code before the operating system loads the notification.

We can spawn one invisible foreground service and execute our code once, and then the app will stop. To further abuse this approach, we needed a way to persistently spawn new foreground services on demand. To do so we use Android’s JobScheduler [4] or AlarmManager [5] classes which allows to execute code outside of the app context. For decided to use for our example the JobScheduler class but the AlarmManager has more or less the same functionality. We create a new Job with the JobInfo.Builder [6] as shown in Listing 2.

As attackers, we want to use the JobScheduler to start a job every X seconds or minutes. Our idea is that we want to execute any malicious command like taking a picture or uploading a file whenever we need it. The JobScheduler class has a method .setPeriodc(long seconds) that offers precisely that. The problem with this method is that it has a minimum interval of 15 minutes. So if we would use it, we could only execute malicious code every 15 minutes. For some malicious commands, this is maybe a too long period, so we wanted to circumvent this limitation. Instead of using the .setPeriodic method, we can create a custom scheduler. All we have to do so is to use the JobScheduler’s .setMinimumLatency method. This method allows us to run a job after a given delay and has no limitations in execution time. In other words, we can set a delayed job under 15 minutes an circumvent the limitation. Consequently, we can build our period job scheduler by chaining jobs with the delay function. Whenever we execute a job, we schedule a new job directly with the delay method. As long as our job chain is not interrupted, we can use the JobScheduler class to spawn new foreground services at demand. The chaining of jobs in combination with foreground services allows us to circumvent the background service limitation introduced in Android Oreo [1] and the background sensor access limitation introduced in Android Pie [2].

If we want, we can further enhance our scheduling with some other options of the JobScheduler class. For example, we could only schedule jobs when the device is charging or connected to wifi. We can as well change our scheduling strategy during execution if necessary, to stay undetected.

• •

  setPersisted(boolean isPersisted): This allows that a job persists restarts. Needs the received_boot_completed permission to do so.

• •

  setRequiredNetwork(NetworkRequest networkRequest) and setRequiredNetworkType(int networkType): This allows us to define a specific network type to be active before the job is executed.

• •

  setRequiresBatteryNotLow(boolean batteryNotLow): Run a job only if the battery is not low. Usually, this is when the phone has more than 15% capacity.

• •

  setRequiresCharging(boolean requiresCharging): Run a job only when the device is charging.

• •

  setRequiresDeviceIdle(boolean requiresDeviceIdle): Run a job only if a device is not used and therefore in idle state.

See [4] for a complete overview of methods. An example of this approach was implemented in our open-source demo app [7]. This approach also works with the AlarmManager class, and the code is as well available in our git.

After we have set up the chain of jobs and start our foreground service, we can add methods to collect the user’s data. As shown in Listing 1 on Line 9, it is common for spyware to take camera pictures or to record the microphone audio. We have tested if our approach works with these features, and we implemented some examples in our demo app.

In Sections III-A to III-D we demonstrated just some examples of possible attacks. All of the common attacks are possible by using a combination of background and foreground services. Nevertheless, we want to discuss as well the limitations of our approach.

First of all, we tested our approach only on three Android devices²²2Samsung Galaxy S9+, Samsung A50, and Huawei P smart and some Android Oreo, Pie, and Android10 emulators. Since wide-scale testing is not feasible within this project, the foreground services may behave differently on other phones. Some vendors may have additional security measurements implemented, which can defeat or detect invisible foreground services. As far as we know, it works on all tested Android Oreo and Pie phones and as well on Android10 devices.

Second, we know that the access to some sensors is restricted to one app at a time: For example, if the user has already occupied the camera, a foreground service cannot access the camera for spying. Depending on the persistence strategy, this can occur more often than one may think and can attract the user’s attention. For example, if our spyware captures a picture and the user has FaceID activated, it can occur that FaceID cannot access the camera and show an error message.

Third, schedulers may not run at specific times: Android reschedule jobs and alarms, for example, when the device goes to the idle state. If our device is for a more extended period in stand-by, the schedulers will likely not execute our code until we use the device again. Furthermore, scheduling strategies can differ from device to device, and therefore the task execution can work correctly on one device but not on another.

Fourth, some vendors have different behavior for showing notifications. For example, the location icon on some phones is shown as soon as the user activates location tracking and is permanently visible in the top menu bar. Other vendors only show the location icon whenever an app accesses the phone’s location. So visibility for some features is different on some devices.

Fifth, if we choose a spying strategy that uses many phone resources, like taking a camera picture every 10 seconds, it is likely that the operating system’s battery optimizations will trigger. Depending on the phone vendor, it may show a notification to the user or directly stop the execution of our app.

Sixth, all the demonstrated malware features work only if the user has already installed the app and has given the app the necessary runtime permissions.

Our demo spyware shows that Android’s permission model cannot prevent excessive use of permissions and that the limitations do not prevent the collection of the user’s sensitive data. As we described, the access restriction in Android Pie cannot entirely prevent our access to the critical sensors like the camera over foreground services. We think the restrictions, in general, are a good idea and give the user more security, but it still lacks some fundamental points like restricting the file access. We can summarize what we have done in the following steps:

1. 1.

   Background Scheduling: We frequently spawn new jobs with a chain of JobScheduler or AlarmManager jobs. With every job we execute, we start a new short-lived foreground service.

2. 2.

   Invisible Foreground Service: As long as our foreground service’s execution time is shorter than five seconds³³3Five seconds it just the average. Timing may change on other phones., it will not display a notification. The operating system allows only foreground service to access critical sensors like cameras and microphones.

3. 3.

   Spying: We can use common spying techniques to collect data from the user during the five-second window. We tested taking camera pictures, recording audio, uploading files, or tracking the user’s location and other features. We have shown that our approach works as well on Android10.

Patching these issues is not as simple as it may seem. Since invisible foreground services only use standard API calls, which are unlikely to be removed soon. Therefore we think that such attacks are likely to be seen for a longer time. Even if a patch for the foreground service is released and the notification’s behavior changes, it seems that an attacker still has some possibilities for workarounds. Access and timings may get patched, but we think it will not entirely prevent such attacks since an attacker can still set the notification design. Attackers maybe will come up with custom notifications that do not look suspicious to the user.

I want to thank my professor Dr. Bernhard Tellenbach for encouraging me to publish this work. Moreover, I would like to thank the Zurich University of Applied Science for supporting my research on this topic.