Posted by & filed under News, vulnerability, zero-day.

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.

Posted by & filed under malware, News, vulnerability.

Activity hijacking is the mobile version of “phishing attack”. By poping a forged UI under certain circumstances, an attacker could hijack the user’s input flow and stole sensitive information, such as login credentials, payment informations and camera pictures.

Imagine those scenarios:

  • You opened a shopping app, finished purchase and clicked “checkout”. The app jumped to the payment UI. Then you input your credit card information.
  • You opened a email app. To add a new account, you clicked “login” and input your username and password.
  • You opened a banking app. To deposit a check, you clicked the scanning button and the camera presents. You took a photo of the check.

Those scenarios could all be exploited by an attacker. Researchers from UMich and UC Riverside have already proved they can successfully implement such attacks on all versions of Android system.

Here’s the PoC video:

The attack flow is:

      Victim installed and opened a malware.
      The malware launched a background service, monitoring the newly launched activity. E.g. by monitoring the logcat.
      The victim opened an target app. Launched a target activity. E.g. Opened a shopping app and jumped to the payment activity.
      The malware service immediately pops up a phishing activity, which looks totally the same as the original payment activity. The former one poped just on top of the later one.
      The victim mistakingly input the payment information on the fake activity, which will be later sent to the hacker.
hijacking checkpeeking

Why this attack is tricky?

Hard to detect –
For the user, if the fake activity is deceptive enough, the victim can hardly identify it; For the Antivirus, popping up an activity is legit in Android. Antivirus is good at detecting a technically malicious behavior but not a social engineering deception. A better way of identifying the phishing activity is needed.

No special permission needed for the malware – except the Internet permission to send the data out.

We are working on update the Trustlook Antivirus to mitigate this attack. Our approach is, if any background service pops up an activity, we will warn you “the current UI is opened by [service name]”.

Posted by & filed under News.


“Mobile tracker” is a default service on Samsung phones. Most Samsung users don’t know its existence. However, it does enabled on most of the Samsung products, we already confirmed the flollowing:

  • Samsung Galaxy S
  • Samsung Galaxy S2
  • Samsung Galaxy S3
  • Samsung Galaxy S4
  • Samsung Galaxy S5
  • Samsung Note I
  • Samsung Note II
  • Samsung Note III
  • Samsung Galaxy Note 8
  • Samsung Galaxy Note 10

Because of lacking proper identity check when binding the phone owner’s Samsung account, this feature could be easily abused by an attacker, and can be turned into a high privilege backdoor. All the hacker need is one minute of physical contact of your phone, such as using a fake charger.

Here is the Prove-of-Concept video:

An attacker could do the following using Samsung’s find my phone web portal (

  • Ring the device
  • Retrive the device location
  • Retrive the call logs
  • Wipe out all the data
  • Lock the device
  • Unlock the device (even with the passcode enabled)

Because the mobile tracker service is by default enabled as a system service, we suggest all Samsung users to bind your own Samsung account before the hacker does.

Posted by & filed under malware, News, potentially unwanted app, Virus.

In the last weekend, the Chinese medias are filled with a news “Super Android Virus In-the-Wild”. The consequence of this worm looks remarkable in the mobile virus history: from Jul 28 to Aug 2, it infected millions. And the writer of this malware, a talented 19-year old freshman, was arrested within 9 hours (because he hardcoded email account inside the app). The intent of making this malware was “showing off” and “spy on girlfriend”.

After we took a close look at this virus, we surprisingly found it a “Hello World” style malware: it contains basic control functionalities such as reading the SMS list (specified on e-shopping notifications). It has a simple but efficient way of spreading: reading the contact, and sending phishing SMS containing the APK download link to all the victim’s contacts, caused an exploding infection number.

There is no destructive functionality in this malware, nor does it generate profit for the writer. The only consequence is bugging your friends and waste some money and data on sending messages. The phishing messages was soon blocked by the Chinese service providers, cut its major spreading channel. Chinese AV vendors all claimed they were “first detected the super Android virus”. And the story came to an end.

Here are some analysis result:

Release an APK, which supports all monitoring functionalities, the main APK only serves infection and spreading.

2852747-1 Screen Shot 2014-08-05 at 12.09.45 PM

Reading SMS:

Screen Shot 2014-08-05 at 5.53.43 PM

Read contacts:

Screen Shot 2014-08-05 at 5.24.42 PM

Scam SMS to all contacts:

Screen Shot 2014-08-05 at 5.55.26 PM

Critical evidence leads to the writer to be arrested:

Screen Shot 2014-08-05 at 5.55.26 PM Screen Shot 2014-08-05 at 5.54.44 PM

Despite the malware itself, there are two problems exposed:

1. Many users are surprisingly lack of security knowledge: SMS phishing is definitely not a new kind of attack. Also Android will pop up warning when install an APK from Internet. However, so many users still gave it green-light all the way. If this incident happened in US, will the consequence be any better?

2. The reaction of AV vendors was no better than in the PC era. The malware created, spreading and eventually being noticed after the number of victim already exploded. Afterwards the AVs made their “detection tool”, which is still based on signature.

Posted by & filed under Uncategorized.

This morning AVTest has published the August benchmark testing result and ranked Trustlook Antivirus one of the top mobile security product (5.5 for protection and 6 for usability).  In its security protecting testing, Trustlook AV successfully detected 99.24% malware/virus. As a six month old mobile security production it is pretty impressive, but we think we can do better in the future.



Screenshot 2014-08-04 17.15.31

AVTest result

Posted by & filed under malware, News, vulnerability, zero-day.


The FakeID vulnerability is a major vulnerability on Android this year, which affects all Android versions since 2.1, says BlueBox inc – the same company published the “master key” vulnerability last year.

This vulnerability is caused by the insufficient check when verifying whether or not a subject certificate belongs to its issuer. The low-level Java code of Android checks whether the subjectDN to issuerDN matches, but doesn’t check whether they are actually signed by the same public key. This allows an attacker to forge an app that passes the subject certificate check, and let Android believe it could share the permission of another app. The full report can be found here: .

Screen Shot 2014-07-30 at 6.38.43 PM Screen Shot 2014-07-30 at 6.38.50 PM

The Adobe webview plugin became a perfect target for such kind of attack. After disguised as a legit 3rd party plugin and tricked the webview plugin manager, a malicious app could be granted special permission of the Adobe Systems. Afterwards the app could escape the sandbox, do some nasty things such as access NFC hardware used in secure payments, and take device administrative control without any prompt or notification provided.

Our team has published a scanning app called FakeID Scanner, available on Google Play. This app will scan your device, and alert you if you installed an app that exploits this vulnerability.


Posted by & filed under News, vulnerability.


Days ago, Curesec had announced a vulnerability that allows the user to bypass phone call permissions on Android. A malicious developer could write an app that makes arbitrary phone calls, without the corresponding permission that an app should apply before making phone calls. Afterwards, the victim could face some expensive phone bills.

The affect Android versions include:

  • 2.3.3, API Level 10
  • 2.3.6, API Level 10
  • 4.1.1, API Level 16
  • 4.1.2, API Level 16
  • 4.2.2, API Level 17
  • 4.3 , API Level 18
  • 4.4.2, API Level 19

The vulnerability is caused by a logical error in the NotificationBroadcastReceiver class in package. When handling an ACTION_CALL_BACK_FROM_NOTIFICATION message, the code directly calls the dangerous ACTION_CALL_PRIVILEGED intent without the proper permission check, which allows an app to call any phone number by sending an ACTION_CALL_BACK_FROM_NOTIFICATION message to

The vulnerable code could be found at, in lines 1137 to 1145:

Screen Shot 2014-07-10 at 5.27.20 PM

To exploit this vulnerability, one could simply send an ACTION_CALL_BACK_FROM_NOTIFICATION message to the component, which carries the phone number inside the data content:

Screen Shot 2014-07-10 at 6.11.50 PM

Curesec has provided the proof-of-concept code and apk.

After having received the vulnerability report, the Trustlook team has added a detection module immediately. By using the static analysis engine, Trustlook Antivirus can detect the exploited code before it is triggered. So far, we haven’t detect any malwares that exploit this vulnerability to gain profit via unauthorized phone calls.

Screen Shot 2014-07-10 at 6.03.08 PM
Screen Shot 2014-07-10 at 6.02.54 PM

Posted by & filed under potentially unwanted app, vulnerability.


The Trustlook security team has recently discovered a number of apps that use the “TrustAllCerts” method in the SSL connection, which renders the secure connections built in these apps meaningless. An attacker could use a self-signed certificate to establish a connection with the victim, and become the Man-in-the-Middle for all the network traffic between the victim and the HTTPS server (In a real-world attack, this can happen on a ARP Spoofing attack, or on a compromised router). Afterwards, the attacker could intercept or even forge the network traffic (e.g. Username and Password submitted via form) sent in a SSL connection.

The root cause for this vulnerability is because some developers reloaded the checkClientTrusted() and checkServerTrusted() methods upon the SSL connection and made them return without actually checking. It is convenient under some certain scenarios (e.g. debugging), but after reloaded these methods, the app would completely neglect the validity of the certificate. According to our scanning result on Google Play, a large number of apps and SDKs have reloaded those methods, and some of them will leak sensitive information.

Untitled drawing

Take the Skout Android app as an example, which is a popular social app with 10M-50M installs:

Screen Shot 2014-06-11 at 10.18.40 PM
Screen Shot 2014-06-11 at 10.19.27 PM

The code that disables the certificate check(click to enlarge):

Screen Shot 2014-06-11 at 10.40.38 PM

We wrote a Proof-of-Concept tool, which could used self-signed certificate to establish a Man-in-the-Middle connection and sniff Skout’s network traffic. As you can see, the plaintext username and password could be intercepted:


Posted by & filed under malware.

Openness often brings about security risks. Several days ago, Szymon Sidor has published a blog that proved it possible to take a photo or video on Android without displaying any notifications. A malware can send the photos over the internet to the C&C server and spy on the victim. This is shown in the Proof-of-Concept below:

Taking photos without giving the preview UI is not recommended by Android, but it’s doable. It seems like a feature rather than a bug. Actually, lots of existing Android apps have already implemented this feature – take the “Find my Phone” app as an example. It can take photos using the front camera without giving any notifications, intended to snap the thief’s face once your phone is stolen.

According to our test, there are at least 3 ways of hiding the preview UI:

  • Set the preview UI size small enough (e.g. 1×1 pixel)
  • Set the preview UI margin large enough that it exceeds the visible screen area
  • Create the preview UI by using new() and not setting its position/size

We also made a Proof-of-Concept app, which could turn your phone into a spy camera, to demonstrate how easy it is to turn a feature into a malware.

Although not every backend snapping is malicious, it’s suspicious behavior. Trustlook Platform will log all the backend camera activities:

Screen Shot 2014-05-29 at 8.32.06 PM Screen Shot 2014-05-29 at 8.34.15 PM

The PoC code can be found at:

Posted by & filed under malware, potentially unwanted app.

What is a Ransomware?

When talking about the cybercrime industry, “business model” is often more important than technology itself. Ransomware is a kind of malware that restricts access to users’ system or data, and blackmails the victim for money to get the restriction removed. One of the most well-known(and profitable) ransomware on PC was Cryptolocker. Emerged in Eastern Europe and grown internationally at the end of 2013, Cryptolocker could encrypt the victim’s hard drive, and ask for 400 USD or equivalent value of Euro/BTC for the private key to decrypt. ZDNet once traced the four Bitcoin wallets used for receiving ransom, it shows a income of 41,928 BTC between October 15 and December 18, worth US$27 million at that time.[1]


Ransomwares on Android

While initially popular on PC, the ransomware scams has begun to cross-platform to Android. In this article, we will discuss 2 Android ransomwares our platform intercepted. The “Fakedefender” and “BaDoink”. Comparing to their PC version. Both technical standard and threat level is significantly lower, and mostly rely on social engineering for money scam.

Screen Shot 2014-05-19 at 10.15.10 PM
  • Name: Fakedefender (Trojan.FakeAV.D)
  • Package: com.avastmenow
  • MD5: E790C4295B8ADB23D090BAE5D6EB786A

Fakedefender is a very simple app, which only contains basic UI, and technically harmless to your phone. It pretended to be a pornography app, and an “antivirus” window (disguised as Avast) will suddenly pop up. Afterwards the following screen will be displayed, telling you that your phone has been locked and you need to pay $300 via MoneyPak to get it “unlocked”.

Screen Shot 2014-05-19 at 10.15.30 PM
  • Name: BaDoink (Trojan.Koler.A)
  • Package:
  • MD5: FB14553DE1F41E3FCDC8F68FD9EED831 / 67bde6039310b4bb9ccd9fcf2a721a45

Have you ever watched child porn? FBI is coming for you! The Trojan.Koler.A blackmails the user in a more professional way: It shows your IP and location, threats the you to be put in prison for 5-11 years due to downloading child porn – unless you pay a $300 fine. Moreover, it will keeps poping up the warning screen every minute, and hook the receivers to pop the warning screen every time you unlock the phone.


Threat or Bluffing?

Strictly speaking, those 2 examples are not “ransomware”, but scam apps. Because they cannot deal actual damage to the user’s data or phone. They scam money purely by social engineering. This is not only due to the malware developer’s technical skills, but also the design of Android. On Windows, every application would have full access of the entire storage by default, including the user’s personal data and system files. However, the Android apps’ permission is much more restricted. It’s storage access is limited to the app’s folder by default.

Let’s think from the attacker’s perspective: Is it possible to make a Android ransomware like PC Cryptolocker? The answer is yes. It is still doable for an Android developer to make an ransomware that can actually damage your phone or data to force you pay ransom.

Firstly, every app could access the SD card by applying the permission android.permission.WRITE_EXTERNAL_STORAGE. The attacker could write an app to encrypt the victim’s SD card, which may contain important data, and blackmail the user just like Cryptolocker does.

Second, there is an Android feature that can grant developer a higher privilege – the Device Admin APIs. It’s a powerful tool used by enterprises applications, which could change the phone’s passcode, encrypt the storage and even wipe out all data from the phone. To enable the device admin APIs, all a malware developer needs to do is to try attracting user to click “allow” on the permission screen.


Think about it, most users don’t know what is device admin, what can it do and how to disable it. Some users are getting used to click “allow” on all permission screens, especially when the ransomware is disguised into another trusted app. After the user clicked “allow”, the question would become: would you pay a few hundred bucks to save your phone data from being wiped out (or the passcode to re-access your phone)?

Third, for the rooted phones, the ransomware would have privilege to deal enough damage. Also, the ransomware might exploit vulnerabilities like “master key vulnerability” to escalate its privilege to a system app.

In conclusion, although the existing Android “ranspmwares” can be rather called a bluffing, the possibility of making a real “Android Cryptolocker” still exists, despite of the Android’s sandbox architecture. Trustlook Antivirus can now perfectly detect the ransomwares mentioned in this article.


[1] CryptoLocker’s crimewave: A trail of millions in laundered Bitcoin