Slashdot Mirror


Over 225,000 Apple Accounts Compromised Via iOS Malware

An anonymous reader writes: Researchers from Palo Alto Networks and WeipTech have unearthed a scheme that resulted in the largest known Apple account theft caused by malware. All in all, some 225,000 valid Apple accounts have been compromised. The theft is executed via variants of the KeyRaider iOS malware, which targets jailbroken iOS devices. Most of the victims are Chinese — the malware is distributed through third-party Cydia repositories in China — but users in other countries have also been affected (European countries, the U.S., Australia, South Korea, and so on). "The malware hooks system processes through MobileSubstrate, and steals Apple account usernames, passwords and device GUID by intercepting iTunes traffic on the device," Palo Alto researcher Claud Xiao explained. "KeyRaider steals Apple push notification service certificates and private keys, steals and shares App Store purchasing information, and disables local and remote unlocking functionalities on iPhones and iPads."

1 of 217 comments (clear)

  1. Re:Headline leaves out one very important detail by swillden · · Score: 5, Interesting

    I expect to be able to go in and out of my door. That's what doors are for. Apple doesn't even give you a door. You have to break your way through the wall. Then there's a hole there. That's why Apple products are only sufficient for sheep. They don't break down walls, they just wander through holes.

    It's worth pointing out that if you root your Android device you're doing the same thing, breaking through a wall. That's fine if it's what you want to do, but you are giving something up in terms of security.

    As a member of the Android security team, I'm involved in lots of discussions about lots of different threat models and attack vectors, and while we do think about trying to maintain security on rooted devices, I'd say that 90% of the time we end up deciding that we just can't, so "device is running an official image[*] and is not rooted" becomes a foundational assumption of the analysis.

    This isn't because rooting is inherently bad, or because we're trying to control user's devices, but because it's impossible to reason about security in a vacuum. You have to know what you can depend on. For example, we might argue that apps can't break out of their sandbox in a particular way because the information they need to do it is managed by a particular system daemon which validates access in a particular way... but in a rooted device that daemon may be modified, or simply bypassed. We just can't know that stuff is still working the way it's intended to. Some members of the modding community do an outstanding job of adding flexibility without breaking the security model, but many others don't.

    Ideally, devices should provide enough native flexibility to allow users to achieve what they want while staying entirely within the normal mode of operation. In the case of Android that means staying within Google's "walled garden": install apps only from the play store, keep Verify Apps enabled (and follow its recommendations), don't root, definitely don't disable SELinux, etc. Where that ideal fails, and users want to do stuff that can't be done in the garden, they should have the option of stepping out of it, and they should be able to do so in a progressive way, not all-or-none... but each step they take increases the probability that they'll change something that violates a security assumption and thereby increases their risk of compromise.

    I suspect that Apple security engineers even more strongly assume that devices are not jailbroken. That's just a guess, but it's consistent with the general philosophy of iOS and, if correct, it means that jailbreakers have even less expectation of security. iOS users also live in a software monoculture, which exacerbates the risk. (Android users get security benefits from ecosystem diversity, though there are obvious costs to that diversity as well. Including the update problem.)

    [*] Note that given the state of updates in the Android ecosystem, we often don't assume that the device is running an up to date system image. From our perspective that's often easier to work with than a rooted device because at least we know how it behaves and can look at trying to mitigate risks at other layers. We're also working on the update situation, but that's hard given the nature of the ecosystem.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.