Boffins: We have FOOLED APPLE with malware app

Researchers from Georgia Tech's Information Security Center (GTISC) claim to have found a way to sneak a malware-ridden app through Apple's inspection regime, and have also raised concerns about “malicious chargers” for iPhones. The GTISC team explains its research here and claim to have created an app “which rearranges its …

[Anonymous Coward]

Now in the real world ..

"The Reg imagines that anyone plugging their high-fructose phone into a charger and finding that message would take a second, and far closer, look at their source of electrons before proceeding."

Your imagination is extravagant. What will really happen is that said phone user will do a brief wtf? Then take a snap of the message and post it on instagram with a comment something lik 'aple thnks charger iz putr lol'

[returnmyjedi]

Or they'll just click "yes" without checking.

[Destroy All Monsters]

Re: Now in the real world ..

'aple thnks charger iz putr lol'

Apple users talk like Dolan Duck?

[Byz]

Objective-C runtime

"which rearranges its own code to create new functionality"

This is part of Objective-C runtime and has been part of the language since it was invented by Brad Cox in the 1980's (part of the legacy from smalltalk). Anyone who has an understanding of the language knows that you can define a new class at runtime and then insatiate it.

As usual this comes down to testing things to breaking point, if the person doing the testing doesn't do a good job then things will slip through (I've got friends who have apps on the App Store that break the guidelines because the reviewer never checked them properly).

People are the weak link in IT security always have been always will be.

[A K Stiles]

Re: Objective-C runtime

slightly OT and I realise you meant 'instantiate' (at least I think that's what you meant), but I'm now quite intrigued by the concept of a class being 'insatiated' - perhaps it needs to be struck by lightning then attempts to absorb the entire contents of wikipedia, AND check all the cross-references. (©1986, Tristar Pictures)

[M Gale]

Re: Objective-C runtime

The entire contents of Wikipedia?

Damn, that movie could have ended SO differently if it was made just a decade or two later. "Input", indeed.

[Simon Harris]

Re: Objective-C runtime

... or possibly dowload all the songs from the web (©2005, Columbia Pictures)

[Stuart Castle]

Re: Objective-C runtime

Indeed.. You can have the most secure system on the planet. A computer system whose security makes all others look like a pile of crap, but as soon as someone chooses an easy to guess password, or writes it on a post it note and sticks the note to the monitor, you have a weakness.

[JonHendry]

Not the Objective-C runtime

It really has nothing to do with Objective-C.

The 'charger' gets the UDID of the iOS device, then logs into the hacker's Apple Developer Account and generates a developer provision file (or maybe an ad-hoc provision) for that specific iOS device. It puts the provision file on the iOS device, at which point it can install apps. Whole, sandboxed apps, just like any other app install.

The fake charger could install a fake 'Facebook' app that looks like the real thing. But it couldn't inject code into the real Facebook app on the user's device. Any apps that the charger installs would be fully-fledged iOS apps, and thus able to do anything other sandboxed, non-jailbroken iOS app can do. But would also operate under the same limitations. They would not restricted by App Store rule compliance, but then again, neither are enterprise iOS apps that aren't distributed via the App Store.

And the apps installed by the charger would likely have to be run by the user - thus the need to install an app that looks like one of the user's apps, like the Facebook app.

[Michael Hutchinson]

Re: Not the Objective-C runtime

Did you RTFA?

The Objective-C runtime was mentioned in relation to the ability to publish an app to the app store, that passes Apple's approval process. That part has nothing to do with the "charger".

[Thomas Wolf]

Re: Objective-C runtime

Maybe I'm being intentionally naive, but I don't understand what the big deal is here: yes, if you want, you can write and get through Apple's approval process an app that can do malicious things. But aren't you, as an Apple app developer, required to register with sufficient credentials to allow Apple (and/or legal authorities) to track you down if your app is found to be doing evil things?

[Steve Knox]

Re: Objective-C runtime

...you can define a new class at runtime and then insatiate it

Yeah, I hate it when those malicious coders create classes that simply won't stop eating and eating...

[Destroy All Monsters]

Re: Objective-C runtime

> if the person doing the testing doesn't do a good job then things will slip through

Let me state in no uncertain terms that finding out whether an app is malicious or has "Manchurian Voltron" powers to rearrange themselves into a malicious configuration at a later time is actually an undecidable problem. Not to mention ill-defined.

Apple just cannot find out that such maliciousness exists in general.

[M Gale]

Re: Objective-C runtime

"Apple just cannot find out that such maliciousness exists in general."

Have to wonder whether this is related to the halting problem.

Given a system, find out whether that system will ever become malicious.

In simple cases, solvable. In complex cases? Well, I think the example is in the article.

[Michael Wojcik]

Re: Objective-C runtime

Have to wonder whether this is related to the halting problem.

Assume Apple have an algorithm that can detect malicious behavior in a particular configuration of a given program. It terminates when it detects such behavior.

They design a program that, given a candidate app, iterates through its configurations, checking each for malicious behavior.

Does this checking program halt?

It's generally pretty trivial to provide a casual argument that any sufficiently-general "analyze a program" operation can be made isomorphic to the Halting Problem, because it's usually just a matter of rewriting the behavior of that operation as a version of the HP. Formally proving it is a bit more work, but usually not much.

Of course, as DAM pointed out, it's not only undecidable in the general case; it's not even well-defined. What is "malicious behavior"? Is it any behavior that the user did not expect and regrets after the fact? Gonna be tough to model that.

[jake]

Apple's variation of BSD ...

... tends to baby the consumer & ignore security. Just like Microsoft. And Canonical.

It'll get ugly before it gets better. Me, I'll stick with proper BSD and Slackware.

[Anonymous Coward]

Re: Apple's variation of BSD ...

You do that, the rest of the world has a life that doesn't revolve around text based computing. The 1970's left this world a long time ago and I for one, don't want them back.

[jake]

@AC 08:38 (was: Re: Apple's variation of BSD ...)

AC (may I call you that? Or am I being too familiar?), I'll warrant that 99.5%+ of the info you gather from online sources is text. And I still use a text-only ASCII console to manage the system you connect to TehIntraWebTubes thru' ...

[SuccessCase]

Re: Apple's variation of BSD ...

Oh pur-lees, we've been hearing "it's just about to get ugly for Apple security", and "Apple know nothing about security" claims for the last 11 years for OSX and the last 5 years for iOS. Really, continually. Most commenters gave up after making their second "please believe me, this time it's really going to happen." claim. The world is still waiting for that particular much portended cataclysm to strike.

[jake]

@Success Case (was: Re: Apple's variation of BSD ...)

Give me access to your Apple hardware, and I can get root. That is, by no stretch of the imagination, "security" in a mobile device that may get lost, stolen, or strayed.

HTH, HAND.

[Tim99]

Re: @Success Case (was: Apple's variation of BSD ...)

@jake

[Give me access to your Apple hardware, and I can get root. That is, by no stretch of the imagination, "security" in a mobile device that may get lost, stolen, or strayed.]

I think you meant "Give me, sufficient time with access to your phone/laptop/netbook/Android/Microsoft/Apple hardware and I can get root". Wel even I probably can some of the time, but it is generally not worth the candle...

[jake]

@Tim99 (was:Re: @Success Case (was: Apple's variation of BSD ...))

Did you see where I wrote:

"... tends to baby the consumer & ignore security. Just like Microsoft. And Canonical."

Kitchen-sink ware is kitchen-sink ware.

Sufficient time is about a minute or so, plus power-up,

[SuccessCase]

Re: @Success Case (was: Apple's variation of BSD ...)

I expect you are referring to the single user mode password reset use-case allowing someone with physical access to the machine and who knows how to access single user mode to reset a forgotten password - but only if the disk is not encrypted.

It's a deliberate use-case and is a policy trade-off between ease of use and security with a more secure option (disk encryption) available for those who need it.

I happen to agree it's not the best policy choice, but Apple disagree and deliberately configure OSX this way. They are in effect saying all the while a disk is unencrypted and someone with ill-intent has physical access, you already have one open door onto the machine, so allowing a second door makes no difference and it is positively helpful if users who have forgotten their passwords can get them reset them (also the password must be changed which presents a soft social barrier to more casual "family", or "staff" member compromise because it will be clear to the user password has been reset).

If you are someone who worries about security and physical machine access, you can switch on disk encryption in which case neither single user mode password reset nor direct access to unencrypted data on the disk drive are possible.

Evidently the policy isn't causing real-world problems and will undoubtedly be solving quite a few lost password user headaches also, so though I happen to agree it's the wrong policy, it seems, on a practical level to be working.

[SuccessCase]

Re: @Success Case (was: Apple's variation of BSD ...)

"also the password must be changed" - should really say "the password will necessarily be changed - because they won't know the original password"

[Anonymous Coward]

Re: Apple's variation of BSD ...

Apple? Ignore security?

iOS is the first consumer OS that I'm aware of that sandboxes all apps.

Now everybody else is copying their obviously-superior security model.

By doing this sandboxing, Apple has done more for computer security than any other company in the last 20+ years.

[Andy Fletcher]

So you should only really use an Apple© charger

Apple will be pissed to hear that I'm sure.

[dougal83]

Lies Lies

This is a lie. You cannot fool Apple as they are the best!

[Cuddles]

Harsh, but fair

"malicious tasks, such as posting tweets"

I know it makes perfect sense in context, but that still made me smile.

[Ken Hagan]

Re: Harsh, but fair

The context, presumably, being the recent court cases where various people ended up paying serious cash for their ill-considered tweeting.

[Number6]

Charger adapter

It sounds to me as though what is needed is a little plug/socket adapter that goes in the line and makes sure that the two USB data lines never reach the charger itself. Preferably moulded in transparent plastic so that it's clear from the outside that there is definitely no trickery going on to make it appear like a disconnect but later connecting the lines on request from the charger. That way the charger can never communicate with the phone. Such a widget would also be useful when you want to charge your phone from a PC's USB port but not register as a device on the PC (although this ignores all the USB power negotiations that would take place).

[Nanners]

Security hacks

So some lonely geeks who need to publish a paper invented a way to create a security consern for apple users so that when it hits the wild they will have more work trying to find ways to "secure" it. I hate these security thieves.

[Anonymous Coward]

Re: Security hacks

Those "lonely" geeks do the things Apple should do but do not. Why pay in house programmers when you can have it for free.

[Anonymous Coward]

Re: Security hacks

Exactly. Nobody cares about computer security till their bank account gets wiped, and then they demand to know why something hasn't been done about it.

[Nanners]

Re: Security hacks

The only security you are concerned about is job security.

[Destroy All Monsters]

Re: Security hacks

> The only security you are concerned about is job security.

I hope summer is over soon.

[Michael Wojcik]

Re: Security hacks

I hope summer is over soon.

Eternal September is eternal.

[Anonymous Coward]

For as long as I can remember

BlackBerries won't do anything when connected to a computer unless you have installed an application which asks for the password. I am sure that there are potential security holes I don't know about, but this seems to suggest that Apple is somewhat behind the curve.

[Darryl]

Re: For as long as I can remember

'BlackBerry'? 'behind the curve'?

I see what you did there

[Bob Merkin]

How big are iPhone chargers?

I'm not following something here. Reports on this story say they used a Beagleboard inside a regular iPhone charger. I have a Blackberry charger that's a 1.25" cube. My Nexus 7 charger is 1"x2"x2". As small as single board computers are, they aren't going to fit in either of those. A Beagleboard is 3" square. Are there iPhone chargers big enough to fit a Beagleboard that an iPhone user would believe is an Apple OEM charger? Or would the hacker have to explain the oversized brick to his target to get by any suspicions?

[Anonymous Coward]

Re: How big are iPhone chargers?

The last time I looked at a Beagleboard, most of it was taken up with I/O. A Beagleboard has a whole lot of stuff, like Ethernet and HDMI, that such a hacking tool would not need. In fact, it would not even need the built-in USB socket. You're looking at a slow ARM cpu, a small flash memory, a small RAM, and a few interface devices. I suspect the entire silicon and a thin circuit board would fit into the volume of a 2p piece, easily.

Why would anybody bother? The ATM scams involve very ingenious engineering; entire ATM fronts have been replicated to hide the equipment. A well designed scam based around dialling premium rate numbers could make very large profits. And with hotels and conference centres making charging stations available as a customer convenience, the throughput and lack of control is all there.

[Ken Hagan]

Re: How big are iPhone chargers?

I imagine that now (having figured out how to do it) they could squeeze the whole lot into an FPGA inside the USB plug. These guys are researchers. If you want product development, speak to the guys in black hats who were sitting in the audience.

[Anal Leakage]

"high fructose phone"

donut, eclair, jellybean...

[jake]

@Anal Leakage

You're talking sucrose, not fructose.

Might be able to control the leakage if you control your sugars ...

[Anonymous Coward]

Horror of horrors

So if I download a dodgy-looking app, it might post tweets without my knowledge? (And they wouldn't even be my own tweets, since the app wouldn't be able to get my credentials.) (And the app would have to be running in the foreground to be doing this, since Apple famously doesn't allow general-purpose multitasking.)

Might as well re-title this article to "apps do stuff when you run them." Breaking story!

The real story seems to be that Apple's security model is working as designed, and working well. Even if you download, install, and run one of these "malware" apps, it still won't be able to get access to any of your sensitive personal data.

[Ken Hagan]

Re: Horror of horrors

"And the app would have to be running in the foreground to be doing this, since Apple famously doesn't allow general-purpose multitasking."

Perhaps not for UI processes, but all sorts of alerts can be raised whilst you are doing other things and I have no trouble transferring files on and off an iPad whilst it is running an unrelated app, so clearly the OS does allow multi-tasking.

[Anonymous Coward]

Re: Horror of horrors

"Perhaps not for UI processes, but all sorts of alerts can be raised whilst you are doing other things and I have no trouble transferring files on and off an iPad whilst it is running an unrelated app, so clearly the OS does allow multi-tasking."

Er, sort of. But both of those examples are not of apps running in the background. In the case of alerts, those are being sent from 3rd parties to Apple notification servers and then to your device... nothing is running in the background on your device other than the OS software necessary to receive and display those alerts. In the case of transferring files, that's another case of the OS reading the files from the device and transferring them without the app running.

iOS does allow limited multitasking for 3rd party apps to do specific things, e.g., give turn-by-turn directions or play music. But I think it would be hard-to-impossible to exploit this multitasking ability to do something malicious. (Which, don't get me wrong, is a good thing. I like to be in control of what's running on my devices. Pretty easy with iOS.)