Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
IOS Security Apple

Apple XcodeGhost Malware More Malicious Than Originally Reported 79

An anonymous reader writes: Details were scant when Apple confirmed the XcodeGhost malware had infiltrated the iOS App Store. The company didn't say which specific iOS vulnerabilities were exposed and didn't indicate how its iPhone users were affected. However, a Palo Alto Networks security analyst is reporting that XcodeGhost had been used to phish for iCloud passwords, and more specific details are emerging. According to the Networkworld article: "URLs can be sent to the iOS device and opened. This isn't limited to HTTP and FTP URLs, but includes local URLs, such as itunes:// and twitter:// that iOS can be used for inter-app communications. For example, this could be used to force automatic phone calls to premium phone numbers, which can charge up to $1 per minute in some cases. Some iOS password manager apps use the system clipboard to paste passwords into the login dialog. As another example, the XcodeGhost malware can read and write data in the user's clipboard, which would allow it to snatch a password."
This discussion has been archived. No new comments can be posted.

Apple XcodeGhost Malware More Malicious Than Originally Reported

Comments Filter:
  • by Anonymous Coward on Tuesday September 22, 2015 @12:56PM (#50576415)
    Seriously. Xcode is beer as in free, yes it used to cost $5 many years ago because of weird accounting but that was a long time ago. Why would anyone ever download Xcode from the Apple Developer web site or the Mac App Store?
    • Re: (Score:2, Informative)

      by Anonymous Coward
      As all the stories clearly said it was because it took a long time to download via official channels so they went with an unofficial one which had local servers and much better speed. In hindsight a bad decision but at least you can see why someone would consider it.

      On another topic, the headline is too long. It can be shortened to Apple more malicious than originally reported.
      • Re: (Score:3, Insightful)

        by Hattmannen ( 658936 )
        Slow download and installation using the official channels does not even begin to describe it. I did some work in Xcode this spring. Two and a half hours it took to install the bloody thing even with a quick and stable connection.
        Two days later I had to install a new update to be able to continue my work. Thankfully that only took slightly more than an hour.
        In hindsight it was a good thing that I didn't grab it from an unofficial source, but man, was it ever so tempting.
        • Slow download and installation using the official channels does not even begin to describe it. I did some work in Xcode this spring. Two and a half hours it took to install the bloody thing even with a quick and stable connection. Two days later I had to install a new update to be able to continue my work. Thankfully that only took slightly more than an hour. In hindsight it was a good thing that I didn't grab it from an unofficial source, but man, was it ever so tempting.

          I guess you've never installed Visual Studio, then. Even from a DVD it is quite a long process.

        • by Gr8Apes ( 679165 )
          XCode only took 5-10 minutes to download and install, even on a really crappy broadband connection. Yes, it's 1.5GB. But at even 1.5Mbps average download it's just a shade over 2 hours. So how bad exactly was your "quick and stable connection" since every cable and fiber connection advertises speeds in excess of 10 Mbps these days in the US?
        • Slow installation of Xcode? Xcode doesn't have an installer. You either download the app and copy it to wherever via drag and drop or grab it from the Mac App Store.

    • by k2r ( 255754 )

      > Why would anyone ever download Xcode from the Apple Developer web site or the Mac App Store?

      I think the current theory is that the big firewall of china made the download so slow that people used local copies.

    • it used to cost $5 many years ago because of weird accounting

      I bet you also believed the line about OS X updates having to cost money because of the Sarbanes Oxley Act.

      Apple charges what they do because people pay. There is absolutely no accounting or SARBOX voodoo involved.

      • it used to cost $5 many years ago because of weird accounting

        I bet you also believed the line about OS X updates having to cost money because of the Sarbanes Oxley Act.

        Apple charges what they do because people pay. There is absolutely no accounting or SARBOX voodoo involved.

        Actually, that would be a SEXCONKER OXSHIT ACT issue, because you just made it up.

    • yawn. This is vaguely interesting in the sense it's novel for using a ken Thompson compiler attack. But it's not an apple problem but a cheapskate developer problem . Morons saved themselves $99 dollars and use unsigned non apple compilers. Dumbasses. Apple just figured out there's dumbasses submitting code. Should be easy to detect non official compilers in the future I would think.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        NO. NO. NO. It isn't even a cheapskate developer problem.

        They did not save themselves $99. They saved nothing except the time it took to download from Apple's servers vs local China servers.

        To submit an app, you have to pay. To download Xcode, you do not have to do so. So if their app is in the app store, no matter where they got the dev environment, they had to pay to submit an app (or any number of apps).

        It is a stupid developer problem, OR a smart Chinese government who slowed downloads via the great

      • yawn. This is vaguely interesting in the sense it's novel for using a ken Thompson compiler attack. But it's not an apple problem but a cheapskate developer problem . Morons saved themselves $99 dollars and use unsigned non apple compilers. Dumbasses. Apple just figured out there's dumbasses submitting code. Should be easy to detect non official compilers in the future I would think.

        They didn't save themselves $99 (631 Yuan). XCode is FREE; the Developer License costs money.

      • by Rosyna ( 80334 )

        It's not that they were trying to bypass a payment (Xcode is free to download). It's that Apple's severs are just so damn slow if you can't get access to their content distribution network. Sadly, this is pretty much the case of everyone in China due to the Great firewall of China that strangles access to non-China networks.

        It also used to be true if you used Google DNS because previous primary Apple's CDN, Akamai, used DNS to route traffic. In that case, many developers would rather use BitTorrent to grab

    • Seriously. Why would anyone ever download Xcode from the Apple Developer web site or the Mac App Store?

      So they can get a clean version of Xcode?

  • by Rosyna ( 80334 ) on Tuesday September 22, 2015 @12:57PM (#50576421) Homepage

    It's actually the opposite. It's much, much less malicious that people say. The source code [github.com] is available.

    For one, it cannot be used for phishing attacks. The UIAlertView is shows [github.com] has no text input fields and it never attempts to get anything from the dialog other than the integer value of the button that was pressed.

    It also cannot get the UDID of the device because it uses -identifierForVendor which is a UUID that is specific to that specific app, so it can't be used to track users. iOS can and will change it.

    It can't be used to dial premium services either as iOS always shows a dialog when opening telephone URLs and iOS 9 always shows a dialog when using URLs that open another app. But the fact it can open Twitter so what? It can't do anything with that. It can't control Twitter.

    This functionality was actually designed to open the App Store so the user can review/rate the app or to show users similar apps.

    It's even significantly less bad than most ad/analytics packages.

    • The use of [[UIDevice currentDevice] name] and [[UIDevice currentDevice] identifierForVendor] (as well as several other pieces of information including App Name, App Version, OS Version, Language, Device Type, Location, etc.) are enough to not only create a generated Unique ID for each device to track on the analytic side but also all of the Apps infected by the malicious code.

      The people tracking the smartphones do not need the actual local device UUID if they can get enough information to generate their
      • The name might be (although it's easy to change it to an arbitrary value in Settings -> General -> About and can't really be considered a unique value), but the identifierForVendor [apple.com] is not. It's only the same for apps with the same bundle ID prefix on a device (apps from the same developer). Different infected apps will have entirely different identifiers.

        • Having a UUID on a per Application or Developer basis is in fact better for the attacker. Then they can carefully create a phishing dialog that fits in with the design or behavior of that particular App or package and then associate any information garnered from the user to the particular device and app installation.

          Without the altered library inside the actual app, they cannot do this because apps are jailed (or whatever Apple calls it).
          • by Rosyna ( 80334 )

            They have the app name, there's no reason to do that with a UUID

            But as I mentioned before, there's no phishing support in XcodeGhost as their use of UIAlertView doesn't allow for any text input fields. Even if a different malware tried to phish with a fake dialog, real Apple ID password dialogs on iOS never have a blank entry for the username, it's always part of the dialog text because iOS knows what your Apple ID is. This makes it significantly easier to not be fooled by just taking a cursory glance of th

    • Ok, I read the article you linked to. Very interesting.

      What I do not understand is how the source code was "found". I understand how to use a disassembler, but that would not yield such readable code.

      Can you comment on this?

      Thanks for linking to the article.

      • I think I answered my own question, and the answer is obvious:

        They distributed this malicious program as an SDK with source code inside the Xcode install. So it's not just a binary library that gets linked against, it's the code too. Is that correct?

      • The author of XcodeGhost released the source after they heard what was happening. It includes an apology at the bottom [github.com] (in Chinese) that makes it seem like it was just a proof of concept and he had no intention of it getting out but was picked up and spread via Baidu by others.

        The PoC angle would explain why it looks so damn much like any other basic analytics package. This is also likely why Apple's app scanners didn't pick it up, it doesn't do anything that's not permitted. The only weirdness is that it t

  • The real story is OS X and somehow Apple getting signed code wrong. Maybe some folks had a connection that was super slow and had trouble getting XCode directly from Apple.

    However, presumably, the people using XCode are developers. And somehow, they managed to install software that was presumably not properly signed.

    Which really makes one worry about the state of mobile development.

    On the other hand, the fact that one could build apps, compile them a little bit different and slip them into the app store i

C makes it easy for you to shoot yourself in the foot. C++ makes that harder, but when you do, it blows away your whole leg. -- Bjarne Stroustrup

Working...