hijack android

Download Free Learn More

The Lookout Blog

December 9, 2010

LOOK-10-007 – TapJacking

[Release Date]: 12/6/2010

[Product]: Android All Versions. Fixed in Android >= 2.3
[Platform]: Android

[Effect]:
A malicious application can mislead a user into performing undesired actions on an Android device. The malicious application can be constructed so that there is no user indication that the undesired actions being taken, all of the actions taking place in the background. Some undesired actions that can be performed by exploiting the TapJacking vulnerability include changing security settings, installing malicious applications or performing a full device wipe.

[Details]:
The Android trust model allows an application to open a dialog (e.g. change settings, install home-screen widget) to allow a user to take action that the application itself is not allowed to directly perform. The application is permitted to programmatically open the dialog but cannot directly interact with it, preventing a privilege escalation attack. Under normal circumstances, an application might open a settings dialog to allow a user to easily change a setting that the application requires to function correctly.

A malicious application that exploits the TapJacking vulnerability may open a privileged dialog (such as the device wipe dialog) and obscure the dialog with an opaque visual layer that passes touch events to lower layers. The malicious application may use the opaque topmost layer to encourage a user to touch certain parts of the screen in order to mislead the user into performing an undesired action. While the user believes that he or she is interacting with that application shown in the topmost layer, the touch events are passed through to a visually hidden layer below.

Ordinary Android dialogs (Activities) do not allow touch events to be passed through; however, a special class of dialogs, called Toasts, overlay the current activity while passing touch events to lower layers. Toasts are meant to communicate short messages to the user and then to fade away. Although toasts are typically very small and distinct from activities, they can be customized so to fill the entire screen with a custom user interface.

A malicious application implementing TapJacking may launch an Activity asking the user to tap certain portions of the screen (perhaps as part of a game) and, just before the user taps that part of the screen, initiate a full-screen Toast notification that looks identical to the Activity. While the Toast is in the foreground, the application can close its original Activity, and launch a privileged Activity that receives touch events but is hidden from view because of the Toast. The Toast may encourage the user to touch a portion of the screen that maps to a protected action on the newly launched Activity.

When the toast notification disappears, after 3.5 seconds, the application’s original Activity can be brought to the foreground, so that when the Toast fades out there is no visual change perceived by the user: the Toast fades to a visually-identical Activity. Immediately, the Toast can be redisplayed, the original Activity can be hidden, and the privileged Activity can be brought to the front (yet still obscured by the Toast). In practice, this allows about 3 seconds worth of misdirected touch events for every 4 seconds that the user is interacting with the application.

The TapJacking attack could cause the user to perform any function that requires a few keypresses or taps, such as performing a factory reset on the device, installing an application, or sending a text message to authorize charges to the user’s bill (without any permissions to do so). The attack could also encourage a user to type a word or move the trackball.

An example attack might involve a “whack-a-mole” game that passes the touches through to the Application Settings Activity, tricking the user into tapping the “Unknown sources” setting, and then tricking them into tapping the “OK” button on the notification that pops up warning them about the dangers of enabling the setting. Meanwhile the application can poll for the status of the “Unknown sources” setting and revert itself into a normal state (back to an actual whack-a-mole activity) when the setting has been enabled. The “Unknown sources” setting is a secure setting that non-system applications cannot modify; this attack would allow a malicious application to effectively modify this setting without elevated permissions.

[Recommendations]:
Android 2.3 (Gingerbread) added the ability for Views to prevent interaction events when they are obscured by another View. A new property was added to the View class: filterTouchesWhenObscured. This can either be set to true in the XML layout, or passing true to the new method setFilterTouchesWhenObscured. 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) {
        super.onCreate(bundle);

        final Button myButton = (Button)findViewById(R.id.button_id);
        myButton.setFilterTouchesWhenObscured(true);

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

Setting filterTouchesWhenObscured in a layout:

    android:layout_height="wrap_content"
    android:layout_width="wrap_content"
    android:text="@string/self_destruct"
    android:onClick="selfDestruct"
    android:filterTouchesWhenObscured="true" />

[Acknowledgment]:
David Richardson of Lookout
Thanks to the Android Security Team

[Timeline]:
10/26/09 Discovery
5/21/10 Disclosure
12/06/10 Fix Deployed

[Contact]:
Lookout Mobile Security
[e-mail]