"Jekyll" Test Attack Sneaks Through Apple App Store, Wreaks Havoc
An anonymous reader writes "A malware test app sneaked through Apple's review process disguised as a harmless app, and then re-assembled itself into an aggressive attacker even while running inside the iOS 'sandbox' designed to isolate apps and data from each other. The app, dubbed Jekyll, was helped by Apple's review process. The malware designers, a research team from Georgia Institute of Technology's Information Security Center, were able to monitor their app during the review: they discovered Apple ran the app for only a few seconds, before ultimately approving it. That wasn't anywhere near long enough to discover Jekyll's deceitful nature."
BUT MACS DON'T GET VIRUSES.
Unless they're too slow.
There is no point to the closed system if you let just anyone come in.
Since it was just a proof of concept and was on the store for a few moments.
Let's say you submit an app to the app store, and like many it's designed to do something fairly idiotic that today's kids find funny, say, take a picture and then superimpose the picture onto a set of background images included with the app.
Now, let's say the app writer has steganographically embedded "naughty" code in the background images, maybe even going so far as to spread the code across all the images, encrypt, etc. to make it difficult to find.
Can the app modify itself by taking its hidden code from the images and actually execute it? Can you download "new" code from the internet, even if its steganographically hidden? It seems like you shouldn't be able to do this, like the apps should be sandboxed from modifying their own code just to prevent importing unapproved code.
When I read this article, it strengthens my opinion that the Q&A process for the App Store is absolutely flawed. Don't get me wrong, regardless of wether you like or hate the walled garden, I actually am of the opinion that the guidelines - especially the UI guidelines - developers have to follow to beeing approved for the app store are a good thing in and itself. The Google Play store has similar guidelines, allthough - IMHO - not as focused on user experience.
I had a apps declined due to improper usage of a certain widget in another certain widget which was not deemed "correct" (switch button in a table footer for example), but always was able to either find a similar solution or - in one rare case (the one mentioned) - explaining WHY that switch button is there, and how if you take a look at the UI, understand what it does.
Then again I saw apps in the store which completely failed most of the even basic guidelines, described as (between the lines): "fail these, and your app will 100% be NOT approved", and I wondered "how did they get in there"?
Talked to other developers, same experience. Some knew they had a few things in there against the guidelines (custom springboards, views not conform with the UI guidelines) and hoped to get through. Sometimes they managed, sometime not, so they also got the feeling that the Q&A for the App store is somewhat like tax declaration. They don't seem to have enough time/ressources to check all, so if you something that is against the guidelines, you have to hope that you are one who doesn't get checked thoroughly.
oh, you mean like my single-serving friends that I meet in my travels
WARNING: Smartphones have side effects--most of them undocumented.
I can totally see getting an app through the submission process that does something a bit sneaky. Sometimes the app reviewers hardly look at a thing (though sometimes they look very carefully, it just depends on the reviewer).
But the claim the app could "wreak havoc" needs some proof. They said:
a Jekyll-based app can successfully perform many malicious tasks, such as posting tweets, taking photos, sending email and SMS, and even attacking other apps â" all without the users knowledge
Every single one of those, requires permission from the user to do - posting tweets an app cannot do directly, it brings up a sheet. Same thing for email/SMS. Taking photos requires an OK from the user to access the camera. You cannot "attack other apps" because of the sandbox.
Extraordinary claims, like a complete breaking of the sandbox, require more proof than they have presented. I would bet they are saying they THEORETICALLY could break out of the sandbox but have absolutely no actual working exploits that go outside of existing user permissions and the sandbox...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
No review process will ever catch all bad actors. I think Apple should be doing a better job with reviews in several dimensions, but that's not the prime advantage to the Apple ecosystem.
The main advantage is Apple can revoke the application. If this app started doing bad things Apple can remotely prevent it from running, and in fact revoke all apps by the same developer. This central control is what scares people, but it's also what makes long term exploitation impossible. The Google ecosystem doesn't have this feature, with no centralized control.
What kind of two-bit operation is Apple running if apps can phone home during the vetting process.
I am becoming gerund, destroyer of verbs.
Sadly, it's a matter of expenses stripped to the bone. The "testers" have targets to fill. Here, you have 1000 apps to test and 3 days to do it. You miss this target twice, you get fired.
It's a method I've seen (generally) pretty much everywhere. UAT or internal testing is considered "money sink" and its attached expenses are minimized by all means.
I would frankly have been surprised if the testing method were to be any different.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
I looked for the paper but could not find the link. Thanks for the extra info.
As I thought, they did not break the sandbox at all. Attacks that don't work in iOS6 are irrelevant at this point...
It's totally sensationalized. It remains true there's no way a real app can "wreak havoc" even if you inject code later.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
There was a time you could jailbreak via pdf or just visiting a webpage.
The only reason THAT worked is because the Safari javascript engine has native code JIT that an app cannot use. And now you know why...
So still true that you cannot jailbreak out of an arbitrary app, only ever from system apps that have elevated privileges, and then only once years ago...
Im not saying such an attack will never exist, it's just exceedingly unlikely and far more unlikely inside of an app you deploy to the store.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Good point. I guess that this never happened
Not in iOS6 it didn't. Apple started taking user security much more seriously in iOS6, anticipating a potential for such attacks. I always thought prior to that it was kind of nuts you could access the address book without permission - now you cannot.
Ah, the old "That vulnerability is completely theoretical" defense.
And yet it turns out to be true. The vulnerability is not real, only a theoretical possibility that relies on breaking the sandbox, which they have not done (using private API calls is not breaking out of the sandbox). You don't need to do anything sneaky in an app to do private API calls, but it remains true the sandbox is pretty secure and stops most REAL attacks.
You are crazy if you are more worried about a possible attack via an unknown hole in the sandbox, vs. very real attacks that are happening every day on Android...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
1. The only people downloading the app were the developers. No "havoc" happened.
2. The app is sandboxed. It doesn't escape out of its sandbox. Therefore, it can only do things that it is allowed to do.
3. The identity of the developers was known to Apple. If malware was delivered to end users, Apple could get hold of the developer.
4. To actually attack an end user, you still have to create an app that does what it claims it does, and that does things interesting enough to make people download it.
5. If an app did "wreak havoc", then Apple could kill it dead on all iOS devices.