Defending Against "Camera Peeking" Attacks

Yesterday, I blogged about a research paper describing various attacks. In yesterday’s post, I covered defending against another activity popping up and masquerading one of your critical activities.

Another attack outlined by the paper is easier for an attacker to use… but is also easier to defend against. The paper’s authors refer to it as the “camera peeking” attack.

A camera, as identified by an instance of android.hardware.Camera, can only be used by one app at a time. The attack is simple:

  • monitor for when an app that might use the camera for something important comes to the foreground

  • at that point, start watching for the Camera object to become unavailable

  • once the Camera is unavailable, then available again, grab the Camera and take a picture, in hopes that the camera is still pointing at the confidential information

The example cited by the paper’s authors is to watch for a banking app taking a photo of a check, to try to take another photo of the check to send to those who might use the information for various types of fraud.

Polling for camera availability is slow, simply because the primary way to see if the camera is available is to open() it, and that takes hundreds of milliseconds. The paper’s specific technique helped to minimize the polling, by knowing when the right activity was in the foreground and therefore the camera was probably already in use. Then, it would be a matter of polling until the camera is available again and taking a picture. Even without the paper’s specific attack techniques, this general attack is possible, and it would not surprise me if there are more efficient ways to see if the camera is in use.

On the other hand, the defense is simple: if your app is taking pictures, and those pictures may be of sensitive documents, ask the user to point the camera somewhere else before you release the Camera object. So long as you have exclusive control over the camera, nothing else can use it, including any attackers.

A sophisticated implementation of this might use image-recognition techniques to see, based upon preview frames plus the taken picture, if the camera is pointing somewhere else. For example, a banking app offering check-scanning might determine if the dominant color in the camera field significantly changes, as that would suggest that the camera is no longer pointed at a check, since checks are typically fairly monochromatic.

Or, just ask the user to point the camera somewhere else, then release the Camera object after some random number of seconds.

General-purpose camera apps might offer an “enhanced security” mode that does this sort of thing, but having that on by default might annoy the user trying to take pictures at the zoo, or at a sporting event. However, document-scanning apps might want to have this mode on by default, and check-scanning apps might simply always use this mode.

Aug 26, 2014


Defending Against Activityjack Attacks

A number of media outlets reported on a research paper and USENIX conference presentation describing a way by which your users could be tricked into providing confidential information — passwords, credit card information, and such — to a piece of malware, rather than to your app.

The paper points out that there are ways of writing malware such that:

  • the malware can pop an activity in front of yours, and

  • do so at just the right time, to mimic one of your activities, such that the user thinks that the malware’s activity is actually yours and enters the confidential data into the malware activity

For the purposes of this blog post, I’ll refer to this as an “activityjack” attack. Just as a clickjacking attack tricks Web users into clicking on the wrong things, and just as a tapjacking attack steals Android touch events via a transparent layer on top of the screen, an activityjack attack steals input destined for your activity by interposing another activity on top of yours.

The particular means of implementing the activityjack attack outlined in the paper is a bit esoteric. What it does do, though, is illustrate that such an attack is possible. Half the battle with security is knowing what you need to defend against.

The paper outlines solutions to their particular flavor of activityjack attack that require OS modifications. That’s fine, and perhaps the Android project will implement that stuff. But it will take years for such changes to percolate through the Android device ecosystem. For example, tapjacking was “solved” in Android 4.0, but there are millions of people using devices older than that, even today. Hence, we need to think as much, if not more, about application-level solutions.


Let’s ignore the details of the particular approach from the paper. Let’s merely assume that an attacker can get their activity in front of ours at the right time, as there are less-esoteric ways of doing the same thing (e.g., via an AccessibilityService). How do we defend against that for critical activities, such as “login” activities that require the user enter a passphrase?

An activityjack attack has two key weaknesses:

  1. The attacker cannot see the screen, because on non-buggy devices, the attacker has no means of capturing a screenshot of our activity as it comes into the foreground. Hence, while the attacker can create an activity that tries to mimic ours, they can only do so statically, analyzing our activity’s UI on their development machine and creating their own lookalike.

  2. We know that our activity has left the foreground, as we are called with onPause() (and perhaps other lifecycle methods, depending upon the nature of the attacker).

Hence, one defense can be to include in our activity a secure element that cannot be mimicked ahead of time, then hide that element (or our whole UI) when we are no longer in the foreground.

This concept of a secure element is not new. Some financial services Web sites have taken this approach. As part of the user setting up their online banking account, the user chooses an image from a collection of clipart. On the Web page that collects the user’s passphrase, the page also shows this secure element. The user is taught that if they do not see their chosen image, then the Web page they are looking at is not really from their bank, and therefore they should not type in their passphrase.

This is not that hard to implement in Android. You too would allow the user to choose a piece of clipart, displaying that in an ImageView on your secure activity in onResume(). In onPause() you would hide that ImageView via setVisibility(View.INVISIBLE). That way:

  • Since the image is chosen by the user, the attacker is unlikely to mimic the same image

  • Since you are hiding the image when you are not in the foreground, the attacker cannot use a transparent region in their activity to have your image “peek through” their attacking activity

As a result, if the user is paying attention, the user should see either the wrong image or no image at all, and the user should realize that they are being activityjacked and therefore fail to proceed.

You might be tempted to do something else in response to your secure activity being replaced in the foreground by another app’s activity, such as pop up a warning dialog. However, there are plenty of valid scenarios when this would occur, such as an incoming phone call, and you have no reliable means of whitelisting all possible valid scenarios. There will be a high incidence of false positives, and that may not help the user. Having this as an user-selectable option is fine, but I would not go this route by default.

With luck, somebody will come up with a better defense, one that makes it more likely that the user will not provide confidential information to the attacker, yet not be so onerous that they get fed up with your app and uninstall you. However, this approach should be reasonably easy to implement and help defend your users from activityjacking attacks in critical activities.

Aug 25, 2014


The Return of "Gradle for Android... and You!"

“Gradle for Android… and You!” is back!

Earlier this year, I offered a 30-minute free webinar on Gradle for Android: what it is and why it will be important for you, here in 2014 and beyond.

I am running “Gradle for Android… and You!” again in September and early October, with two changes:

  1. It is now a 45-minute webinar, getting into more about how Android Studio and Gradle for Android are related, how Gradle for Android relates to the larger Android development ecosystem, and more.

  2. To register, you need to make a donation to the Electronic Frontier Foundation. Proceeds from these webinars — minus Eventbrite processing fees — will be contributed to the EFF once the webinars are done. Eventbrite’s minimum donation is $1.

So, if you have been hearing about Gradle for Android and are trying to determine what it gives you and why you should be considering it, sign up for the webinar!

Note that this is not a deep technical dive into how to use Gradle for Android. Gradleware and I have an online training course for that, plus the material in my book on the subject.

Aug 20, 2014


Want to Review a Beta Book?

UPDATE: This program is now closed – thanks to all who responded!

Version 6.0 of The Busy Coder’s Guide to Android Development should be released around September 4th. At the suggestion of a subscriber, I am offering early access to a draft of the book to 10 active subscribers who are interested in reviewing the new Android Studio coverage. I should be delivering this draft late this week, so reviewers would have a bit over a week to examine the draft and provide any feedback.

Besides the cap of 10 reviewers, there are some limits on this program:

  • It is open to active subscribers only, not to former subscribers or the general public.

  • The draft will only be published in PDF form. In particular, I am testing smallpdf’s PDF compression service, which so far has worked remarkably well in reducing the PDF file size while not seeming to wreck images and whatnot.

  • I will offer a limited version of the Book Bug Bounty program, where any reviewer who reports bugs in the draft gets a six-month Warescription extension. The normal bounty program offers six months per emailed bug report, but as I will not have completed my own review of the changes by the time I deliver the draft, I am capping the bounty for the draft to one bounty per reviewer.

  • This is a one-time program, to help with the extensive changes going into this book update. If this program is a success, I may do it for future changes of similar scope, but there will be a fresh call for reviewers at that point.

  • I reserve the right to cancel the program, though I have no idea why I would.

If you are interested in reviewing the draft of Version 6.0 of my book, please send me an email, stating that you are interested in this program, along with your Warescription user ID. I will reply to let you know if you successfully qualified. I will update the blog post once I have 10 reviewers to indicate that the program is not accepting new candidates.

Thanks in advance to everyone who reviews the draft!

Aug 18, 2014


Intel's Android Developer Field Guide... And You!

A few weeks ago, I was recruited to provide some links as a starting point for the “Build” portion of Intel’s Android Developer Field Guide. In addition to the links I contributed for “Build”, Paul Blundell organized the “Ideate” area, Jason Mark covered the “Design” area, and Shen Ye brought up the “Launch” area.

In addition to the resources presently linked to from this site, Intel is interested in your input for other resources that should be considered for inclusion. On each area’s page — such as the “Build” page — there is a “Recommend a Resource” button to tweet the page’s organizer a link that you think belongs on that page.

Each organizer has his own criteria for what belongs there, beyond being relevant for the page’s topic area. In my case, my focus is on links to resources that are likely to be relevant for the next few years. Android evolves rather quickly, and so I’m trying to avoid links that are more prone to become stale too soon. Beyond that, I am looking for links to “quintessential” resources — the sorts of things that developers should not miss. And, I’m going to try to avoid too much overlap with what’s already there, as I do not know how many links Intel wants to have per page.

Intel will be seeking this input over the next few weeks. If you have a suggestion for any of the pages, click the button on the appropriate page on the Intel site. If you are not a Twitter user, or otherwise would prefer not to tweet your idea to the world, you can send me an email. I will try to remember to update this post when the window for recommendations has closed.

(and, yes, I know about the typo on link #15 — they’re working on it…)

Of course, definitely take a look at the resources that are already collected, as there may be ones that are new to you that could prove useful.

Aug 15, 2014


Older Posts