December 9, 2010

Android Touch-Event Hijacking

With the recent release of Android 2.3 (Gingerbread), developers can now protect themselves from a new twist on an old bug: TapJacking. Like ClickJacking on the web, TapJacking occurs when a malicious application displays a fake user interface that seems like it can be interacted with, but actually passes interaction events such as finger taps to a hidden user interface behind it. Using this technique, an attacker could potentially trick a user into making purchases, clicking on ads, installing an application, granting permissions, or even wiping all of the data from their phone.

Earlier this year we contacted the Android Security Team at Google about the issue and they were able to build a fix into Android 2.3 (Gingerbread). In Android, an attacker is able to display the fake user interface by creating a customized notification (called a Toast) to obscure the real interface. To allow developers to protect their user interfaces from TapJacking, Android 2.3 added the ability for Views to prevent interaction events when they are obscured by another view. Essentially, this makes a View only usable when it is visible, eliminating the possibility for a user to accidentally interact with a hidden View. The new feature for View objects can be used in two ways: by setting the filterTouchesWhenObscured property to true or by implementing the onFilterTouchEventForSecurity method. It’s important to remember that the new security features require developers to explicitly set them to protect from TapJacking.

How TapJacking works:
On Android, transient notifications are called Toasts and are usually used to pop-up a short message on the surface of a window (similar to Growl notifications on OS X). Toast notifications pass touch events through to whatever UI is below, because developers ordinarily don’t want them to interfere with the functionality of an app. Simple Toast notifications don’t pose much of a risk because they only take up a small part of the screen; however, Toasts are also customizable with layouts just like standard Android UI screens (Activities). A malicious developer can customize a Toast to take over the whole screen and seem like a standard Activity. When creating a full screen Toast, an attacker can use a variety of techniques to trick a user to click a portion of the screen that corresponds to a button or other view on the hidden Activity below. For example, an attacker can ask a user to push a button on the screen to purportedly start a game, the button being in the same position on the screen as a settings checkbox so that when the user presses the button, the touch event toggles the hidden checkbox. Of course, there are a variety of other potential attacks.

Because Toasts only have a 3.5 second lifespan, a TapJacker needs to choreograph a delicate dance to make sure a user always sees the fake UI and not the targeted UI. In our research, we found that it is possible to repeatedly launch Toasts, but there was a brief period of time between the ending of one Toast and the beginning of another Toast where the target Activity underneath was visible. In order to never display the target UI, we found it possible to display a legitimate Activity having the same View as the malicious Toasts during the brief period of time between one Toast ending and another launching. After the next Toast finishes launching, the Activity with the same View as the Toasts is hidden and the target Activity is at the top of the stack, ready to receive user input even though the user cannot see it. The net effect: a user never sees the target Activity. Using this kind technique, an attacker could potentially trick the user into installing an application, granting permissions, or perhaps even wiping their phone of all data.

Proof of Concept

Advisory: LOOK-10-007 – TapJacking

How to protect your app:
If you develop apps for Android, you should make sure that you use some form of TapJacking protection available in the Android SDK for all of you sensitive View elements. Because the protection mechanisms affect individual View elements, you’ll need to explicitly protect each sensitive View element. Usually, you’ll want to either call the setFilterTouchesWhenObserved method or set the android:filterTouchesWhenObscured property in your layout XML to true. For more fine-grained control, you can override the onFilterTouchEventForSecurity method on a View subclass and discard specific MotionEvents to your liking. Remember that these protection mechanisms will also prevent View elements from receiving interaction events when standard toasts are displayed, so be careful where you use these protection mechanisms.

Calling setFilterTouchesWhenObscured:
public class MyActivity extends Activity {
    protected void onCreate(Bundle bundle) {

        final Button myButton = (Button)findViewById(;

        myButton.setOnClickListener(new View.OnClickListener() {
            // Perform action on click

Setting filterTouchesWhenObscured in a layout:
    android:filterTouchesWhenObscured="true" />

Thanks to the Android Security Team and everyone else who helped get this vulnerability fixed (you know who you are).

  1. Awesome discovery. Keep up the good work.

  2. Durgesh says:

    This is very useful. Consumers are losing trust in mobile apps and someone needs to step into to restore their confidence.


  3. James Hudon says:

    This article is outdated now, I believe. Commonsware reports that Android 4.0.3+ protects against tapjacking ( Can you confirm/deny?

Leave a comment