Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Hm. I had CamScanner on my phone a long time ago. Months ago. Maybe used once or twice. Can't think of any suspect iOS prompts offhand. Would be a lot of passwords to have to reset...
 
If infected apps can pass through Apple's iOS app gates it undercuts Apple's security rational for insisting on a Walled Garden.

Admittedly I know zip about coding but seems Apple is betraying it's users here and could have avoided this situation. I Hopefully this is a wake up call.
 
Seriously what developer who knows anything about security is going to download an IDE from a non official source?

That's like downloading an OS from The Pirate Bay and being shocked the file was injected with malicious code.
not sure why you quoted me. here my 2 cents.

The users do not know what IDE is or what is the compiler is (it is NOT required for them to know).

it is app store and app's vetting process of apps broken.
 
Mercury - if it is the web browser - that is huge. Mercury is on a lot of devices.

I wish there was a link to the apps in this list, as you're right - Mercury is quite popular and used a lot in the US. Though there has only been one recent update - Sep 3 - before that Jul 31.

Being a web browser, it has a greater chance of the clipboard having a password if using a password manager to copy/paste passwords into it. :(
 
If this only affects past versions of some apps, it would be nice to know exactly which version #s of each app are affected.

EDIT: For WeChat at least, it seems we do know that! The source document says 6.2.6 is fixed. (Although using ANYTHING from Tencent sounds risky, if they're willing to use developer tools downloaded from untrusted servers instead of from Apple. Big company... can't get the real tools?)
 
Last edited:
If infected apps can pass through Apple's iOS app gates it undercuts Apple's security rational for insisting on a Walled Garden.
No, it doesn't, because once Apple recognizes that kind of a problem, they can also fix it from that one central location. Without that "walled garden" approach, every user would now have to install a malware scanner and hope that it will get updated with profiles for the new malware.
Admittedly I know zip about coding but seems Apple is betraying it's users here and could have avoided this situation. I Hopefully this is a wake up call.
How could Apple have avoided that situation? How did Apple betray its users? Apple did not force anyone to download a compromised Xcode version. The only "mistake" Apple made was not to recognize the malware in the review process. But that is hardly trivial.

Oh, no I just realized that you already said "I have no clue about the topic at hand, but I will make unfounded claims!"
 
So... It begins.

iOS has been breached through the one thing that kept us safe. The App Store.

I don't think that's a correct analysis of the situation.
What has really happened here? Developers have used the wrong tool (we'll discuss that later) and that tool has embedded some unwanted additional code in their apps. BUT look what still worked
- each broken app STILL has to be submitted to the app store, with identification and an audit trail

- even when the app is on an iOS device, there are severe limits to what it can do. It still can't break out of the OS protections, randomly control the device, etc. The type of info being sent back to base is, let's face it, not THAT serious --- not ideal, but not control of the machine.

- The items that ARE problematic (and which Apple should work on fixing) are items that were problematic before we knew about this, and that have been used in other contexts --- the ability to phish for passwords by throwing up fake dialog boxes, and the way the current sandboxing FORCES Password apps like 1Password to transfer data over the Clipboard.

What this REALLY provides is a way to throw out a bunch of these phishing scams in a way that can't be traced back to the real scammer; only to the developer using the wrong tool.

Which gets us to that issue. I don't know enough about XCode to know what was and was not breached on that front. Obviously the entire XCode package should be signed, and obviously if you're stupid enough to install an XCode package that complains about being unsigned, you're setting yourself up for trouble. But blaming the victim, especially when the security landscape changes every year is not helpful --- how could Apple do better?
You can't really avoid people being able to write their own compilers and dev tools, and you can't stop those dev tools from doing god knows what to the code they create --- this has been known since Pike's infamous C compiler of the early seventies.
What you SHOULD be able to do is not allow code that has been created by such dev tools into the app store. THAT seems to be the flaw that needs to be fixed --- that any tool that's generating binaries that will land up in the store needs to be provably signed. But I don't know how feasible that is. Obviously the last stage (the actual store submitter app) is provided by Apple and signed, and using the developers signature. But what about the linker beforehand? And the compiler before that? And you then need the binaries passed between the two to be encrypted? It's just totally inimical to the current expected model of how we code.

So what about at a higher level? Do something that's a ugly hack, but basically FORCE that any installer that calls itself "XCode" has to be signed no matter what? That's one package that you can't install regardless of your GateKeeper settings except from Apple. But then you get a wack-a-mole of packages called "XCode 7" and "XCode!" and "XCode Pro".
 
If this only affects past versions of some apps, it would be nice to know exactly which version #s of each app are affected.

EDIT: For WeChat at least, it seems we do know that! The source document says 6.2.6 is fixed.
Yep, Data Monitor is still there too. Last updated in 2014. I certainly hope Apple is on the case and will address this asap.
 
I don't think that's a correct analysis of the situation.
What has really happened here? Developers have used the wrong tool (we'll discuss that later) and that tool has embedded some unwanted additional code in their apps. BUT look what still worked
- each broken app STILL has to be submitted to the app store, with identification and an audit trail

- even when the app is on an iOS device, there are severe limits to what it can do. It still can't break out of the OS protections, randomly control the device, etc. The type of info being sent back to base is, let's face it, not THAT serious --- not ideal, but not control of the machine.

- The items that ARE problematic (and which Apple should work on fixing) are items that were problematic before we knew about this, and that have been used in other contexts --- the ability to phish for passwords by throwing up fake dialog boxes, and the way the current sandboxing FORCES Password apps like 1Password to transfer data over the Clipboard.

What this REALLY provides is a way to throw out a bunch of these phishing scams in a way that can't be traced back to the real scammer; only to the developer using the wrong tool.

Which gets us to that issue. I don't know enough about XCode to know what was and was not breached on that front. Obviously the entire XCode package should be signed, and obviously if you're stupid enough to install an XCode package that complains about being unsigned, you're setting yourself up for trouble. But blaming the victim, especially when the security landscape changes every year is not helpful --- how could Apple do better?
You can't really avoid people being able to write their own compilers and dev tools, and you can't stop those dev tools from doing god knows what to the code they create --- this has been known since Pike's infamous C compiler of the early seventies.
What you SHOULD be able to do is not allow code that has been created by such dev tools into the app store. THAT seems to be the flaw that needs to be fixed --- that any tool that's generating binaries that will land up in the store needs to be provably signed. But I don't know how feasible that is. Obviously the last stage (the actual store submitter app) is provided by Apple and signed, and using the developers signature. But what about the linker beforehand? And the compiler before that? And you then need the binaries passed between the two to be encrypted? It's just totally inimical to the current expected model of how we code.

So what about at a higher level? Do something that's a ugly hack, but basically FORCE that any installer that calls itself "XCode" has to be signed no matter what? That's one package that you can't install regardless of your GateKeeper settings except from Apple. But then you get a wack-a-mole of packages called "XCode 7" and "XCode!" and "XCode Pro".

Good analysis, but there is something Apple could have done, and I have been saying as much for over a year. Here's the more strongly worded one:

They should ban their in-house teams from throwing up a password request box. Absolute ban. It has got out of hand recently with stock apps asking for the password without any justification or explanation and pretty much at random. I've said it over and over, Apple have been training their users for exactly this scenario - enter password whenever anyone asks. If an app needs the iCloud password it should instruct the user to enter it in the appropriate settings page. Train users: only the settings app should be trusted with passwords.
 
Last edited:
How could Apple have avoided that situation? How did Apple betray its users? Apple did not force anyone to download a compromised Xcode version.
  • Apple could provide significantly better download speeds from the official source to the affected locations. That way developers would have no reason to go with unofficial sources.
  • Alternatively Apple could provide an official checksum and a list of localised mirror servers. That way developers resorting to unofficial mirrors or whatever unofficial source they want, still have the chance of checking the file and verify its validity.
That said, I wouldn't exactly call the lack of these solutions a "betrayal"...
 
Yep, Data Monitor is still there too. Last updated in 2014. I certainly hope Apple is on the case and will address this asap.

It's on Apple to pull those apps immediately, and ESPECIALLY to have ensured that the App Store back-end will NOT accept any submissions from a modified Xcode. I wonder if there's a mechanism in place for that already, and some security hole will emerge that has broken the mechanism? Either way... Apple's problem to deal with.

(It may be interesting in a few days to see what further details there are.... I can't think of an Apple security scandal that was ever QUITE what it first seemed to be.)
 
Why would anyone download Xcode from anyone other than directly from Apple? Even if the download is slower it can't be worth getting a compromised developer tool.
Because the connection is very slow and Xcode download is very large. But makes me wonder why Apple doesn't make these downloads available from Chinese servers (I assume they don't).
All traffic from China to the world outside of China goes through the great Chinese firewall. One reason why every connection is slow.
 
  • Like
Reactions: V.K.
the way the current sandboxing FORCES Password apps like 1Password to transfer data over the Clipboard.

Not as much of a problem any more since iOS 8. The most frequent case of copying passwords — browsers — will use an extension now. Other apps are slowly following suit.
 
I used WinZip on iOS :(

But i also bought it in the Mac App Store. Any guarantees that the Mac Version is not infected?
 
  • Like
Reactions: V.K.
My thought is I am all done with any company that would use an Xcode version they got from a file sharing site rather than Apple directly. I would never trust them again.
I feel the same way. It is incomprehensibly stupid. I don't care if it takes a week to download Xcode, as a professional developer that distributes applications to potentially millions of users, downloading from anywhere other than the source is just ridiculous. I'm shocked at WeChat. Never using that app again.
 
I don't care if it takes a week to download Xcode, as a professional developer that distributes applications to potentially millions of users, downloading from anywhere other than the source is just ridiculous.
It is irresponsible and unprofessional. Wouldn't mind if Apple remove those developers and their products completely from the app store.
 
If this only affects past versions of some apps, it would be nice to know exactly which version #s of each app are affected.

EDIT: For WeChat at least, it seems we do know that! The source document says 6.2.6 is fixed. (Although using ANYTHING from Tencent sounds risky, if they're willing to use developer tools downloaded from untrusted servers instead of from Apple. Big company... can't get the real tools?)
You'd be surprised by the amount of companies using pirated apps.
 
  • Like
Reactions: satcomer
Seriously what developer who knows anything about security is going to download an IDE from a non official source?

That's like downloading an OS from The Pirate Bay and being shocked the file was injected with malicious code.
I agree, that is absolutely ridiculous and shameful for those developers. And all to save a few minutes on the download? Come on. Go eat lunch while it downloads (that's what I do for Xcode updates) or do it overnight if necessary, but no good developer would download their main dev environment from any file sharing site. I'd say they deserve what they get but millions of users are going to pay the price for their laziness.

Also, users probably shouldn't be downloading things like "Wallpaper10000" from Chinese developers, but that's another matter. Some apps (WeChat) it's hard to tell, but a lot of apps just feel sketchy/scammy from the name alone.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.