Toutes les vulnérabilités
HIGHSupply chainexploited in the wildcurated

SC-XCODEGHOST-2015

Build system · Xcode (compromised compiler)

Résumé

XcodeGhost, uncovered in September 2015, was the first major malware outbreak inside Apple's tightly controlled App Store, and the developers who spread it had no idea they were doing it. In China, where downloading Apple's 3-gigabyte Xcode tool from Apple's servers was painfully slow, many developers grabbed it from faster local mirrors instead. Some of those mirrors served a tampered version that secretly injected malware into every iOS app built with it. The infected apps, including giants like WeChat, sailed through App Store review and reached 128 million users. It is the lesson that your build tools are part of your software, and that a compromised compiler poisons everything it touches.

How it happened

Xcode is the tool every iOS app is compiled with, and it is large, around 3 gigabytes. Downloading it from Apple's servers was slow in China, so developers routinely fetched it from faster domestic mirrors (hosted on services like Baidu). Attackers uploaded a counterfeit version, dubbed XcodeGhost, to those mirrors. It did not modify the compiler binary; instead it slipped a malicious CoreServices object file into one of Xcode's default framework search paths, so Xcode automatically linked it into every app at compile time, without the developer's knowledge or consent.

Those infected apps were then submitted to the App Store, where they passed Apple's review, because the malware was subtle and Apple was not looking for compiler-injected code, and shipped to users as trusted, signed apps. Once installed, the payload phoned home to command-and-control servers with names that mimicked Apple infrastructure (like init.icloud-analysis.com), uploaded device and app details, and could read and write the clipboard, open arbitrary URLs, and pop fake alert dialogs capable of phishing credentials. The developers had become unwitting distributors of malware simply by using a tampered tool from an unofficial source. It is a supply-chain attack on the compiler itself.

The damage

Internal Apple emails later revealed in the Epic v. Apple trial put the reach at 128 million users (about 18 million in the US) across more than 2,500 affected apps that had been downloaded over 203 million times, among them WeChat (China's dominant super-app), the ride-hailing app Didi, and the business-card scanner CamCard. It was the largest App Store malware incident ever and it shattered the assumption that Apple's walled garden was inherently malware-proof. Apple removed the affected apps and notified developers, but, the same emails showed, decided against individually emailing the 128 million affected users. A later variant, XcodeGhost S, switched its command channel to HTTPS to evade detection and lingered in enterprises for months after disclosure.

Why XcodeGhost still matters

It is the poisoned-compiler supply-chain attack, proof that the build toolchain is part of your trust boundary, the same lesson taught by the CCleaner compromise and by Curve's compiler bug. Developers introduced malware into their own apps just by using a counterfeit tool. The defences are straightforward and still ignored under deadline pressure: download build tools, SDKs, and compilers only from official sources and verify their checksums or signatures; treat the compiler and build environment as trusted supply chain by isolating and controlling it; compare built artifacts against what your source should produce, so injected code shows up; and give developers a fast, official internal mirror so there is no temptation to reach for an untrusted one.

Comment le corriger

  • Rebuild every app with a clean, verified copy of Xcode from Apple and ship updated versions; assume any app built with the counterfeit tool is infected.
  • Notify users of affected apps and rotate anything the malware could have captured, such as credentials entered into fake prompts.
  • Audit where build tools came from across the team and remove any obtained from unofficial mirrors.

Comment l’éviter

  • Download build tools, SDKs, and compilers only from official sources, and verify checksums or signatures before use; speed from an unofficial mirror is never worth authenticity.
  • Treat the compiler and build environment as part of your trusted supply chain: isolate it, control what runs in it, and verify the toolchain's integrity.
  • Compare built artifacts against what the source should produce, so injected code that is not in your source becomes visible.
  • Provide developers a fast, official, internal mirror so there is no incentive to reach for an untrusted one.

Références

Vulnérabilités liées

Tout Supply chain →