26 May, 2011

Revisiting Android TapJacking

by Ken Johnson



Although we probably didn’t need another *jacking vulnerabillity, TapJacking is a relatively easy vulnerability for a malicious application to leverage in Android prior to version 2.3 (Gingerbread).  To be clear, we did not discover this attack vector.  For the initial disclosure and a good writeup, please reference the Lookout Bloghttp: blog.mylookout.com="" look-10-007-tapjacking="".  We are revisiting this issue to raise awareness and provide developers with a friendly reminder that they are still on the hook to defend against this in their applications.  Although 2.3 provides the ability to protect against this, it is not enabled by default.

What TapJacking allows a malicious application to do is overlay the Activity at the top of the stack with another object (ie- Toast) that passes touch events through to the Activity.  The result is that the user has no clue what they are really clicking on or typing into because it is hidden from view yet still accessible.  So while a user may be tapping to install new paid applications, transferring funds, or dialing expensive numbers overseas, they are still happily clicking away at whatever they see.  The illustration below demonstrates how a Toast object would overlay an Activity:

We wrote a proof of concept application that you can install to your phone or Android virtual device in order to see how the attack works.  You can find it in the Android Market ( https://market.android.com/details?id=com.nvisium.tapjacking).  The proof of concept application can also be used to perform security testing to ensure your anti-TapJacking defenses are working properly.  You can download it directly to your phone from the Android Market <download .apk=”” android=”” compiled=”” from=”” market=”” the=””>, or you can pull down the Eclipse project from GitHub and build it yourself (https://github.com/nVisiumSecurity/TapJacking-Demo). You can easily modify this application to test it against your own applications by modifying the package and class names that are launched by the background services.  You can also modify the offsets within the layouts to determine where icons and buttons will be placed within the Toast overlay.

Another interesting thing to take note of is the fact that our sample application requires zero permissions.  Permissions in Android get a lot of attention, and therefore we’ve begun to train our users to make some of their security decisions based on the types of permissions an application requests.  If a wallpaper application requests SEND_SMS, CALL_PHONE, ACCESS_COARSE_LOCATION, and other sensitive rights, it will hopefully make someone very suspicious.  However, a wallpaper application that makes use of TapJacking could fly a bit further under the radar.  The applications that are being granted the sensitive rights could be installed silently in the background instead, achieving the same effect and with less risk of detection.

The good news: there is a relatively simple fix: in the 2.3 SDK and above, subclasses of the View class inherit the setFilterTouchesWhenObscured method.  You set this on your View derived object and it prevents interaction when something else is on top of it.  This can be called either through code or declared within your resource and layout XML files.  Any sensitive functionality such as purchasing, account modification, or changing a user’s settings should be protected.  So assuming you create a button within a layout file instead of within code, you would create it like so:

<Button android:text=”Button” 




android:filterTouchesWhenObscured=** "true"**>


That’s  it.  Simple.  Easy.  Even though your Activity may be at the top of the stack, if there is anything obscuring it from view Android will disallow interaction with it.  For most applications, this should not be an issue.

The bad news: this is not enabled by default (as it hopefully will be at some point).  It also means your users with pre-2.3 devices aren’t protected, either.  According to Google’s own numbers ( http://developer.android.com/resources/dashboard/platform-versions.html), close to 96% of the Android ecosystem is still using 2.2 and below.  Since many older phones are no longer receiving updates and will never see an official Gingerbread release, this issue will be around for a while.  So it's up to developers to implement this on their own.  Hopefully as a larger percentage of devices begin to use 2.3, Google will consider enabling this by default.

From the people we've talked to that specialize in mobile malware and forensics, this technique has not been used much in the wild.  However, as Android malware continues to grow at an alarming pace, it is only a matter of time before we may see this used.  Combine that with a growing number of applications using in-app billing, and the use cases expand even more.  We also hope that Google will begin to make use of their own security features in future releases of their own packages, such as settings, dialer, and market applications.