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

Fallout from the Android Stagefright OTA Update: Trustlook Mobile Security Memory Boost Stays alive while other Task Management Apps are Left Disabled

Google addressed the Stagefright bug by solving and rapidly releasing the Android 5.1.1 Stagefright fix. However the fix broke the widely used “recent activity” log access for the developer community. As a result, the Stagefright “fix” disabled many popular task management, parental control and app-locker android applications. The Trustlook team moved quickly with a timely update of the Trustlook Mobile Security application. “Memory Boost”, our task management feature continued to work as normal for millions of our users while others’ remain disabled.

The Nexus 6 Phone screenshot below shows all is A-OK. Users can continue to keep their Android devices running in tip-top shape.

The story started from the Black-Hat 2015 (08/01-08/06), when an exploit called Stage-fright was revealed to the public as a threat to over 95% Android devices. The Stage-fright exploit utilizes the media-play library of Android operating system and executes malicious code embedded in multi-media files. Later on 08/12/2015, Google released the OTA for the stage-fright bug to fix Stage-fright.

Immediately after the users updated their Nexus 6 phones, they found:


As shown in the red box of the right-bottom part of the screenshot, the user of a famous Task Killer app with 50 Million to 100 Million download counts stated : “Latest update for Android 5.1.1 killed this app. …”

To further investigate the Android OTA update, we researched the top 10 Task Killer apps in Google Play and were shocked that ( as late as 08/14/2015 ) all apps which are supposed to kill other unauthorized processes were actually ‘disabled’ by the OTA update.

Here are a few examples of the most popular ones:

The aforementioned Advanced Task Killer App , which has more than 50 Million downloads:


Exactly as described by the review, the app failed to access any of the processes in the memory:



Here is another example:


Zapper Task Killer & Manager with more than 1 Million downloads was developed by a renowned mobile antivirus vendor. The process killer feature was blocked after the Android OTA update. Therefore, no process other than Zapper itself was recognized while several apps and games were still running in the operating system, which means that Zapper failed to access any recently apps, not to say forces them destroy.


The root cause of the problem is the new permission requirement of the ActivityManager.getRunningAppProcesses() method in Android 5.1.1 version. In the Android OTA update, the PERMISSION.REAL_GET_TASKS needs to be proposed and granted by user in order to get the full list of tasks and processes.


From this series of stories with Stagefright, OTA and Task Killer, we can see that : due to the open-sourced nature of the Android Open Source Project (AOSP), vulnerabilities and exploits were discovered only a few days ahead of the real zero-day attacks. Thus, the community is patching the Android operating system at a much faster speed and might require subsequent patches from the third party developers and antivirus vendors. In this evolving environment, the best strategy of Android users is:

1. to keep an keen eye on safety updates of both Android OS and Antivirus apps,

2. to always use the most updated versions to protect the devices and the data.


Please contact support@trustlook.com for comments.

Authors: Jinjian Zhai, Tianfang Guo, Weimin Ding, Wilson Ye




“The Clickers” – Zombie Malware that feed on the mobile ecosystem

Authors: Tianfang Guo, Jinjian Zhai; Special Thanks: Steven Chen

Last week, Trustlook exposed the Facebook credential phishing malware “Cowboy Adventure”. In the article we pointed out that phishing is one kind of behavior that is difficult to detect via an automated technical approach. This may be one reason it sneaked by the Google Play Store’s  “Bouncer” automated security check.

In this article, we will highlight several examples of Zombie malware on Google Play we very recently uncovered. These are Called  – “The “Clickers”.They commit another stealthy kind of malicious behavior, that  will likely be overlooked by automated analysis solutions.

“Clicker” is a malware that affects a large part of the mobile ecosystem creating fraud for the vendors, spamming the networks and exploiting the resources of user the community. This form of malware launches requests through Advertizing links. “Clickers” generate costly, false user traffic for advertisers, while draining the user’s battery life and consuming their monthly data plan bandwidth allowances. Everyone loses when a “Clicker” is unleashed.


Screen Shot 2015-07-13 at 3.46.01 PM

Screen Shot 2015-07-13 at 3.46.10 PM


The latest malware we detected is called “Best: Dubsmash”. It has no actual functionality other than a confusing UI. Most users are likely to spend some time to figure out what it does. In the mean time, let’s see what is doing in the background:

Screen Shot 2015-07-13 at 3.47.28 PM


Communicate a C&C server. This server will serve the target URL that needs users to click.

According to our test, this URL will give different URLs each time you refresh it. Most of the URLs are porn sites.

Screen Shot 2015-07-13 at 3.48.05 PM

Our behavioral analysis shows the Zombie requests are generated by using invisible webview calls, in a continuous 20s time interval. There goes the user’s battery life and bandwidth. data plan. Also it will (or rather should) create events on a properly monitored corporate network. Just what your SecOps team needs, right? More Spam remediation.

Screen Shot 2015-07-13 at 3.48.45 PM


As of Jul 13 PST 2:40PM, this app, as well as 3 similar “clickers” are still alive on Google Play. We already reported this issue to our colleagues at Google Play and will look forward to timely remediation.

Screen Shot 2015-07-13 at 6.50.16 PM

Meet the Most Successful Malware on Google Play: Nearly 1M Users in 4 Months

Authors: Tianfang Guo, Jinjian Zhai

How many users can a stealthy malware acquire after being published on Google Play? Hundreds? Thousands? We believe a new record has been established: 500k-1m downloads. This malware survived more than 4 months until the Trustlook research team uncovered it.

The holder of this dubious honor is a malware called “Cowboy Adventure”. It is a simple game made utilizing the popular 2D game engine “Platformer 2D”.  After careful analysis our team found a devious and scary reason behind its user growth.

Screen Shot 2015-07-02 at 10.49.50 AM
Screen Shot 2015-07-02 at 10.50.03 AM
Screen Shot 2015-07-07 at 4.37.06 PM


Beginning of the story

Days ago, we found some users are complaining about their Facebook accounts are abused, sending a game invite to all the friends. And most of them speak Chinese:

Screen Shot 2015-07-07 at 5.06.03 PMf493908d8528286f25d4a51818c8d45c-1

After analysis, we found the “Cowboy Adventure” is actually a phishing malware that forged into a game. It will forge a Facebook login, and collect users’ Facebook username/passwords. By spamming the victims’ friends, it spread virally. Moreover, the phishing behavior is committed “selectively”, only the IP address from Asia could trigger it.


The detailed analysis


Above is the fake Facebook login window. If you have basic knowledge about OAuth, you should know that no 3rd party could ask your FB account in this way.

The app is developed using Mono, the open-source, cross-platform implementation of Microsoft’s .NET Framework. The app’s code is written in C# and compiled to several PE dll files. We used the Telerik JustDecompile and ILSpy to decompile it.

The key code are from 2 dlls:

ThinkerAccountLibrary.dll – the component responsible for collect user information, including the Facebook accounts.
2015-07-06 22_39_50-ILSpy
CowboyAdventure.dll – the game’s code. Also it contains an entry activity that determines whether it pops up the phishing activity or not, based on user’s location.

Upon launching, the app will first communicate with a command & control server:
2015-07-06 22_38_07-ILSpy

The returning data will determine the app’s logic: directly start the game, or phishing the user via the fake Facebook login activity.

During our test, the return data is very tricky: the C&C server will determine whether to commit malicious behavior via the client IP. We tried access the URL using our IP in United States, the returning data is as follows, with the “LoginEnabled” value 0:
Screen Shot 2015-07-07 at 2.52.38 PM
In this case, the game will start without phishing.

However, if we access this URL via a proxy server from China Mainland, Hong Kong, Taiwan or S.E Asia, the return will be different:
Screen Shot 2015-07-07 at 4.04.55 PM

Note the “LoginEnable” value has changed to 1. In this case, the app will first pop-up the phishing activity. This probably a trick to delay the time it discovered by major Antivirus vendors outside Asia. (And it worked!)

Here is the our reversed engineered code showing its logic:
Untitled drawing -2-

The AppData class is for storing the data returned by C&C server. “LoginEnable” indicates whether to phishing, and “UrlHomePage” indicates the URL for submitting the users’ FB accounts.

As is shown below, in the apps main activity “HomeActivity”, the first activity shown to the user is decided by the value “LoginEnable”.

Cowboy2 -1-

After the phishing activity is popped up, and the victim input the Facebook account, the email/password will be sent to the URL specified in the C&C server’s returned JSON value “UrlHomePage”. The detailed logic is shown below:

Untitled drawing -3-

After the C&C server received the users’ Facebook account and password, we don’t know what exactly happened there. But we can guess: a automated script will use Facebook’s API to spread the malware among friend networks, attracting more and more victims.

Even at the time the author writing this article, there is ZERO AV vendor can detect this malware according to virustotal.com . The VirusTotal even gave a comment: “Probably harmless! There are strong indicators suggesting that this file is safe to use.”
Screen Shot 2015-07-07 at 3.02.31 PM
That is the story behind a “legendary” malware on Google Play, which infected nearly 1M phones in 4 months. According our analysis, there is no complicated technology used, just a little social engineering and a small trick to evade detection.


Some thoughts

We have to ask: what’s going wrong? The author’s opinion is as follows:

1. Mono is relatively a new development framework, thus good at evading analysis. This is not about difficulty, but cost-efficiency. As the Jar pack is still the majority of the Android threat source, few vendor integrates the Mono and C# code analysis into automated platforms.

2. Phishing is naturally difficult to detect via automated technical approaches. A phishing Facebook login activity has no difference to a normal login activity on code level. Only experienced human being can identify the forged images & layout.

3. The sneaky developer has set a location based triggering mechanism. This may fooled a lot of AV vendors outside Asia.

4. Some AV vendors have overly trust on Google Play. The slow reaction for AV vendors and the VirusTotal’s result is the best evidence. The app’s high-profile on Google Play might be a factor that made VirusTotal gave the “Probably harmless” comment. Also to our knowledge, some AV vendors gives more trust to the apps on Google Play during their automated analysis.


Update on Jul 9 3pm PST:

After more research, we found the conclusion of “the phishing only works for Asia IP” is incorrect. Now we found it actually affects anywhere except US and Canada.

0Day Malware, 0Day Detect


Authors: Tianfang Guo, Jinjian Zhai

The “Fake Amazon Giftcard” is a malware that has been breaking out in the last 48hrs. It’s pretty simple from the technical aspect, but has infected 4,000 devices and caused over 200,000 spam SMS worldwide in less than 24hrs (source: http://goo.gl/cFs2BG).

Let’s see what it can do:

    • The app presents itself into a “survey for giftcard” app to attract a user install.


    • After user has installed it, it will read the contact list, and send spam SMS, which includes a download link, to all the victim’s contacts. So it spreads like a worm.


Hey [contact name], I am sending you $200 Amazon Gift Card You can Claim it here : https://bit.ly/getAmazonReward

    • The app’s interface is a series of surveys based on a web view, which will collect a lot of the user’s private information – especially those who are greedy for the giftcard. Also, the app includes an Advert SDK, to generate more profit.


Trustlook has intercepted a sample from our user base yesterday, Mar 3rd, and the dynamic analysis sandbox gave us a detailed report within 2 minutes:

Screen Shot 2015-03-04 at 5.03.36 PM

Screen Shot 2015-03-04 at 5.07.26 PM

According to Virustotal, at the time of intercept, only 2 out of 57 Antivirus programs can identify it. After 24hrs, there are still 46 out of 57 AV programs blind to this simple malware. Nor is any AV program warning their users about the malicious link used to download the malware.

Screen Shot 2015-03-04 at 4.49.31 PM

Screen Shot 2015-03-04 at 4.37.42 PM

-Another example that shows the superiority of behavioral analysis in the modern mobile era.

Major Android Vulnerability, 75% Android Users Are "Abandoned"

Privacy Disaster is a major vulnerability on Android native browser component on the versions below 4.4. It’s a critical vulnerability because it shaken the foundation of client side web security: the same origin policy. By exploiting this vulnerability, an attacker could bypass the SOP protection and steal sensitive informations such as cookies and login credentials.

Q: How could a hacker exploit it? What’s the consequence?

A: Your Android version must below 4.4 (which occupies more than 75% of market share). If you unfortunately opened a malicious webpage using Android’s native browser or apps’ webview component, the attacker could extract your cookie from another website, which may contain personal data or login credentials. Also, the attacker is able to embed another good webpage in the malicious page, say Paypal, and manipulate the page’s source code to log your username and password when you are logging in.

Those malicious behaviors should never work if the Same Origin Policy mechanism works properly.

Screen Shot 2014-09-22 at 1.27.28 AM

Q: What is Same Origin Policy (SOP)?

A: “Same origin” here means the same domain, same port and same protocol. We can assume 2 pages have same owner if they matches the “same origin”. SOP is a basic client side protection mechanism on almost all browsers: JavaScript from one origin should not be able to access the properties of a website on another origin.

For instance, you own a webpage, and embedded an iframe pointing to an email login page inside the page (in this case, email is the child page, and your page is parent page). Suppose you write some JavaScript in the parent page, can these code manipulate the source code of the child email page? The answer is certainly no, your JS cannot access the page elements – including page source and cookies – from another domain. Otherwise the hacking would be fairly easy, how about modifying some code to post your password to somewhere else? Or open an invisible iframe pointing to a social media website, and then retrieve the cookie from the parent page?

Unfortunately, the nightmares became the reality, as the SOP on Android browser could be bypassed by “Privacy Disaster” vulnerability.


Q: What caused this vulnerability?

A: At first glance of this vulnerably, my reaction is like other security researchers: unbelievable. It’s a so critical mistake in the code: it seems the developer passed a wrong URL variable into the URL security check, and rendered the check meaningless. Here are the 2 major fixes on the AOSP (Android Open Source Project): 1368e05e8875f00e8d2529fe6050d08b55ea4d87 7e4405a7a12750ee27325f065b9825c25b40598c

Q: How do I defend against it?

A: The best way is to upgrade your Android to 4.4, however it’s not doable for everyone. Moreover, the default browser cannot be uninstalled, neither can you evade the webviews that widely used among apps. It’s hard to patch or mitigate, that’s why we say 75% users are “abandoned”. The best suggestion we could give you is to be careful clicking an untrusted URL or installing a suspicious app. Nevertheless, even the URL points to a trusted source, it is possible that a network attacker hijacks the traffic and redirect your HTTP requests to a malicious source.

Trustlook is still working on the solution via 3rd party security softwares. We’ll keep you updated.