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.

Comments

Detects and exploits

[xxxJonBoyxxx]

>> free app that apparently detects the Trojanized apps

"detects and exploits" probably

Re:Detects and exploits

[Junta]

"It's an App!" - Admiral Ackbar

Re:Detects and exploits

[U2xhc2hkb3QgU3Vja3M]

"It's a trap!" - Admiral Appbar

Re:Detects and exploits

[cfalcon]

Don't slander Pangu. They have a reputation to uphold, and they are already trusted with root on many jailbroken devices- because they have written several of the jailbreaks. All the guys that make jailbreaks happen don't want to see people fucking with jailbreakers.

Still better than that malware Android

[Anonymous Coward]

Still better than that malware Android

Re:Still better than that malware Android

[Anonymous Coward]

Way to hint at bigotry. Who cares if "homosexuals" read slashdot, how does that affect you at all? FULL STOP. It doesn't.

Now tighten up your manbun.

I agree, both "ecosystems" have their flaws. there's a start difference between IOS and Android.

IOS is a walled in garden, closed source, and you have to PAY to be a developer. You have no choice as to your "app store" without jailbreaking your device. This was done to "protect" it's users with a secured, walled in, app store. Clearly this failed

Android is open source, and while you are selling a bit of your soul to google, you can EASY strip any remnants of google from your device and still have a perfectly functional smart phone. You can decide where you get your apps from, and you can download the SDK and start building apps for free, RIGHT NOW.

Both app markets are full of garbage, for every 1 good app there's 30 rip offs of varying quality and functionality. Both market places have had infected apps hosted on them.

The difference is, on android you have the ability to view the code and see what's going on, not ever app releases it's code or even in a human readable form, but the source code for android is out there, with thousands of eyes on it.

If you trust ANY hardware/software manufacturer to have your best interests at heart you are a fool, they are in it for money, they are owned by the shareholders and do whatever maximizes profit at their behest.

Offering a stable and secure produce is tertiary.

Re:Still better than that malware Android

[mrchaotica]

It matters because "IOS" is a different operating system, made by Cisco. Sure, it's clear from context which one is being talked about in this case, but that's not always true.

(On a related note, it was pretty stupid of Cisco to license the trademark.)

Re:Still better than that malware Android

[tlhIngan]

IOS is a walled in garden, closed source, and you have to PAY to be a developer. You have no choice as to your "app store" without jailbreaking your device. This was done to "protect" it's users with a secured, walled in, app store. Clearly this failed

Not anymore. XCode 7 adds the ability to deploy to any personal device for "free".

Quoted because you need a Mac to run XCode.

But as long as you compile the code yourself (way to go - a proprietary OS enforcing open-source!), you can load the code on your phone.

In fact, there are emulators out there (like provenance, gba4ios, etc) that people are using just fine on their iOS devices. All you need to do is get the code from a tarball or git/svn/etc, open in XCode, build and deploy to your iPhone or iPad or whatever.

No, it doesn't qualify as "Free" because the built binary is limited to running on your own devices.

And the iOS sandbox was not breached - the amount of information the malware could access without alerting users was pretty limited anyhow - you could get the date, time, application ID, UUID (which because of advertising, is now different per-app) and a few other things. If the malware tried to access contacts, photos, or GPS, an alert would show up asking if the user wanted to allow or deny the action.

Of course, if said iOS device was jailbroken, then the malware could get way more information because the sandbox would be broken.

As bad as it goes, the infected apps really get less information than a typical app which wants to do in-app advertising.

Re:Still better than that malware Android

[drinkypoo]

Also, who decided that 20% is now the "standard" tip amount? It's supposed to be 15%!

The minimum wage hasn't kept up with inflation in over twenty years. Be a sport.

Re:Still better than that malware Android

[tepples]

IOS is also the name of the Wii's operating system, developed by Nintendo and BroadOn.

Re:Still better than that malware Android

[jittles]

As bad as it goes, the infected apps really get less information than a typical app which wants to do in-app advertising.

Unless the infected app is supposed to request permissions for GPS, address book, calendar, photos access, etc etc. If snapchat were to become infected, as an example, they would have access to pretty much every piece of information you can get inside a single app except for the calendar.

Re: Still better than that malware Android

[Karlt1]

So does that "freedom" come with the ability to update the OS the day a new version is released?

Without waiting on the carrier?

And the manufacturer?

For up to four years after you bought the phone?

Re: Still better than that malware Android

[Karlt1]

Now tighten up your manbun.
I agree, both "ecosystems" have their flaws. there's a start difference between IOS and Android.
IOS is a walled in garden, closed source, and you have to PAY to be a developer.

Android is open source - except for the large part that is Google Play Services, and Google apps, and many of the hardware drivers, and the third party apps that most OEms and carriers put on their phone.

Parts of iOS are open source (Darwin). It's a distinction without a difference.

You don't have to pay to be a developer, you can download XCode for free and install any apps you create with it on your own devices.

You have no choice as to your "app store" without jailbreaking your device. This was done to "protect" it's users with a secured, walled in, app store. Clearly this failed
Android is open source, and while you are selling a bit of your soul to google, you can EASY strip any remnants of google from your device and still have a perfectly functional smart phone.

Except for the fact that many apps depend on API's that are part of the closed source Google Play services....

You can decide where you get your apps from, and you can download the SDK and start building apps for free, RIGHT NOW.

And you can download XCode for free RIGHT NOW....

Both app markets are full of garbage, for every 1 good app there's 30 rip offs of varying quality and functionality. Both market places have had infected apps hosted on them.

The big differences are that iOS has better sandboxing that was able to keep even the infected apps from doing any real damage and when there is a vulnerability and Apple releases a patch, every IOS device worldwide released in the last four years can be updated that day without waiting on your carrier.

The difference is, on android you have the ability to view the code and see what's going on, not ever app releases it's code or even in a human readable form, but the source code for android is out there, with thousands of eyes on it

Except for the large parts of the code that encompasses Google Play Services, drivers, OEM and carrier installed apps.....

Re:Next...

[TheRaven64]

This is true. I have an Android phone, and I don't even need to go to some 'app store' thingy download malware, it still (3 months after initial public disclosure) is vulnerable to the Stagefright vulnerability, which Google researchers have shown is exploitable from the browser and allows privileged arbitrary code execution. None of this crap from Apple, where you need user action to install this stuff!

Need to ban these companies

[ilsaloving]

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.

Re:Need to ban these companies

[Malc]

They probably already had Gatekeeper disabled. I know I had to do this simply because of the number of tools I use as a software developer that wouldn't run otherwise. Gatekeeper's pretty good if you only play Farmville or don't do anything beyond Safari, although I wonder why you'd have a high end computer for that rather than a generic Windows system or some other portable device.

Re: Next...

[BronsCon]

Blame your phone manufacturer and carrier for your lack of update. I have a Nexus device and had the stagefright update the next day, direct from Google. Same for the password field update (which didn't affect me as I use a pattern lock). Apple has never released a patch that fast for iOS.

Re: Serious to get into developer path

[BronsCon]

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.

Re: Next...

[BronsCon]

Most security updates aren't hardware specific.

But the system images are. That's kind of the point.

and then Google only promises updates for 18 months

Actually, that's:
- Three years from when the device first became available on the Google Store
- Or, 18 months after the device stopped being sold on the Google Store
For how long does Apple promise to support their handsets?

Apple is currently supporting every phone that has been released since 9/2011

While it is true that the oldest phone Google is directly releasing updates for (Nexus 4) was released on November 13, 2012, the HTC HD2, a Windows phone released in November 2009, has community-released ROMs of Lollipop. Does the iPhone have that? No, the iPhone can't have that. If you want to limit it to official vendor support of devices that originally shipped with Android, we're looking at support dating back to 2010.

http://arstechnica.com/security/2015/01/google-wont-fix-bug-hitting-60-percent-of-android-phones/

You do realize that the security hole in question is a bug in WebKit, which is more Apple's than Google's; Blink, which replaced WebKit in Android in 2013, is a fork of WebKit, and the issue has been patched there already. Google hasn't actively developed Apple's WebKit since it forked off Blink. Also, Google didn't say they wouldn't issue a patch, only that they wouldn't write one:

If the affected version [of WebView] is before 4.4, we generally do not develop the patches ourselves but do notify partners of the issue[...] If patches are provided with the report or put into AOSP we are happy to provide them to partners as well.

WebView 4.4 is where they replaced WebKit with Blink. They are no longer developing WebKit, so it is a reasonable position.

No less reasonable than Apple, at least. I do miss Snow Leopard.

Also, Google not writing their own patch for a 3rd-party library (WebKit) does not negate the 24hr turnaround I've seen on many issues since I've had a Nexus device; something, again, Apple and Microsoft literally never do.

All of that said, I do think Google screwed the pooch by allowing manufacturers to bake their own ROMs; that's why I own a Nexus in the first place. Android's ability to be customized to allow for quick access to apps and information (literally tap from the lock screen, then unlock) far surpasses that of iOS, which is why I prefer Android on the device I carry with me to pull out of my pocket when I want/need to access information quickly; it does lose that advantage on a tablet, which is typically only picked up to perform tasks (rather than the fetch information), which is why I also have an iPad.

Re: Next...

[Karlt1]

But the system images are. That's kind of the point.

What good are the "system images" if you can't update your phone with it -- unless you are one of the tiny minority that have non-Verizon Nexus devices?

Actually, that's:
- Three years from when the device first became available on the Google Store
- Or, 18 months after the device stopped being sold on the Google Store
For how long does Apple promise to support their handsets?

Lets look at history:

iPhone 3GS
-release 6/2009
-discontinued 6/2011
-last update 2/2014

iPhone 4 -
-released 6/2010
  discontinued 6/2013
- dropped support with iOS 8 (9/2014)

iPhone 4s
-released 9/2011
-discontinued 9/2014
-still receiving updates

iPhone 5
-released 9/2012
-discontinued 9/2013 still receiving updates

iPhone 5c
-released 9/2013
-discontinued 9/2015
-still receiving updates

iPhone 5s and later are still being sold

So if you bought any iPhone when they were the top of the line phone, you got at least four years of support. If you bought any Nexus phone when they were the top of the line phone, do you still receive updates after four years.

But Nexus phones have never been top sellers. So most Android users aren't buying Nexus phones.

You do realize that the security hole in question is a bug in WebKit, which is more Apple's than Google's; Blink, which replaced WebKit in Android in 2013, is a fork of WebKit, and the issue has been patched there already. Google hasn't actively developed Apple's WebKit since it forked off Blink. Also, Google didn't say they wouldn't issue a patch, only that they wouldn't write one:

WebKit was not "more Apple's than Google's". Before Google split Blink from WebKit, they had just as many commits to the code base as Apple.

http://appleinsider.com/articl...

Even if that's not the case would you argue that they shouldn't make a security patch in Android that was found in the Linux kernel because it wasn't "theirs"?

Could Apple get away with not patching a vulnerability found in the Darwin kernel because it was actually an issue with BSD?

And the issue was with Google's implementation of the WebView that uses WebKit, iOS didn't have the same vulnerability.

Also, Google not writing their own patch for a 3rd-party library (WebKit) does not negate the 24hr turnaround I've seen on many issues since I've had a Nexus device; something, again, Apple and Microsoft literally never do.

WebKit was not a "third party" library. It was an open source library that Google committed just as much code to as Apple. The code in question was integrated in the AOSP.

Android's ability to be customized to allow for quick access to apps and information (literally tap from the lock screen, then unlock)

Huh? For access to notifications you just swipe down on a locked phone to get to the notification and you swipe right on the actually notification to do some application defined event with it.

Or the notification pop ups directly on the screen depending on how you have notifications set for the app.