"Reflections on Trusting Trust" – Some Thoughts on the XcodeGhost Incident


Authors: Tianfang Guo, Jinjian Zhai

(Further reading about the XcodeGhost: the original story and detailed analysis)

Reflections on Trusting Trust

In 1984, Ken Thompson, “Father of Unix”, mentioned in his speech about the first compiler backdoor he once made, which allows him to login with “su” privilege into any Unix systems in the Bell lab in the 1970s. To find this backdoor, his colleges reviewed the source code of Unix and found nothing.  They have never suspected it’s the compiler that planted the backdoor. The author, who wrote Apple’s App Store Infected with XcodeGhost malware in China” believes that Ken is telling us, before searching for security holes, one should first be clear about which party he could and couldn’t trust,  thus Ken named that speech “Reflections on Trusting Trust”.

And 30 years later, we witnessed the consequences of “Trusting UnTrust” – everyone gave enough alertness to the apps, but gave unconditional trust to the compiler which builds apps. As a result, the XCodeGhost infected more than 4000 apps on the iOS App Store, according to FireEye.

The injected malicious code could upload the victim’s privacy to a remote server, it could also pop up message boxes upon server request, which can be potentially used for phishing or attracting users to download more malicious apps. Luckily the last functionality seemed not been used till the C&C server was shutdown. Yet it would have been still possible for an attacker from world-wide-web to hijack the HTTP traffic and reactivate this backdoor.

Screen Shot 2015-09-22 at 7.47.47 PM
Screen Shot 2015-09-22 at 7.48.29 PM

Apple has also reacted to this incidence by pulling off 400+ infected apps:

The XcodeGhost is the first successful example of distributing large number of malwares into the iOS App Store. The impact rose many questions.

Who’s at fault?
Most victims are from China , thus it took days to download the Xcode in China from the official source. Some places were suffering from frequent disconnections (not sure if it was caused by Great Fire Wall), making a complete download the mission impossible. On the other hand the local download links could be easily found in developer communities and were conveniently hosted by Chinese cloud storage vendors such as Baidu. The hacker apparently took advantage of the situation to launch such attack. Like Ken’s story in 1970s, people fully trusted the infected build environment which is distributed via the peer-to-peer downloading channels.

What surprised us is, despite the individual developers, even the largest players in the industry were not survived, e.g. Tencent. The large companies certainly have the condition to download their IDEs from official sites, e.g. using a Virtual Privacy Network. Lazy or ignorance? Apple could also have deployed their CDN servers in China, but they choose to ignore the developers from their 2nd largest market.

Also, repackaging a signed dmg file should not be an easy job on OS X . After 10.7.5, the Gatekeeper mechanism is introduced, which will verify an app’s file digests upon the first launch. In this case, Adding or modifying the files in a dmg will cause verification failure and rejection.

The Gatekeeper is turned on by default. According to our survey, most iOS developers has turned it off, some said it’s for the convenience of adding 3rd party extensions to Xcode.


Is it over?

There are follow-ups about this incident: the Unity framework distributed in China has also been found infected. The samples have the same malicious logic. The only difference is the domain names of the C&C servers.

Technically, the Android IDE is as fragile as Xcode under an attack of compilers. As is shown below, on all the fundamental Java packages are under the /lib folder of the project. It’s entirely possible to inject the malicious code into one of them, and to repackage the installation dmg of Android Studio. As a result all the APKs built by the Studio ( including the IDE ) will be infected.

Trustlook is closely watching the similar attacks on Android. We will update the blog if we found any infected frameworks.

Screen Shot 2015-09-23 at 1.15.46 AM

Android signature verification vulnerability and exploitation

Authors: Tianfang Guo, Jinjian Zhai, Allan Zhang

“When you do not have the means to attack your enemy directly, then attack using the strength of another. Trick an ally into attacking him, bribe an official to turn traitor, or use the enemy’s own strength against him.”
– “Kill with a borrowed sword”, Thirty-Six Stratagems, Sun Tzu

After showing the “master key” and “FakeID” vulnerabilities in Android’s signature verification, today we demonstrate a new vulnerability. This was first discovered by Alibaba’s security team and disclosed at BlackHat Mobile Security Summit 2015.

In this article we will highlight one of the major vulnerabilities in Android signature verification, and demonstrate a new way to exploit this vulnerability- “To kill with a borrowed sword.” Namely, getting AntiVirus software to remove an innocent target app.

Android’s signature mechanism

Android is decentralized not only in its system, but also in its app distribution. To ensure an app’s integrity and traceability, Android enforces that all apps must be signed by the developer’s’ private key. After being signed, an app will be linked to the developer with that developer’s public key (or certificate). Thus, any changes in the package will result in signature verification failure and rejection upon installation.

Screen Shot 2015-09-02 at 5.39.33 PM

The signature verification process is shown in the figure above. Each file in the package will generate a digest using the SHA-1 hash function. Afterwards, they will be encrypted by the developer’s private key and put into the certificate file (ended with .RSA or .DSA depending on the public key algorithm). Without the developer’s private key, nobody could forge or modify any file.

Screen Shot 2015-09-03 at 11.52.14 AM

SHA1 digests for the files in CERT.SF file in the META-INFO folder.

The vulnerability

There is a loophole in the Android’s signature mechanism: any file containing the APK file’s digest can not also be included in the file digest list.

This is obvious: it’s difficult to generate a file containing its own SHA-1 hash. In other words, finding a hash(AB) = A is undoable. So the digest summary file, CERT.SF, cannot contain its own SHA1 digest.

Let’s look in detail about how Android handles this dilemma:

In Android OS source code: libcore/luni/src/main/java/java/util/jar/JarFile.java
Screen Shot 2015-09-03 at 12.10.33 PM

Any file ending with .SF, .DSA, .RSA or .EC, and those in the META-INFO folder, will be ignored when verifying the signature. That gives attackers a chance to put arbitrary files into the package without breaking the signature verification.

To launch an attack:

1. Prepare a malware file (e.g. the EICAR malware test file which can be identified by most AntiVirus vendors), and the APK you would like the AVs to remove.

2. Unzip the APK, put the malware file into the META-INFO folder, and zip it back. Due to the vulnerability, you now have a APK file which contains malware components, yet one that can still be identified as legit by the certificate verification.

3. Replace the original APK on the user’s phone. You need a 3rd party app to download the repacked APK from the Internet, and fool the user with an “upgrade notification”. Then the upgrade activity should be launched by the new Intent:

Intent intent = new Intent(Intent.ACTION_VIEW);
intent.setDataAndType(Uri.fromFile(new File(“[repacked APK path]")), "application/vnd.android.package-archive");

Even when the version of the repackaged APK is the same as the original APK, the repackaged one can still replace the original one.

4. Additional Attack: If the repacked APK is uploaded to Android app vendors, it will be identified as written by the original developer instead of repackaged by an attacker. If the designated Android market scans viruses before publishing, the original developer might be put in trouble because the repackaged app signed by their certificate contains malware (namely, the EICAR malware testing file).

The Proof of Concept video can be found in the link below, where the genuine ‘Angry Birds 2’ app is replaced by the repackaged app containing malware. Then the McAfee Anti-Virus software – with its signature based detection – identified it as malware:

To fix it

To fix this vulnerability, the digest files cannot simply be skipped when calculating the digest – at least not skipped by file extension or folder name. To solve the self-digest conflict, here is a simple idea: fill the self-digest with 0x00 before calculating the SHA1 of CERT.SF files:

Untitled drawing (6)

Through this approach, no file would be ignored: every file would be verified against the digest list. Any new file additions would cause an authentication error.