Slashdot Mirror
Number of XcodeGhost-Infected iOS Apps Rises
An anonymous reader writes: As the list of apps infected with the XcodeGhost malware keeps expanding, Apple, Amazon and Baidu are doing their best to purge their online properties of affected apps, malicious Xcode installers, and C&C servers used by the attackers to gather the stolen information and control the infected apps/devices. China-based jailbreaking Pangu Team claims that the number of infected app is higher than 3,400, and have offered for download a free app that apparently detects the Trojanized apps.
>> free app that apparently detects the Trojanized apps
"detects and exploits" probably
Still better than that malware Android
Yesterday it was broken iPhone VPN, today it's hacked apps via xcode. Blah blah blah. Real techs use Android.
So let me get this straight...
First they downloaded a dodgy version of a free development tool...
Then they completely disabled Gatekeeper, which would have warned them that they were using a problematic version of xcode...
People/Companies who demonstrate such a shockingly poor level of judgement shouldn't be allowed to flip burgers, let alone be near a computer.
Hint: the only way to prevent an app from doing BAD STUFF is for the operating system to prevent it from doing BAD STUFF. Even a human reading the source code has a hard time telling whether that socket it's opening to www.evilserver.com is being used legitimately, or sending your banking passwords to Elbonian hackers. And if the bad code is inserted by the compiler, reading the source is pointless.
If you want security, you need to sandbox the apps, and ensure that Fluffy Kitty Screensaver can't read your banking passwords. At best, any app scanning approach can only find the most obvious malware, as this has proven.
Oh, and don't outsource development to dubious nations.
The "free detection" app quoted in the summary is an off-appstore build that must be trusted by the user explicitly. Given this is a "jailbreak team" it's unlikely they'll be bothered to do an in-channel release.
Given that it depends on crossing filesystem protection zones that are disabled for privileged apps which can only run on jailbroken phones, it's unlikely they would be *able* to do an in-channel release, since the thing simply wouldn't work.
Not the guy you were replying to, but I'll answer #5 anyway. It means any developer can slip malware past an Apple App Store review by making it wait a month or so before activating.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Not the guy you were replying to, but I'll answer #5 anyway. It means any developer can slip malware past an Apple App Store review by making it wait a month or so before activating.
That was a guess on my part; but ANY code can be obsfucated.
The only question is, regardless of Platform, Walled Garden, etc, is there any reasonable way that this can be eliminated from possibility, without hamstringing App Developers to the point that all they CAN write is "Fart" Apps?
Does, for example, XCode have to swell to twice its size (and half the speed) by having nearly as much "self-checking" code as actual functional code? Does , for example, XCode have to be "grey-listed" such that it WON'T run if it has been modified? Or what?
Until malware authors start leaving their code dormant for 2. then 3, 6, 12. See where this is going?
Of course, Apple would never increase the screening time to 1 month, let alone 2, 3, 6, or 12. They'd have approximately 0 developers writing for their platform if they did. So no, there is no solution; not even one involving a cat-and-mouse game with dormancy and screening durations.
The closest they could get would be to do a symbol dump of the submitted binary, identify all functional code, and require that directions for activating every bit of functional code be submitted along with the app. If a routine is found that can't be activated by following those instructions, reject the app.
Here's why that won't work:
- It makes it difficult or impossible to test applications which may call certain routines based on random outcomes (e.g. many games)
- It makes it difficult or impossible to test applications which may call certain routines based on user actions requiring much practice and skill (experience) withe the application (e.g. many games)
- It makes it impossible to test, in a reasonable timeframe, applications which call certain routines only after a set amount of time has passed
- It makes it difficult to use 3rd-party libraries, as one would have to ensure that they remove any unused routines from those libraries; this means not just stripping out any their application does not use, but also leaving in any which may be called by those their application does use. It's not always clear when some library might make internal calls to its own routines, nor always how to trigger them, which would make providing the required documentation neigh impossible, even if one were able to properly cull the code
- Even ignoring all of the above, there is nothing stopping a malware author from wrapping their malicious code in an if() statement inside a routine or function that is documented and will be tested by Apple, such that the code will lay dormant until a certain condition is met, even as the routine is otherwise executed during testing.
That is to say, as you already pointed out (while paradoxically still insisting that this should be able to be fixed):
ANY code can be obsfucated
And, more to the point, the code itself needn't be obfuscated; Apple doesn't see the code, they review the binary.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
That would only prevent developers from unknowingly submitting malware to the app store. It would to nothing for purposeful malware that simply remained dormant until some time had passed. The only solution for that is to increase the amount of testing/screening time allotted to each app. A month ought to do it.
Until malware authors start leaving their code dormant for 2. then 3, 6, 12. See where this is going?
Of course, Apple would never increase the screening time to 1 month, let alone 2, 3, 6, or 12. They'd have approximately 0 developers writing for their platform if they did. So no, there is no solution; not even one involving a cat-and-mouse game with dormancy and screening durations.
The closest they could get would be to do a symbol dump of the submitted binary, identify all functional code, and require that directions for activating every bit of functional code be submitted along with the app. If a routine is found that can't be activated by following those instructions, reject the app.
Here's why that won't work:
- It makes it difficult or impossible to test applications which may call certain routines based on random outcomes (e.g. many games)
- It makes it difficult or impossible to test applications which may call certain routines based on user actions requiring much practice and skill (experience) withe the application (e.g. many games)
- It makes it impossible to test, in a reasonable timeframe, applications which call certain routines only after a set amount of time has passed
- It makes it difficult to use 3rd-party libraries, as one would have to ensure that they remove any unused routines from those libraries; this means not just stripping out any their application does not use, but also leaving in any which may be called by those their application does use. It's not always clear when some library might make internal calls to its own routines, nor always how to trigger them, which would make providing the required documentation neigh impossible, even if one were able to properly cull the code
- Even ignoring all of the above, there is nothing stopping a malware author from wrapping their malicious code in an if() statement inside a routine or function that is documented and will be tested by Apple, such that the code will lay dormant until a certain condition is met, even as the routine is otherwise executed during testing.
That is to say, as you already pointed out (while paradoxically still insisting that this should be able to be fixed):
ANY code can be obsfucated
And, more to the point, the code itself needn't be obfuscated; Apple doesn't see the code, they review the binary.
So, since no system is foolproof, we do nothing, right?
A few years ago, it DID take longer for an App to get Approved. Developers whined. Users whined. Apple Management probably whined. So they (somehow) dramatically shortened the Approval Process. Is this the result? Don't think so; but I don't really know. Do you?
Using the iOS Approval Process as an example, since API calls can easily be spotted, perhaps Apps-Under-Review that make certain iOS API Calls get kicked to a higher-tier of Review, where the Submitter HAS to hand-over their SOURCE under NDA (or something similar), and more than one Apple Developer has to manually review it, and has the right to have the Submitter explain any questionable code.
Not perfect; but perhaps better at spotting questionable code, no matter the cause.
Which API calls would those be? Any that communicate to the outside world? There goes 99% of apps getting bumped to the "higher" review. Not a tenable solution.
I'm surely not implying that, since no solution is perfect, no solution should be implemented. I'm simply pointing out that, since no solution is perfect, no perfect level of security should be implied (as has been up until this point), while pointing out that the seemingly obvious solutions are not only imperfect, but so impractical as to be unimplementable. If you manage to come up with a practical solution, great, let's hear it; the one you provided above does not qualify, for the reasons stated.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
Which API calls would those be? Any that communicate to the outside world? There goes 99% of apps getting bumped to the "higher" review. Not a tenable solution. I'm surely not implying that, since no solution is perfect, no solution should be implemented. I'm simply pointing out that, since no solution is perfect, no perfect level of security should be implied (as has been up until this point), while pointing out that the seemingly obvious solutions are not only imperfect, but so impractical as to be unimplementable. If you manage to come up with a practical solution, great, let's hear it; the one you provided above does not qualify, for the reasons stated.
Show me where APPLE has ever implied that their security is perfect?
Pretty much, it is a meme by Fandroids, NOT Apple Users, derisively put into the mouths of the latter by the former.
Show me where APPLE has ever implied that their security is perfect?
I'm sure they never said it was perfect, but they've certainly marketed their devices as not requiring the user to think about security. This article highlights some of it.
"We’re trying to do two diametrically opposed things at once—provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks." ~ Steve Jobs
"We think a few months of patience now will be rewarded by many years of great third party applications running on safe and reliable iPhones" ~ Steve Jobs
Those were found skimming a single article. When taken in the context of the old "Macs don't get viruses" ads, which has also since been disproven (though I'm still often told that Macs really don't get viruses because it's not a virus if the user has to allow it -- okay, fine, it's malware, it still does something the user doesn't want, and it's still on a Mac, isn't it?), it's easy to see where people get the idea that the App Store should be safe.
And, by and far, it is safe. By the same metric, so is the Play Store.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
it's easy to see where people get the idea that the App Store should be safe.
And, by and far, it is safe. By the same metric, so is the Play Store.
Frankly, I think there is a Vas Deferens between THIS and THIS.
Oh, and BTW, XCodeGhost DOESN'T seem to affect the U.S. App Store, only China.
Frankly, I think there is a Vas Deferens between THIS [techcrunch.com] and THIS [pcworld.com].
There is also a vast difference between the availability of tools to properly scan for and detect malware on Android and tools to do the same on iOS; without filesystem access, they simply do not and can not exist on iOS. That might explain it, dontcha think?
Oh, and BTW, XCodeGhost DOESN'T seem to affect the U.S. App Store, only China.
That's not entirely correct. About 90% of affected apps are chinese-only, but there are a number of affected apps in the US and global app stores. Further, while Lookout and other solutions can actually scan apps for malicious content on Android, due to sandboxing and lack of filesystem access, these solutions can only scan for app names and versions known to be infected on iOS; and that capability has even been removed from iOS 9. Interesting, no?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
That would only prevent developers from unknowingly submitting malware to the app store. It would to nothing for purposeful malware that simply remained dormant until some time had passed. The only solution for that is to increase the amount of testing/screening time allotted to each app. A month ought to do it.
A simple way for preventing developers from submitting malware is to make sure you know the developer's identity, and make sure they pay for all the damages and get thrown into jail if they submit malware. And _that_ is what doesn't work against clueless devs.
There is tech to inspect compiled code and try to find malicious bits, even in an automated fashion, that won't be fooled by an idle loop. It's far from perfect or being a silver bullet, but it is there and getting better by the day.
Look at what the security firms are now calling "sandboxing". Look here: https://en.wikipedia.org/wiki/Malware_analysis#Free_automated_malware_analysis_services.5B2.5D
This is most probably what Apple does already, and clearly needs to get better at.
The bad news is that _it's bound_ to happen again.
This is why I agree with BronsCon, Apple should open doors to the sec community, but I don't think it will happen anytime soon.
BronsCon mentions sideloading as a possible way to do analysis, I don't know if this is the case (can sideloaded apps break the sandbox model?) but jailbreaking would obviously do.
13-4=54/6
Frankly, I think there is a Vas Deferens between THIS [techcrunch.com] and THIS [pcworld.com].
There is also a vast difference between the availability of tools to properly scan for and detect malware on Android and tools to do the same on iOS; without filesystem access, they simply do not and can not exist on iOS. That might explain it, dontcha think?
Oh, and BTW, XCodeGhost DOESN'T seem to affect the U.S. App Store, only China.
That's not entirely correct. About 90% of affected apps are chinese-only, but there are a number of affected apps in the US and global app stores. Further, while Lookout and other solutions can actually scan apps for malicious content on Android, due to sandboxing and lack of filesystem access, these solutions can only scan for app names and versions known to be infected on iOS; and that capability has even been removed from iOS 9. Interesting, no?
The Vas Deferens thing is a puerile joke I have used since I was a teenager, sorry.
I couldn't find any references to infected Apps in the U.S. Store, hence the comment.
Apple is in the best position to scan Apps on their own servers, anyway; so who cares about what anyone else can do? Lack of direct access to the Filesystem in iOS has significantly decreased the attack surface for malware, and has no doubt made the platform safer for everyone. It's a PHONE, get over it!
and WHY does EVERYTHING with Apple HAVE to be some big, dark CONSPIRACY?
Yeah, that'd probably work. Good luck getting it implemented, though. Also, not sure why it wouldn't work against clueless devs, as well; if it can be proven that, by using a legitimate copy of XCode, the infection would not have happened, they still get charged with negligence; otherwise, they're as much a victim as anyone else.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
It's a PHONE, get over it!
To some, it's a phone that can also do some computer-y stuff. To an increasing number, it's a computer than happens to be able to make phone calls. I'm in the latter camp; I hate phones, which is why I carry the device that lets me do more non=phone activities; that my Nexus can also make phone calls is simple a bonus, for those times when a text message or email isn't sufficient and face-to-face communication is not possible.
and WHY does EVERYTHING with Apple HAVE to be some big, dark CONSPIRACY?
Who said anything about a conspiracy? I was just pointing out that it was interesting that, as malware is being discovered in the App Store, Apple is also removing the only detection method available to end users; I recognize that iOS9 was released in advance of this discovery and that the two are unrelated, but that doesn't make it any less interesting, does it?
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
To an increasing number, it's a computer than happens to be able to make phone calls.
I understand that; but for most people, it's still primarily a phone. And for those people, it it a device that carries around a disproportionate amount of sensitive, personal information. So, I really don't think that security measures such as strict sandboxing are such a bad idea. There are more than enough file-manipulation Apps for iOS that no one should have trouble getting files on/off of an iOS device. In fact, I just discovered the other day that there is a Lightning to USB cable (Amazon even has a third party one for $3), which file-manipulation Apps like GoodReader can use to quickly transfer files onto/off of, any iOS device. And if your device is pre-lightning, you can use WiFi in several different ways with GoodReader or several other Apps to accomplish the same thing.
Oh, and I didn't know until the other day that the same situation exists in Android; that is, you need a File Manipulation APP to transfer files on/off of an Android device, just like iOS. The only difference is that you can muck about directly in the Filesystem, which, guess what? Most non-geeks really don't understand so well.
Who said anything about a conspiracy? I was just pointing out that it was interesting that, as malware is being discovered in the App Store, Apple is also removing the only detection method available to end users; I recognize that iOS9 was released in advance of this discovery and that the two are unrelated, but that doesn't make it any less interesting, does it?
Actually, it makes it TOTALLY uninteresting. Do you have ANY idea how much time likely elapsed between the "Feature Freeze" for iOS 9 happened BEFORE the Release Date? Jeezus.
So, I really don't think that security measures such as strict sandboxing are such a bad idea.
Neither do I, honestly. But I also think the ability to make an app a device administrator (which, in Android, allows it to traverse sandboxes) is a good idea, as it allows for administration tools to be implemented which otherwise would be impossible. Sandboxing does exist in Android; the fact that there still exists a shared "user" filesystem actually makes the platform more powerful. It also means apps can break their own sandboxes, and I do think Google needs to crack down on that.
Let's say I want to keep a Git repository on my phone. I can do this on both iOS and Android. On iOS, I have to open the Git app, browse to the repository, find the file I wish to edit, choose "Open in..." from the menu and let the Git app launch my editor. On Android, if I keep the repository on the shared filesystem, rather than in the Git app's sandbox filesystem, I can simply open my editor, navigate to the file, and edit away. Then, navigate to another file, edit, navigate, edit. When I'm done editing, I then launch the Git app and make my commit. I don't have to return to the Git app every time I want to edit a different file, as I must in iOS.
And yes, this is a real use case.
Conversely, if I keep the repository in the Git app's sandbox, it behaves just like iOS.
The issue is that many apps don't honor their own sandbox, so storing anything there is not possible for many apps; again, I do think Google should crack down on this. I also wish Apple would provide a shared "documents" filesystem, similar to Android's legacy implementation; it could even be implemented such that opening a file was an API call that launched an OS-level file selection dialog, so the app can only access files specifically requested by the user. That would be a fair balance between security and accessibility; right now, if I want that accessibility, my options are limited, I get Android's shared "user" filesystem, or Windows Phone (and pray I can find a worthy app on the platform), iOS is not an option.
Actually, it makes it TOTALLY uninteresting.
That they've neutered anti-malware apps on their platform shortly before the announcement that malware was discovered in their marketplace is uninteresting to you? It's interesting to me because now I know my anti-malware solution is ineffective on their platform; if you're not interested in that layer of security, then, well, good luck to you. It certainly doesn't point to any sort of conspiracy, but there are many other interesting things in this world.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
All while Google often removes much worse malware from the Play Store so often it doesn't even hit the headlines anymore. Did I mention they also scan all apps admitted? And refuse some? Like ad blockers? Must be malware.
Of course news about a fake are Fake News.
I'm typing this on an iPad keyboard that is paired to both my MacBook Pro and my iPad
Yes. Clearly I prefer Android.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.