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 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.

Follow @NakedSecurity

Follow @duckblog

Image of ghost and pumpkin courtesy of Shutterstock.