Scary Android Malware Story

This story sounds pretty scary:

Developed by Robert Templeman at the Naval Surface Warfare Center in Indiana and a few buddies from Indiana University, PlaceRader hijacks your phone’s camera and takes a series of secret photographs, recording the time, and the phone’s orientation and location with each shot. Using that information, it can reliably build a 3D model of your home or office, and let cyber-intruders comb it for personal information like passwords on sticky notes, bank statements laying out on the coffee table, or anything else you might have lying around that could wind up the target of a raid on a later date.

It’s just a demo, of course. but it’s easy to imagine what this could mean in the hands of criminals.

Yes, I get that this is bad. But it seems to be a mashup of two things. One, the increasing technical capability to stitch together a series of photographs into a three-dimensional model. And two, an Android bug that allows someone to remotely and surreptitiously take pictures and then upload them. The first thing isn’t a problem, and it isn’t going away. The second is bad, irrespective of what else is going on.

EDITED TO ADD (10/1): I mistakenly wrote this up as an iPhone story. It’s about the Android phone. Apologies.

Tags: , , , , ,

Posted on October 1, 2012 at 6:52 AM • 46 Comments

Comments

Ian McDowall • October 1, 2012 7:01 AM

Actually, the story describes it as an Android app, not an iPhone one. I don’t think that the difference is important because the same approach would probably work on any smartphone but I’m amused that any app is assumed to run on an iPhone.

Michael • October 1, 2012 7:02 AM

iPhone != Android.

Android can run background tasks, iPhone cannot. There is the difference. A benefit of one platform turned against the user. Not a but thou.

John • October 1, 2012 7:03 AM

@bruce Out of interest, why did you headline with iPhone, but not Android or Windows Phone? The article, and the one it links to, say that it’s an Android app.

The only place iOS (or Windows Phone) is mentioned is in the quote: “We implemented on Android for practical reasons, but we expect such malware to generalize to other platforms such as iOS and Windows Phone,”

I’d be a little less optimistic than he is that that iOS and Windows Phone stacks (including Stores) will be as vulnerable.

Ian McDowall • October 1, 2012 7:08 AM

The security problem isn’t a bug but a feature of the smartphone app permissions model. Consider a trojan that claims to be a gallery app (or similar). The user therefore gives it permission to operate the camera and to upload data. These are legitimate privileges for such an app. Then the app mis-uses them.
How would you propose to prevent this? If you block the privileges then legitimate apps are blocked. We have continually seen smartphone security as a conflict between security and convenience whereby users want ease of use and don’t want to worry about security until things go wrong.
Maybe all the apps could be screened? But this gives a lot of control to the screener and prevents an open market.
In this case, maybe a limit could be set on the amount of data transferred or the frequency of pictures but neither of these would block a trojan that wanted to collect keylogging-based info and upload that.
Sorry if this is a bit of a wandering comment but the interaction of privileges and trojans is a hard problem to solve.

Juergen • October 1, 2012 7:10 AM

iPhones CAN nowadays run background tasks. It’s discouraged by Apple AFAIK, but the OS itself can handle it.

The key issue is getting root access on the iPhone to install the software – you can either ask Apple for help (they were kind enough to hand Gamma International the certificates needed to install FinFisher…), or you use one of the exploits used for “untethered jailbreaks” – which basically are nothing more than malware pages installing rootkits, albeit on the request of the user.

How’s this for a scary scenario… the NSA starts a webpage offering iPhone jailbreaks – and installs trojans on every iPhone they can get their hands on? 😉

Kai Howells • October 1, 2012 7:12 AM

I won’t weigh in on the iOS vs Android aspect of this, but I will say that even if someone did get it to run in the background on my iPhone, all they’d be getting when I’m at home is a heap of shots of the inside of my jeans pockets, and then an extreme close-up of my desk when I put it down (face up, so camera-down) at the end of the day… The data they’d be possibly able to get from GPS would be nowhere near granular enough to map most houses.

Bruce Schneier • October 1, 2012 7:12 AM

Oops. I mistakenly wrote this up as an iPhone story. Thank you everyone for catching the mistake. It’s fixed above, even though the mistake still lives on in the URL.

Jonathan • October 1, 2012 7:13 AM

The “cyber-intruder” would most likely get a really good 3D model of the target’s pocket or handbag, limiting the booty to lint.

Nevertheless, a lens cap sounds like a good idea. Also, that’s why smartphones issued to some military-related companies’ employees have their cameras physically removed.

Juergen • October 1, 2012 7:15 AM

@Kai Howells Technically, they could be using BOTH cameras at the same time – so they’d get lots of shots of your ceiling, too

zombie tropes must die • October 1, 2012 7:36 AM

@michael, @Juergen, iOS (and iPhone OS before that) could always run background tasks. It is based on Mac OS X, which is a variant of BSD UNIX. What you could not do before iOS 4 was have third-party applications continue to run in the background (unless the device was jailbroken). Now, with some restrictions, they can.

Olivier • October 1, 2012 7:39 AM

good 3D model of the target’s pocket if the capture is take when you are in communication, it’s probably work. Much people are walking in circle when there are in phone communication.

Otto • October 1, 2012 7:43 AM

Reading the article, it doesn’t appear to be exploiting any “bug” of any sort, it’s just a malware application proof-of-concept. Presumably, when you installed it on the phone, Android’s permissions model would tell you that it runs in the background and can access the camera and can access the internet and so on. You’d have to give the permission for it to be able to do any of these things, else it would not be installed at all. And given the permission model, if it was installed without those permissions being granted, then it wouldn’t be able to do those things at all.

So, somebody wrote a clever app to take pics and send them to a server, then another server program to stitch them together. A good demo of what is possible, but not necessarily a security issue in the existing models.

Otto • October 1, 2012 7:47 AM

Note that there would be a security issue if this were placed unsuspectingly into, say, a camera application. Take Instagram, for example. It’s designed to take pictures and upload them to the internet. So naturally, you’d grant it just that permission. Twitter apps ask for those permissions also, and some of them run in the background as well. So if something like this was inserted into one of those apps, then the user would be unsuspectingly sending photos of everything somewhere.

I can think of no realistic model to fix this, however. If you do something very similar to what you actually claim to do, then there’s not a lot of technical difference there to base a permissions system on.

tz • October 1, 2012 8:09 AM

Put a piece of tape or post it or something over the camera lens.

Also run a firewall.

I would find a legit app that does this for my own use to be very useful.

You can have all kinds of nasty malware, but getting it on the machine and it having access should be harder.

Why is this worse than something that logs keystrokes? Most people are typing passwords on the soft-keyboards. Or simply allows taking over and using the saved credentials?

Scary. But I think people fear the wrong things.

Patrick • October 1, 2012 8:13 AM

Oh come-on you bunch of “specialist”. It. Does not seem to exist among u one single iOS developer? Neither someone who care on reading Apple’s guideliness?

Today an iPhone App can do minor background tasks and use only one sensible hardware while on this mode. An iPhone app will never use the camera, the giro, accel at a single app on background and for the apps that will use sensible hw except for GPS they have a limited time to the resource while in bg.

Therefore such a malware on iOS shall run on foreground or on a jailbroken device. Which is stupidity of the user for both scenarios if one is concerned with security.

So please dont make such an assumption. Android itself was not a victim for this malware. Its a school homework. A PoC. Google Play is terrible at evaluating what is a malware and what is not but they did not allow for it yet.

I am not sure if this can b abused on Windows Phone as it does on Android but I will not make Any assumptions before a single small research.

When you comment on a blog like this one people tend to believe u know what ur saying. Só please try to know.

BTW this PoC was probably tested on iPhone too.

It would make much more noise for the University and navy and The students. After all criticizing and exploring Apple security tend to make u more notable than a conceptual malware for a System with more than a couple thousand malwares on the first quarter of the current yr.

wiredog • October 1, 2012 8:53 AM

Right now this app would be getting lots of good shots of the chair I’m sitting in. It’d get good waist level views of the office if I was walking around.

At home it would get awesome views of the counter I lay the phone down on when I’m not wearing it.

paul • October 1, 2012 8:59 AM

Just a note for all the people who think you’d be taking pictures of the inside of stuff. Remember that smartphone cameras and software are already good enough to measure users’ pulse rates. “Am I in a pocket?” would be a piece of cake. Also: apps can have access to phone state and bluetooth state, so knowing when you’re by the user’s face is easy.

A little social engineering, and zap.

hashbroken • October 1, 2012 9:01 AM

Patrick,

Good clarification.

In fact unless you run on an enterprise account, and you do a number of tricky workarounds to fool iOS controls, Camera can never be run on background.

Every assumption contrary is wrong.

Adam • October 1, 2012 9:05 AM

If you’re really paranoid about the camera, stick the phone in some kind of case and ensure it’s covered up. Cyanogenmod also permits you to explicitly revoke permissions from apps that want access to your camera.

If one were technically inclined other options would present themselves too.

I really don’t expect this attack would be very effective. Phones tend to be laid down on tables (with the camera on the back) they’re not likely to gain much from capturing data. I think I’d be more concerned that the phone was connected via wifi to the same network as other devices in the household and what risks that might pose.

Winter • October 1, 2012 9:16 AM

Why should a background task have access to the camera? I really see no reason it should.

A case could be made that you want to record audio while the phone is on standby. But even then this could be made so it required a separate user action to achieve.

So, a simple addition to require specific user action for any background task accessing camera or microphone would solve most of these problems.

alanm • October 1, 2012 9:32 AM

Phone at rest/in pocket isn’t a barrier, it’d be easy to watch the gyro, detect when it’s picked up, and snap a shot then. I doubt the sampling model is as simplistic as just “take a photo every x minutes”.

Even shots of desk tops and pocket insides are useful because they contain GPS data. They’ll know where you like to leave your phone and where you walk around, probably your average bed time and other habits. Use your imagination.

Use your imagination guys.

Malachi J • October 1, 2012 9:35 AM

@Winter

“Why should some_person_entity have access to ____something____?”

This question is what leads to needlessly locking down something because someone isn’t able to see other possible future use cases.

Boss: Why should anyone have access to websites that are not on the pre-approved whitelist?

Developer: The answer to that bug in the software is on this tech forum that I can’t access.

derp • October 1, 2012 10:24 AM

Custom build android from source and add in SEandroid this and all other malware becomes useless.

Brad Templeton • October 1, 2012 11:33 AM

This isn’t really an Android story or an iPhone story, and it does not describe, as you write, an Android bug which lets an intruder take pictures and upload them.

The story is entirely about the stitching app, no bug is exploited. They wrote an app to which they gave camera permissions as a demonstration of what can be done if an app has camera permissions.

Perhaps this is an argument that camera permissions should not allow taking photos while in background mode. This would block out various webcam apps and yes, spy camera apps where you use your own phone as an unobtrusive recording device.

And there is the security conundrum. We want the security to be more fine grained, so that “take a picture manually with the OS’s UI” is one level of permission, and “take a picture with your own UI, and thus no UI” is a higher level of permission. But every nuance that goes into permission lists just causes people to approve permissions lists without reading them. So what’s the right answer?

Francos • October 1, 2012 12:08 PM

Interesting. I just saw an iphone that had a thin rubber sleeve-type cover on it. The cover was deliberately put on upside-down – thus putting the camera cutout towards the bottom, and completely covering the lens. This thought crossed my mind.

As always, low-tech ingenuity beats high-tech engineering.

RH • October 1, 2012 12:10 PM

Of course, you have to read between the lines. For a Navy Security lab to have an effect on the social world, it has to word things to appeal to the average person.

For those who are security conscious, like all viewers of this blog, consider the security implications for a large corporation full of such malware infected phones, stitching together their 3d world in unison. In those cases, does it even matter if the “useful picture rate” dips below 1%?

Roman • October 1, 2012 12:23 PM

N900 had the right idea with hardware camera hatch. It does two things: protects the lens and protects you from any accidental or malicious photographs being taken.

Figureitout • October 1, 2012 12:29 PM

Much people are walking in circle when there are in phone communication.
–Great point @Olivier, easily enables panoramic view.

Paper here: http://arxiv.org/pdf/1209.5982v1.pdf

This is why I have so many papers and troll un’s & pw’s lying around; so a physical raid would be necessary to get them.

(any relation to RobertT?) From paper: A desired capability might include autonomous identification and extraction of sensitive data.–I’ve heard of such tech. already existing, some billionaire’s developing it; reading text off papers/surfaces.

I wasn’t impressed w/ defense recommendations.

One of the reasons my smartphone became an alarm clock was b/c of all the permissions every app needed, even an f’n flashlight app. Others should switch back, I’ve been smartphone-free for ~10 months; you’re just exposing yourself to attacks of all kinds.

Might I also add that isn’t it funny there’s a NAVAL warfare center in a landlocked place and that they are creating malware; figures.

atis • October 1, 2012 1:18 PM

@Winter I have two perfectly valid examples of background camera usage.

First – Android’s built-in “viewing detection”, that detects if you’re actually looking at phone’s screen in order to turn it off or keep it on (once per minute).

Second – Car black box app (DVR), I have chosen one that allows background recording, so I can open Navigation app in foreground.

However I would look totally suspicious at any app that requires network access in combination with any of my privacy (phonebook, sms, camera).

Mr. Finch • October 1, 2012 2:05 PM

I don’t own a smartphone, but most of the TV commercials tell me that if I did, I’d instantly turn into a super-muscular, chick-attracting android with laser beam eyes in a shiny metallic superhero suit, so if this app turned out to be bad, I could probably just destroy it with my mind. Or maybe run it over with one of those rice rockets that leaves a trail of pink neon light. Enjoy your tracking device, chump.

Neddy • October 1, 2012 4:10 PM

Yeah, and what happens when some jacker turns your phone-camera into an x-ray machine — like the ones the TSA uses to create their photo albums?

I guess into each life some rain must fall.

Clive Robinson • October 1, 2012 4:15 PM

@ Bruce Schneier,

The first thing isn’t a problem and it isn’t going away. The second is bad

That depends on your view point in any specific case. This is because all of this technology is basicaly a “tool” and “all tools are agnositc to use” it’s the human who decides Good/bad in a case by case bases and usually in a quite arbitrary fashion.

For example,

In the UK we have in effect made it illegal for people to carry any kind of knife that is of any real use (ie blade has to be less than four inches and non-locking) unless it’s in a “toolkit” (due to EU legislation about restricting trade).

Such a legal “pocket knife” would, because the blade cannot be locked, be dangerous to use if you tried to do anything over and above what a pair of sensible scissors could more easily do.

But… it appears to be perfectly legal to carry scissors with razor sharp edges and blades of any length. And as various accident statistics have showen there are actually more injuries from scissors than knives. And yes people have been killed by a person wielding scissors as a weapon.

The point is any tool can be used for good or bad, and trying to force the use of a tool to an idea of “good” only just won’t work.

The real issue is that for most tools people can see them “in use” and will usually take appropriate action if they think the use is inappropriate. Not so for “Hi Tec” such as smart phones, thus what is needed is a clear and un bypassable (by software) way to indicate that the camera is in use and the last time it was used and by which application.

But as the “last time” and “which app” are recorded by the OS which can be fritzed in one way or another this won’t be at all reliable. Thus it realy does need an “external cover” over the camera lens, which also preferably cuts the power to the camera as well.

FOK • October 2, 2012 1:47 AM

Why it has to be malware? First of all when the phone is in rest, it doesn’t take pictures, because it knows they will not provide any new information. Second, try to imagine some spy who wants to map some place. He just receives fake call. And in one quick round he gets hi res pictures to be assembled later. Yes, he can take video footage, but still pictures have more pixels and thus more information in it.
BTW: This could also be used in friendly manner to take a panorama I guess.

Autolykos • October 2, 2012 5:12 AM

@Roman: Yep, a hardware solution is the way to go. I was thinking “duct tape”, but including it in the design is the cleaner solution.
It’s just the same way an air gap is better than any amount of firewalls you can pile on your network (if you can afford to have parts of the system offline).
If you don’t want a device to do something, make it physically impossible. You won’t have to worry about it ever again.

vasiliy pupkin • October 3, 2012 10:14 AM

@Clive
“thus what is needed is a clear and un bypassable (by software) way to indicate that the camera is in use”.
Per my recent posting in this blog regarding secretly activation mic on landline phone when handset is in a cradle, activation required electricity passing through particular circuit. If LED is added to that circuit, it will turn on whenever mic is active, but handset is in a cradle as if phone is diconnected out of line.
Same idea could be easily applied to smartphone mic and camera, but that should be hardware solution by manufacturer design who really respects privacy of its customers and does not want to get ‘1984’-type award for bad privacy protection.

Figureitout • October 3, 2012 11:54 AM

If LED is added to that circuit, it will turn on whenever mic is active
@vasiliy pupkin
Regarding landline phones, you’re saying there should be separate LED’s for when it’s “charging in the cradle” and when microphone is active? Of course that solution can be bypassed w/ physical access to phone aka warrantless search of your residence; so maybe you need to test for tampering occasionally. I’ve only recently had my eyes opened to the mind shattering world of electricity. I found an old transitor (from 1964!) project book and hope to get going on some here shortly.

that should be hardware solution by manufacturer design who really respects privacy of its customers
–Let’s assume they all don’t 🙂 Have you ever tried manipulating circuits w/in modern electronics? Like say a smart phone. Or do we need access to some expensive facilities to get this done. I want a phone w/ no camera and LED for mike; I’m sure there’s many others, we need to make it economically profitable.

Jose • October 3, 2012 3:02 PM

That is criminal terrorism, not to confuse with the lye of patriot act…. Being smart is one better choice and bed…

Virginia • October 4, 2012 1:08 AM

Wouldn’t it be just as easy to look up old real estate photos and figure out the floor plan from those? We act like knowing someone’s floor plan is a big deal. Plus, it is not super hard to guess where papers are kept once you are inside…

Clive Robinson • October 4, 2012 7:46 AM

@ Vasiliy Pupkin,

If LED electricity passing through particular circuit. If LED is added to that circuit, it will turn on whenever mic is active…

There are a couple of issues with LED’s as noted by Figureitout they can be “fritzed” in some way.

The second is that they have quite a high forward drop voltage (around 1.2V on many common LED’s) whilst their reverse breakdown voltage is corespondingly very low (some around 7V), They also tend to make lots of noise which gets superimposed on the relativly high current that passes through them.

These deficiencies tend to make LED’s a bit of a pain to use when you are trying to “design them into” as opposed to around a circuit block.

The usual way is to drive them in battery powered units is with an issolated constant current driver which is actually not integrated into the circuit you would want monitored at all. At best it might have an easily spoofable hardware interface at worst some compleatly unrelated “driven by software” circuit hung off a latched or even multiplexed CPU port pin.

Actually integrating a “fail safe” indicator into a mic or camera circuit block is very difficult to do reliably, for a whole heap of reasons. Not the least being the use of plastic “light pipes” between the LED on the PCB and the external surface of the case. These can in many cases be fairly easily modified by someone with even quite short term physical access (say 10-20mins) to the device.

I’ve actually changed LEDs on some mobile phones where the owner did not like the standard red or green and wanted purple (as you will see in some X-Box controler mods) and electric blue. I’ve also quite a bit of experiance use LEDs in one form or another (including turning them down in lathes) to make lights for OO / HO / N gauge model railway engines and carriages. All though it sounds fancy a “light pipe” is little more than a plasitc extrusion that the light travels down like an optical fibre, cutting and splicing these although fiddley is not difficult it just takes a little practice and patience.

The best ever mobile phone “anti spy” device I ever saw was those replacment antennas with a light in them that lit up every time the handset transmitted. Sadly due to the fact some caused harmonic distortion and thus sprogs they have now been ddeclared (in Europe at leasst) illegal to sell.

vasiliy pupkin • October 4, 2012 3:49 PM

@Figureitout.
That was related to old landline (not wireless) phones. Those old ones do not charge handset whet it is in cradle – just for clarification and thank you for your comment.
@Clive.
Thank you for your input related to LED.
May be some nano technology application could be utilized rather than LED in a future. The general idea is that detector of activation should be triggered by current passing through mic or camera, and you are right detector should not interfere with other vital functions.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.