It’s about six weeks since we first wrote about XcodeGhost.
That’s the Apple Mac malware that was specially created by crooks in China to create iOS malware.
You read that correctly.
Just as the infamous Stuxnet virus tried to infect PCs with the ultimate goal (allegedly) of indirectly infecting uranium centrifuge controllers, so XcodeGhost aims sneakily and indirectly for the App Store.
XcodeGhost was pretty successful, with many infected apps getting past Apple’s approval process.
Memories of Induc
The same sort of “infected toolkit” problem hit the Windows world back in 2009, when the Induc virus was found.
Induc targeted software developers who used the Delphi programming system.
The virus deliberately infected their Delphi installations, so that every Delphi program they compiled thereafter…
…contained a copy of Induc.
Fortunately, all Induc did was to spread – it didn’t steal data or try to phish passwords along the way.
But Delphi was widely used in IT departments around the world, because it was a slick and convenient tool for putting a modern-looking user interface in front of legacy back-end business software.
So Induc turned up in lots of official corporate software, often to the surprise (and occasionally the disbelieving denial) of the companies concerned.
Amusingly, if malware writing can ever be funny, numerous malware samples turned up with Induc infections, too.
That’s because Delphi was also popular in the cybercriminal community at the time, especially amongst the creators of password-stealing programs targeting online banking.
Enter XcodeGhost
XcodeGhost does something similar, though it isn’t strictly a virus.
It doesn’t spread by itself, but instead relies on the developer community to do the spreading on its behalf, typically following this sequence:
- Chinese cybercriminals produce a cooked remix of Apple’s Xcode development toolkit, a multi-gigabyte download that you usually get from the App Store. Xcode is free, so a pirated version sounds pointless, but the theory seems to be that the cooked versions are available locally from Chinese servers and are therefore promoted as faster and easier to download.
- The cooked version is, in fact, downright crooked, because the hackers mix in some “secret sauce” with their locally-sourced download.
- The Trojanised Xcode version indirectly infects iOS apps when they are compiled.
- The resulting infected iOS apps contain malware, buried in parts that look like Apple-supplied components.
Apple initially let many of these apps through App Store validation and into the App Store, presumably because the parts compiled from the vendor’s own source code were fine.
When the news first broke, Apple responded quickly, removing afflicted apps from the App Store, and vocally telling its developer community how to get a “real deal” version of Xcode downloaded and installed.
Not necessarily enough
But just refreshing your Xcode installation (from a non-dodgy source, of course!) and validating its digital signature isn’t necessarily enough.
Your build process may very well include third-party components, such as programming libraries or sub-programs, downloaded from other suppliers.
And if any of your suppliers has an XcodeGhost problem, then the code they compiled and shipped to you might have XcodeGhost buried in it.
Indeed, even if they had XcodeGhost but have now fixed their own infection problems, until they recompile their products and you download the new versions, you might still be building XcodeGhost infections into your own iOS apps.
The Possible Mobile story
That’s what happened to mobile development house Possible Mobile.
The company openly admits that its core motto is SHIP IT, but recently reported that it was having trouble living up to that promise.
It submitted an app to the App Store, only to have it bounce back almost immediately with a rather unhelpful, message from Apple:
Invalid Executable – The app in [REDACTED].app has been built with an unsupported version of Xcode. Make sure Gatekeeper is enabled, download the latest version of Xcode from developer.apple.com, rebuild the app, and submit it again.
But the executable was valid in the technical sense of being well-formed and able to run, and the company’s own source code in the app had been built with the latest version of Xcode.
And, as you can imagine, following Apple’s advice didn’t solve the problem, thanks to components in the app that weren’t built from source, but compiled in from infected third party libraries.
What to do?
- Don’t blindly trust third party libraries. After a scare like XcodeGhost, you need to review your supply chain, as well as your own development tools.
- Consider using an OS X anti-virus. Many Mac users still pooh-pooh anti-malware software, considering malicious code to be “a Windows problem,” and assuming that the low amount of Mac malware means that the risk can largely be ignored.
Possible Mobile’s story has an extra twist that is a tricky issue for developers whose job includes integrating and shipping pre-compiled core components provided by paying customers.
Sometimes, you may need to go back to your paying customers and say, “We think the infection actually comes from you.”
Here at Sophos, we faced that very problem during the Induc outbreak on Windows, with some corporate IT teams complaining that we were falsely reporting the virus in their software, “because it was developed and built in-house and thus can’t possibly be infected.”
But, as we are seeing once again, the fact that a program came from a trusted developer, and was built from trusted source code, doesn’t necessarily mean that you will end up with a trusted product.
As we suggested when XcodeGhost first appeared:
Perhaps App Store submissions will require full source code in future? You compile it; Apple compiles it; if and only if the two packages agree, your App goes forward for further analysis.
We imagine there would be an outcry if Apple were to enforce this – What? Share everything with Apple, even my source code? But so-called double-compilation is a respectable approach to countering the problem of trusting trust.
It would certainly help to confirm that both third-party developers and Apple were singing from the same code generation hymn-sheet.
Sophos products detect and block XcodeGhost variants under the family name iPh/XcdGhost-*. At the time of writing [2015-11-09T12:00Z], variant letters -A to -F are known.
Sophos Anti-Virus for Mac Home Edition
Want to keep an eye out for malware, malicious web links and other threats to your beloved Mac?
Whether you are a developer or not, Sophos Anti-Virus for Mac Home Edition is 100% free (email address required), with no expiry and no time limit on updates.
Sophos for Mac also stops threats for Windows too, so it even protects non-Mac users you share files with.
Choose from blocking viruses in real time (on-access protection), scanning at scheduled times, or running a check whenever you want.
Image of ghost and pumpkin courtesy of Shutterstock.
David C.
Of course, what would be the actual point of double-compilation? If you submit source code, then let Apple compile it and ship that.
If they produce a different app, then your proposal would reject it, and if they’re the same, then one of the two copies is redundant.
Paul Ducklin
The idea of submitting source code is not simply to let someone else compile and ship it, but to validate that two separate build environments can produce the same binary. Neither copy is redundant if the purpose of making two copies isto verify that they come out the same :-)
If Apple compiled it and it came out different to yours – the version you’d tested – then, yes, indeed, my proposal would reject it. That’s the whole idea, because it implies that there is an unexplained and unauthorised difference in the two build systems.
Laurence Marks
I don’t get it. If anti-virus detects XcodeGhost, then why don’t the development shops simply run AV on their compiled product and simply replace/refresh libraries/components until they get a clean build?
Paul Ducklin
I was hoping someone other than I would ask that :-) Possible Mobile, ironically, ended up sort of re-inventing their own anti-virus, using the detection techniques of the late 1980s (in fact, they used ‘grep’).
However, the underying problem and advice remains: when your development ecosystem is invaded by untrusted build tools, recompiling from source may not fix the problem (because the malware might get compiled back in) *and* relinking with binary libraries may not fix the problem either (because the malware might already be compiled in).
Nick Arnott (@noir)
Our environment did not have XcodeGhost in it. We had a third-party framework that had been compiled with XcodeGhost by another vendor and provided to us for inclusion in an app. Sophos AV does not appear to detect the infected framework as a threat.
Paul Ducklin
My point was that if you’re embedding someone else’s framework in your app as part of your build process…that framework is in your environment.
If you couldn’t detect the pre-build framework with Sophos…I’d be really happy if you could send us (or upload) a sample, though I fully understand if you no longer have it :-)
For “how to get it to us and what to send,” feel free to email me personally (duck at sophos dot com).
Jean Walker
How does a user who has unwittingly installed an XcodeGhost-infected app on her iPhone uninstall such an app from their phone? Is there an anti-XcodeGhost app that can be downloaded to the phone through iTunes?
Paul Ducklin
By now, you’d hope that the vendor would have pushed out an update.
If on doubt, try asking each app’s vendor (or reviewing the app’s release notes).