The CommonsBlog

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 developers 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.

Need a speaker at your Android development meetup? Mark Murphy is available, in person in the Boston/Pittsburgh/DC triangle, or by remote anywhere in the world! Contact Mark for details!