My professor (a malware/security expert) actually came up with this a few months back, but it was an idle thought, not a project, so sadly we don’t know the answer. It would be very difficult for an iOS app to execute malicious code since all apps are screened for various things before put into the store. However, they likely won’t notice seemingly non-functional bits of superfluous code.
So then the idea is this: make a handful of apps, and in each one have an obfuscated component of some malware that seems completely innocent and useless on its own. However, when all the apps are on the machine (and presumably have been launched), suddenly they do something none of the apps alone do. In other words, they have some mechanism to activate each others’ code, and while alone these methods are boring and useless, together they end up spreading a virus or stealing your stored phone numbers or using your phone’s email for spam or any other number of things.
So the question comes down to: can apps on the iOS communicate normally? Would it require a level of hacking that wouldn’t make it past the app-store inspectors anyway? I think people would be pretty quick to notice this sort of trickery if the effects were blatant enough, but I wonder if it’s possible.
And no, I’m not planning to write iPhone malware thank you. Well, I mean, maybe if it’s possible I’ll “infect” my own phone with some silly relatively useless Happy Birthday-level “malware” just as a proof of concept, but definitely not actually release anything into the wild. I’m more interested in malware at the level of “to stop it, you must first understand it”.
It is my understanding that iOS applications are sandboxed from each other as well as the underlying OS, so you have to break that level first - probably not impossible, but it makes it harder for each individual component to look innocent if they all require the ability to break the sandbox.
Multipart malware is fairly common, usually to avoid scanners.
I figured this might be the case. For precisely this reason. Thanks.
Yeah, I figured it wasn’t exactly a genius revelation. But it did seem to be a rather clever way to get around the app store screening process if it worked.
iOS apps can communicate with other apps on a device in three ways that are completely apple approved:
(1) Via UIDocumentInteractionController, which allows apps to send files to other apps
(2) Via a custom URL scheme that the other app can register for
(3) Via the pasteboard
The first and third requires the user explicitly selects the other app, so it probably not a great vector. The 2nd makes it trivial to detect if other apps are installed, and if so, launch them with extra information. I have an app on the app store that does just this (for non-malicious purposes).
All of this is pretty unnecessary though, because there are plenty of ways to get your app approved and then later have it execute malicious code. For example, you could have it ping a server to ask whether to be naughty or not and only flip the server flag on after you’ve passed review. Apple will be very unhappy if they found out you did this of course.
I think that by using UIDocumentInteractionController you could possibly assemble a piece of malware from nonfunctional files included with a family of apps, but the app sandbox would make it hard to actually execute the resulting code - I expect that the file storage areas will be non-executable.
The classic multi-part assembly hack was used to disable hacked satellite decoders back in 2000 or so - after several months of small, odd, rapid updates, the final update assembled all the prior data into an entirely new firmware that disabled the hacked decoder cards and pasted a message “Game Over” onto the cards.
Yeah, in general you can’t run any code that’s not included in your original binary. If you could do that, you wouldn’t even need multiple apps - you could just download the malicious code from the network and assemble it locally. This is why apple has taken such a stance against interpreted languages, for example.
There is one exception to this: apple’s very own UIWebView, which will render javascript. And just to show that their fears were not off base, being able to run code downloaded from the internet has already resulted in high profile attack vectors like dropbox’s iOS app:
which potentially allowed an attacker to steal user files that had been cached locally.