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.

Read the rest of this entry »

The permissions in Android devices are designed to guarantee that those Android apps without any declared permissions cannot do anything harmful to the mobile device. Or can they?

How Android Permissions Work

Before we get into the details, let’s see how Android permissions work.

An Android app can access limited system resources. To access sensitive APIs, the app must declare permissions required in AndroidManiflest.XML file. These sensitive APIs include camera function, location data (GPS), Bluetooth and telephony functions, SMS/MMS functions and network/data connections.

Once an app is installed, the App Installer shows the declared permissions to the user who either accepts or refuses them.

If a user chooses to grant the permissions, these are applied to the app so long as it is installed. During runtime, the system will no longer notify the user when sensitive APIs are being accessed again. Declining these permissions, on the other hand, aborts the app installation.

Once an app attempts to use a protected feature but failed to declare the required permission, the runtime system typically throws a security exception, which then terminates the app.

Given these facts, it appears that the chances of bypassing permissions is slim. Unfortunately, some crafty developers may create apps that can circumvent permissions by abusing the following.
Read the rest of this entry »