Tapjacking: An Untapped Threat in Android

Using social engineering tricks, a developer can create an app that tricks users into tapping a specifically-crafted app popup window (called toast view), making it a gateway for varied threats.This attack, dubbed tapjacking, takes advantage of a specific vulnerability in Android user interaction (UI) component.

This technique is not very complicated but has serious security implications to Android users.

But before we get into the details of tapjacking, let me explain briefly where this UI vulnerability is stemming from.

Introduction to app activity

Android displays UI elements in the unit of activities. An activity is a system component that takes up the whole screen size and can hold many different views, which is a rectangle area shown on the device’s screen.

Below is an example of an activity that contains two views namely (1) text view, which is where a user can encode a text and (2) button that a user clicks (or taps). As seen below, an activity may take up the whole screen even if a large part of it is empty (or black). Below is a screenshot* of an activity in the app WarGames:

An app has several activities with each activity representing a UI element that may consume the whole screen. The OS manages different activities using a data structure called stack, with the most recent activity shown on top of the stack while the older ones are situated below it. The currently displayed activity is always shown on top and is the only one that can respond to a user’s tap or swipe.

Most of the time, an app is designed to display a new activity to show a new UI screen that may take up the whole screen. But there are exceptions to this. In some instances, an application can show a view instead, without the need to put the view inside an activity. These exceptions are dialog view and toast view.

Difference between dialog view and toast view

The dialog view is mostly used for the application to interact with the user. It’s a two-way interaction: the dialog shows some information to the user and the user responds by encoding a text or clicking widgets like buttons. And because dialog view is shown temporarily, it is designed to be as small as possible so users can still see what’s behind it. Users also cannot interact with the activity behind the dialog.

With toast view, however, it gets more interesting. Toast, according to Android, provides “simple feedback about an operation in a small popup”. Usually, it only fills the amount of space required for the message and users can still interact with the activity behind it. Below is an example:

Depending on the app (and developer), a toast view may show a short information (as seen above). Its size, however, is not fixed. A developer has the freedom to design his app to show a larger toast view and can even include an image like this:

Now, this is the intriguing part. The ability to display any image inside the view can lead to many possibilities. Because a toast view simply passes a user’s tap or swipe to the activity behind it, a shady developer can then use a thought-provoking image (e.g. porn, celebrity pictures etc.) or a fake UI as a lure to prompt users into interacting with the hidden activity. This may lead users to various threats such as downloading malicious app, purchasing online, registering to premium services and even wiping the whole OS.

But there is a catch in using toast as bait. Toast views are typically designed to be brief and may only show within seconds. To effectively use a toast view in an attack, it should stay on the screen longer than just seconds.

Though a hurdle, this problem is not entirely a showstopper. To circumvent this limitation, a malicious developer can use timer. Timer is provided by the Android SDK to run a piece of code in a pre-defined period. By using timer the bad guy can use the timer to make it re-appear before it disappears onscreen.

Because a malicious app only uses tapjacking as a way to trick users and does not perform any malicious activity by itself, the app won’t need to acquire any permissions from the device. This can be a challenge to security researchers and AV products, as the app in question may do nothing more than just show these views and it will be difficult to tag apps as a malware by just static code analysis.

Based on our research, this threat affects all Android devices running on earlier versions of Gingerbread (those before ver. 2.3). Google offered a solution to developers to address this flaw, which is the ability for view to prevent interaction events when they are obscured by another view, thus eliminating the possibility of a user interacting with a hidden view.

However, this new feature can only be used in two ways either (1) by setting the filterTouchesWhenObscured property to true or (2) by implementing the onFilterTouchEventForSecurity method. It requires developers to explicitly modify their code and chances are, not every developer is aware of this. What’s more, users need to update both their OS and application to the latest versions to prevent this kind of attack.

In short, the threat of tapjacking is not out of the picture and may exist for quite some time.

*Screenshots used in this blog entry are not from malicious apps.

Post from: Trendlabs Security Intelligence Blog – by Trend Micro

Tapjacking: An Untapped Threat in Android