Slashdot Mirror
"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.
So...it has come to get this...
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.
“The Jekyll app was live for only a few minutes in March, and no innocent victims installed it, Lu says,”
So it "wreaked havoc" when no one installed it? lolwut?
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.
"Apple ran the app for only a few seconds, before ultimately approving it."
iOS apps are disposable like travel-sized portions of toothpaste.
Would have trusted Steve Jobs to have solved the Halting Problem before he died. Guess he was a mere mortal after all.
oh, you mean like my single-serving friends that I meet in my travels
WARNING: Smartphones have side effects--most of them undocumented.
Wanna buy some soap?
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
Well done, by jove I think you've got something, my dear watson!
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.
....compared to Android apps? Usage figures seem to say otherwise.
What is the "academic" value of showing that one company has flawed processes? I'm not criticizing the findings themselves nor the methodoloy per se, but I just question that it's being done in the name of "academic" research when it is anything but (though I'm sure there will be attempts to divine some sort of generality from the results). The generality would have legitimately, in the academic world, come from a paper that might describe theoretically how such an attack could happen.
Don't get me wrong, I'm not saying that the work wasnt good.. I'm just saying that it's misplaced, to the extent that these guys deserve a serious review of their work. It's like "academics" doing research that's really market research ... and so not really appropriate.
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)
When it came to concealing its true nature from Apple, I guess you could say Jekyll found it easy to...
(puts on sunglasses)
...Hyde.
YEEEEAAAAAAAAAAAHHHHHHHH!!!!!
You can't attack other apps?
So how does jailbreaking work?
Jailbreaking works by attacking the device over USB, generally the update mechanism - not something you can do through an app.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Only the most recent one.
There was a time you could jailbreak via pdf or just visiting a webpage. It is quite possible another such exploit will be found in the future.
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
Private API calls are not breaking the sandbox.
Pretty much none of what they did that they consider an attack is possible in IOS 6., much less iOS7 which is on the eve of release - and some 95% of active devices are running iOS6 now.
I can break into Windos95 pretty easy too. But who cares and why would it warrant an article? The whole paper really boils down to "sometimes the app reviewers do not run an app for long" which is news to pretty much no-one.
"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
They can convince companies to add spyware to their apps and then turn it on at a later day. In fact maybe 100k of the shit apps out there were actually created by the NSA all with different accounts so when one account is deleted they still have others to use,
Where did it wreck havoc? I would be more worried about the malware rise in the Android App Store copy instead!
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.
made the app store....rotten to the core! LOL
I just best if they tried this tactic with and app that made reference to it being able to view eBooks that it would get more than a few seconds look over by apple.
As an iOS developer, I already discovered this a few months ago. I released an app to the store a few months ago that used Kiip for rewards. Kiip allows me to see who is using the app.
I was surprised when Kiip announced they only used my app for approximately 5 seconds. Since my app was a game in itself, that was about the time it would have taken for the game to launch.
I chalked it up to a mistake on Kiip's part... However, when it finally hit the store I installed it and was shocked to discover my game crashed after doing one of the most fundamental actions in the game. It crashed right on queue, every time.
There is no way Apple actually tested my game or they would have seen the crash and rejected my app (i wish they had. would have been better for me). Kiip was right.
So, I ended up fixing it and submitting an expedited review request that eventually fixed it a few days later.
Apple does NOT test apps before approval or only does for a very small sample of apps. I never thought of making malware of the situation though.
From all I have read in the thread, the app was available for only a few minutes and could only attack an outdated (4% of users) version of iOS and still could not break out of the sandbox. Havoc is way overstating what happened. I agree with "headline completely made up".
Similar trick for Android from a year ago:
https://blog.duosecurity.com/2012/06/dissecting-androids-bouncer/
Just gonna lie in the headlines now? Come on...
Posting tweets, I know for a fact is the same as SMS and Email in that it's a sheet operated by the system, you can't touch it from the app.
The worst possible thing I thought, would be if it could actually dial out without the user giving permission. So I embedded the code they gave in the paper in a sample app, with the CoreTelephony framework (and a number of other frameworks/libraries for good measure) added:
void* h = dlopen("CoreTelephony", 1);
void (*CTCallDial)(NSString*)=dlsym(h, "CTCallDial");
CTCallDial(@"A Valid Phone Number here");
Segfault, no dialing. So THAT does't work either.
I didn't test some of the other things but I really wonder how much they ACTUALLY tested on iOS6. What a shame that it's so easy to fool so many people like yourself just by throwing around terms like "private API" and some semi-plausable looking code...
I'm sure some of it would still work on iSO6, but it seems none of the really dangerous ones does. So my stance is still that they didn't really break out of the sandbox, they are just building some nice looking castles and pretending they are real.
Is it TOO MUCH TO ASK that some independent verification take place on fantastic claims like these?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Oh really? So how about those millions upon millions of IPhone 3 / 3G and IPad 1?
Very few, in any kind of access logs or app statistics from analytic libraries those devices fall way below 1% of devices.
Not everyone in this world is a wealthy American that would throw away a perfectly fine three year old phone or tablet
I didn't throw mine out. It just has more limited use than the newer devices. No way would I buy new apps to run on it, it just runs some apps that I bought for it a while ago, or works for browsing (or a photo frame).
If Microsoft behaved the way Apple does wrt. updates
Which they do - didn't you know?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
The researchers wrote a fairly in-depth paper on the attack which can be read here..In the case of tweets, they make use of "private API's" to avoid notifying the user:.
Which does not work in iOS6, as mentioned by the article itself (it notes that attack only works in iOS5)
I attempted to get the dialing code as presenting working in iOS6. It segfaulted (and yes I did include the CoreTelephony framework, and used the -all_load linker flag). Since that's a bust how much other stuff in the paper does not work as claimed either?
Their POC app apparently performs the exact malicious tasks they indicate all without user notification.
They CLAIM it does, this is what requires proof. The paper is just providing some means how it might be done, not showing that it works.
Real proof would be a buildable, runnable project that did all of the things they claim. Since they are already providing source code in the paper why would they mind releasing a project... well where is it?
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Getting users to grant permission for just about anything is pretty easy.
Not dialing. If the user is presented with a dialog in the middle of an app run asking to dial some number they have no idea about, very few people will agree to that... context is very important.
Similarly just running some to-do list app and out of the blue it asks to use the camera? Not that many people would agree to do so, even those who are pretty naive.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I do think that Apple checks automated for any non approved API calls or other methods of adressing functions outside of the 'standard' environment. I know of apps being rejected because of doing lower level calls.
There's apps that prevent access to harmful data http://tech.slashdot.org/comments.pl?sid=4072127&cid=44581987 in a useful way that gains speed (as you admitted), added "layered-security"/"defense-in-depth", better reliability, superior anonymity, & just better overall as well (by yours truly).
* :)
(All of which you pulled a "Run, Forrest: RUN!!!" from in that link above too, no less... lol! "Gee, wonder why?" (NOT!!!)).
Everything's a dichotomy - I prove the usefulness of it @ times... speed gains that are incredible (by reduction of dead-weight useless more than potentially harmful data) - which you conceded but radically underestimated as well, but more security, reliability, & even anonymity added.
APK
P.S.=> Yes folks, I have to tell you: "It's not easy being 'world-class'" having to dispatch trolls as I did to omnichad using facts (does them in, every time) - pats self on shoulder!
... apk
App stores are going to continually up their level of interrogation to stay ahead of malware. In a similar way that PC users are still fighting malware, mobile platforms also have to make certain assumptions to detect malware-laden apps before they get to a consumer. While still an uphill battle, the control that Apple and Google have over the actual app stores (to varying degrees, of course) allows for a fighting chance, at least. There's a minimum set of hurdles that an attacker has to jump over in order to have an app pass through their direct stores. This research has some commonalities to the work Jon Oberheide and Charlie Miller did last year regarding Android's Bouncer (https://blog.duosecurity.com/2012/06/dissecting-androids-bouncer/). In that research they determined how Google was flagging a "bad app" and were able to circumvent that process by hiding the malware functionality when tested by Bouncer but not on a real device that would actually matter to an attacker. Overall, both pieces of research have huge implications for strengthening the security programs at Google and Apple.
Because of Apple's desire to allow in-app financial transactions, apps are allowed to reach out to a certain extent. If Apple closes things down all the way, so that this can never happen, the usefulness of the platform will suffer. I am interested in whether these students actually had credentials as researchers, or whether they were just a few hackers looking to generate some street cred by talking down the review process. I don't like the way Apple is doing things, but I think everyone involved in this "research" should have their developer credentials suspended. They definitely violated their developer agreement. For all we know these people are on Microsoft's payroll. I call bullshit on the entire situation.