Posted by & filed under AVTest, News.

Achieving 100% Malware Detection Rate With Zero False Alert And Full Application Usability & Protection Score Of 6.0/6.0

Trustlook ranked No.1 mobile security application in AV-TEST Benchmark testing. With 100% detection rate of a representative set of malicious apps (2186 malware samples used), zero false alert for Legitimate applications from Google Play Store (1946 samples used) and other App Stores (970 samples used), and full performance score of 6.0, Trustlook Mobile Security (http://goo.gl/nLj7DS) ranks No.1 among other 32 Andoid mobile security products.

Untitled

The growing popularity of smart devices bring not only convenience to people’s lives, but also the security risks that come with it. AV-Test’s benchmark testing have raised more awareness of the fact that mobile security applications has become essential to smartphone users. AV-Test’s scoring metric in fields from comprehensiveness of protection and other key features makes it one of the most authoritative standard with which to assess mobile security solutions for individual and enterprise users.

On the one hand, Trustlook’s outstanding performance is due to the relentless pursuit of technology, on the other hand benefited from the continued improvement for user experience, which are both reflected in the AV-Test tests. Besides comprehensive protection integrated with wide range of features including antivirus, data security, anti theft and web security, Trustlook’s quick response to recent severe vulnerabilities also gave users up-to-date solutions to mitigate everyday security risks.

Posted by & filed under News, potentially unwanted app.

You may have encountered the problem that your games and apps – which looks normal – has been identified as “high risk” by Trustlook antivirus. In this case, you need to check if they are genuine version from official Google Play, and upgraded to the newest version. Otherwise, those app might contain minor risk behavior that violates your privacy.

In this blog we’ll take the “Admogo” (http://www.adsmogo.com/) as an example, which is a famous Ads SDK emerged in China. They claimed to have more than 70k apps covered, with 1.1 billion requests per day. However, we found this SDK contains some code that may send your device IMEI number, location and phone number to the 3rd party servers, and might be use for commercial purpose.

Some well-known games and apps are also in the list (e.g. the old version 2.3.1 of “Don’t Tap The White Tile”, which now have 50m+ install on Google Play). They are malwares, but they do contain stealing behavior. To avoid installing these apps, we suggest you to get apps from Google Play, instead of from a less-known app markets or direct APK download.

Here’s some examples:

Package Name Still on Google Play? MD5
com.raesun.lovely.photo.frames No 0AE614389E861C562D77C9FB80A4B669
zhao.peng.you no 0BEE4547BE554C14D204520539264244
com.doirdfunia.photoartdroid no 0E9BAA19BBF60E8EFC41935C46AE5C79
cn.com.lw.fish no 05525E236F4C5EA5F7D7FB142F1BA171
com.doirdeditor.PhotoFunia no 10402A2E17DC14F23194EC414BECAE38
cn.bluesky.fourinalinekids yes
(newest version is clean)
0B8E1DECAC3EFE6FC5BA63D0EB655758
net.tomcoolz.android.livewallpaper no 0DB19A61974D31C5F813C0A4DAB2CB79
com.raesun.lovely.photo.frames no 0AE614389E861C562D77C9FB80A4B669
cn.chinabus.main yes 5CC96B42A91017184D04CD5F972CA2B4
com.umonistudio.tile yes
(newest version is clean)
EC0AA4AED20669BF68305D686CD94606
com.zjsj.chinachess yes
(newest version is clean)
07186A73DAF1ACD4E8DB9BBEC7F2FCD6
com.funny.camera no 0E31A11E26B4F3A0CCC11DB0A9BCE8E0

Screen Shot 2014-10-12 at 7.01.50 PM
Screen Shot 2014-10-12 at 7.02.01 PM

Detailed behavior in Admogo SDK:

Read personal information from your phone:
Get IMei:
Screen Shot 2014-10-10 at 5.53.20 PM

Get Phone Number:
Screen Shot 2014-10-10 at 5.45.07 PM

Get Location:
Screen Shot 2014-10-10 at 5.37.27 PM

Send Out Information:
Screen Shot 2014-10-10 at 5.26.57 PM

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.

htc

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 (http://findmymobile.samsung.com/):

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

GxLh-Z6iwiXPm1anMnFziNF1IeZTo_Xa5SkDW7Wxz-mm2oVUbB3rUtQESRlGETypglA=h900

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: http://goo.gl/nQ5gIb .

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.

n2t8EDpjljqkIrq69tXzggyVte2PWwCaj-PqZwsxjGaJzSOBFlfD_wuWm_K2-ZcLwjE=h900

Posted by & filed under News, vulnerability.

unnamed

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 com.android.phone.PhoneGlobals 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 com.android.phone.

The vulnerable code could be found at http://goo.gl/brGgGX, 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 com.android.phone 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:

Untitled