ElevenPaths Black Friday

Thursday, November 26, 2015

The highly anticipated Black Friday starts at Eleven Paths with the very best desktop tools against metadata.

Friday November 27th Metashield desktop suite of products for Client and for Outlook can be exclusively yours for free for 1 year.

Use the codes Black Friday and will turn on the best technology of preventive security on your computer against leakage of metadata.


Links of products:
Engine:
Metashield Engine Stand-Alone 3.2

Client:
Metashield For Client SA 3.2

Outlook:
Metashield For Outlook SA x86 3.2
Metashield For Outlook SA x64 3.2

Black Friday 1 year free activation code:
Metashield for Client: BLACKFRIDAY27NOVMSCW
Metashield for Outlook: BLACKFRIDAY27NOVMSOU

Activation mail: metashield@support.elevenpaths.com
Do not let this chance go away.

More information on https://www.elevenpaths.com/es/tecnologia/metashield/index.html
Youtube: https://youtu.be/QBhISm4QTik

* 27 November one day special offer.

Quick and dirty script in Powershell to check certificate fingerprints

Sunday, November 22, 2015

Malware is using signed binaries to attack Windows systems. Malware needs it to get into the roots of the operative system. So attackers steal or create their own certificates. Everything counts to "look good" for the users and machines. Sometimes, when a signed malware is discovered, you may wonder if any of the binaries in your machine is signed with that certificate. This is a simple powershell script to get that.

Script in powershell

With Powershell, retrieving the fingerprint of the certificate is quite easy. Just a few lines of code. Since most of the suspected machines will be Windows and all modern versions are able to use Powershell, this a simple solution. Just add the certificate fingerprint you are searching for in your computer, tell the program where to start from, and that is all.



To use it, just create your txt file with some fingerprints. For example, these are the fingerprints for the certs used in TheFlame (2012) and WildNeutron (2015) operations respectively.

‎1D190FACF06E133E8754E564C76C17DA8F566FBB
0D859141EE9A0C6E725FFE6BCFC99F3EFCC3FC07

We have uploaded the code to our Github. Whatever good idea you may have to improve it, just share it with us in our community.

Please note this is "quick and dirty" code with both practical and educational purposes.

Research: On the overexposure of Amazon credentials in mobile apps

Sunday, November 15, 2015

The development of mobile applications that interact with common services in mobility environments such as Amazon Simple Storage Service (S3), Amazon Simple Notification Service (SNS), Amazon Simple Queue Service (SQS) or Amazon Mobile Analytics is becoming more frequent.

To interact with these services, apps need to communicate with them and authenticate with some kind of credential (usually based on tokens). We have identified unsafe programming practices in the form of poor management of login credentials, which could allow an attacker to modify the behavior of the affected apps.

Identity management in Amazon AWS

Mobile app developers need their own access keys to programmatically call Amazon Services. They can use the AWS Command Line Interface (AWS CLI)  , AWS SDKs or direct HTTP calls using APIs for AWS individual services.

The latter is more common in apps communications. From the Amazon Management Console, access keys, known as access keys and secret keys can be created, modified, viewed or rotated. These access keys are valid to programmatically interact with the contents or services offered by Amazon. Apps that use these contents must therefore know the access keys.

Although there are more appropriate methods, some programmers embed this information in the app itself. If access is read-only, this can result in a bad programming practice, but not necessarily in a security problem. However, if permissions are poorly established, contents could be controlled. If, in addition, access keys are accessible by anyone analyzing the application, an attacker could modify those contents that later on would be used by the app.

If necessary measures are not taken when setting access permissions of the API keys, anyone with access to the keys could not only access the information, but modify it.

However, access keys can also be introduced into an app through a credentials file located within the APK, in clear text. This way, apps are easier to manage and maintain. This file is generated with the AWS CLI. Its default name is AWSCredentials.properties, and its format is similar to the following:
(Falso) example of credentials
With Tacyt , ElevenPaths’ Cyber intelligence Tool for mobile apps, we have searched how many apps in the different monitored markets contain a file of such type, subsequently verifying the nature of the associated credentials.

First seach in Tacyt for APKs with this kind of files

At the time of writing this report, we found 1,635 APK files containing a file of this type in our database, formed by 4.5 million apps. Those 1,635 files correspond to apps and also to different versions of those same apps (hashes) stored in our database. Unique apps (regardless of their version, and on the basis of unique package name) are actually 478 different apps distributed over different markets.

We have studied the situation of credentials and if they represent any risk.

Data analysis

These are the results obtained after analyzing the apps containing files that could potentially pose a security problem:
  • Of all studied apps, 102 are no longer in the official market and have been removed. Although removed, they still to pose a problem, since the apps remain in the installed devices, and furthermore, credentials do not stop being valid even so.
  • We have found 478 different apps containing valid credentials. 408 of them in Google Play.
  • However, the number of different access keys found in all markets is not too high: 63. This means that several of those 63 credentials are distributed between different apps. In other words, many seemingly different developers share valid AWS accounts. In particular, two different credentials are shared in 523 and 196 different versions of the apps. There are only 26 unique credentials that are not shared and that are found in a sole app.
  • 37 of the 63 access keys found remain fully operational, which means they allow the correct performance of the authentication process. The valid access keys shared have the following distribution. Among the valid access keys, one is distributed in 523 different versions of different apps.  
  • Of these access keys, we have obtained permissions (ACL) from 26 credentials. 
  • 22 access keys kept FULL CONTROL with those credentials. This means that some contents hosted on Amazon could be read, written and even edited.The rest of them allowed Write, which for practical purposes also poses a security problem.
  • The credentials found on Google Play are distributed over 408 different apps. In turn, many seemingly different developers share credentials. It is interesting to see how there is a single credential present in 74 different developers, each one with their respective apps.
Of the 74 credential-sharing developers on Google Play, it should be noted that most of them seem to be magazine publishing companies and media in general, some of them quite known. This suggests that these companies’ apps have been developed by the same team, which has somehow reused part of the resources, including the infrastructure in the cloud and, with it, the access credentials. This exchange of shared credentials between different apps that load contents hosted on a third party opens an interesting attack window, depending on the credentials permissions.

It is necessary to clarify that not all apps containing credentials have to use them. It can simply constitute a "bad practice" if using the appropriate permissions, which means that, even if it involves exposure of sensitive information, in practice it does not open any security breach or attack possibility against app users or developers.


The Android Trojan preinstalled in Amazon Tablets is in Google Play as well

Friday, November 13, 2015

Researchers from Cheetah Mobile have found Trojans preinstalled in some cheap Amazon tablets, very hard to remove. But, here in ElevenPaths we have found that a version of this Trojan is present right now in Google Play hidden as a HTML 5 games application. The malware has been dubbed "Cloudsota".

The app, still in Google Play, made by the same band of "Cloudsota".
 
The Trojan found by Cheetah Mobile, is preinstalled in tablets, restores itself after reboots if deleted, hijacks the browser homepage and downloads apps from some servers to install them silently if the device is rooted (which, in these tablets, is very likely). We found a very similar behavior in a Google Play app, downloading apps from the same servers and with quite similar code. What we can be sure is that is made by the same people behind this Cloudsota. Although maybe with enough changes to be able to get in the official market.

How it works

Once the apps found by Cheetah were analyzed, thanks to Tacyt, we found a strong correlation with just one out of 4.6 million apps in our database. It has been in Google Play since August 2015. This app, when booting or if a user is present (unlocks the screen), calls a method called "b" inside the  com.android.ThreeTyCon.c class, that visits this site hxxp://union.dengandroid.com/getconfig and sends some interesting information.

JSon sent to the server before being encoded
After sending some encoded personal information (email, MAC, if the device is rooted or not, etc) it finally downloads (with some encoding as well) a dex file called business.dex. We guess the file may be different depending on this information previously sent.

The code to download and use business.dex
This business.dex is terribly offuscated, and contains most of the malicious code. Business.dex is as well programmed to download different versions of business_X.dex (the X depends on the configuration in the device) that we suppose that makes its behavour quite unpredictable.

If busybox util is found in the device, it tries to load libraries, install and uninstall apps... This is done just before business.dex is downloaded, we guess this is for uninstalling any antivirus the user may have just before downloading the (even more) malicious code, that is more likely to be detected.

Triying to uninstall code

As far as we know, the app itself or the business.dex does not contain code to survive and install itself after reboot or hijack the homepage, but it definitely could, as we can see some references in the code. 

It may hijacks the homepage
  
Aside, it shares with Cheetah samples, the use of a very particular library libshellcmd.so.
 
It uses libshellcmd.so, shared with Cloudsota


The app in Google Play is detected by some antiviruses. But most of them do not detect the app because of this behavior, but because of it containing some Airpush SDK code. Airpush was considered a potentially unwanted adware SDK long time ago by the antiviruses. It is interesting as well that the app has been downloaded 5.000 and 10.000 times, but only 3 votes have been given.

Too many downloads for so few votes...

That make us think about some time of artificial boost with unreal downloads made by the same developers to enhance searching position.

Sergio de los Santos
ssantos@11paths.com

Miguel Ángel García 
miguelangel.garcia@11paths.com

Apps in Google Play that install an HTTP Server as a backdoor in your Android

Thursday, November 5, 2015

Trend Micro has discovered a very interesting problem with an SDK called Moplus that, literally, works as a backdoor for Android devices. The problems here are that this SDK belongs to Baidu (the Chinese biggest search engine); that is used not only by their apps but others; and that some of the apps are in Google Play right now, with millions of downloads. Finding vulnerable devices is just as easy as scanning a network and send some HTTP commands. Aside Trend Micro research, we have discovered some of these apps in Google Play and other curiosities.

This SDK is called Moplus. Aside its "official features" it sets up a local HTTP server (the well known nanoHttpd), that listens in different ports, depending on the app and SDK version (probably 6259 TCP port). If connected to that port, nothing is served (documentRoot is at data/data/apkName\files\local_http_server)… but it allows the attacker to send POST requests with commands.

Defining the port where the server will listen
And that is all. Any attacker may send commands to the port via HTTP POST requests with no strong authentication. One of the weakest version only needs the header "remote-addr" to be set to 127.0.0.1. But some others need the referer header to match this.

^http[s]?:\\/\\/[^\\/]+(\\.baidu\\.com|\\.hao123\\.com|\\.hiapk\\.com|\\.91\\.com)(:\\d+)?(\\/.*|)$";

If it works, it will execute the orders and return a JSON with the response (given the right permissions, which most of the spotted apps seem to have).

What commands does it support?

It is very clear with this piece of code:

Code with the accepted commands
It allows downloading files, and uploading anything. From retrieving the lists of apps to inserting new contacts. In rooted devices, any new apk could be installed silently.

Code to add contacts silently
Part of the code to upload files
Trend Micro contacted Baidu, that has created a new version that removes most of the malicious commands of the list. They are replacing most of the affected apps.
 
What did we found?

Trend Micro talks about thousands of apps affected. With Tacyt, we found the ones using the SDK and still available in Google Play. Some of them with up to 5 million downloads and not related to Baidu at all.

A variation of the code with the commands
These are some of the packageNames spotted in Google Play (although there will be more, for sure), different from the ones published by Trend Micro (so far):
  • com.qiyi.video.market
  • com.nd.android.launcher91
  • com.ivodani.comicsisland.activity
  • com.qyer.android.jinnang
  • com.pad.comicsisland.activity
  • com.cubic.choosecar

We could not confirm that the commands works the same in all of them. For sure, they contain the offensive code, but maybe with slightly different systems to be able to get in. They should be reversed individually to be sure how to make it work (or if they even work).

One of the easiest that we tested, was the very popular Baidu Maps. Not this one, but a previous version (8.7.0).

In the image, we use this Chrome plugin to inject POST commands. The result (inserting a contact remotelly) is shown. As you can see, Baidu Maps icon is on the top.

Adding contacts with a POST


It is worth mentioning that, many of the spotted apks, rely on two different classes.dex files. This means that, once executed, the app may load classes2.dex from its own "main" code, and usually this classes2.dex is the one with the offensive code.

An app containing a second "dex" file
This is not new. Many malware/adware in Google Play use this trick to try to fool detections. They may download the .dex file from elsewhere, or hold it inside. It is quite interesting finding that, some of the apps were using the "Moplus SDK capabilities" in this second dex file.

Aside, one of the most interesting point is that Mobo Launcher, related to the well known Mobogenie market, counts with this code backdoor as well, and it is very popular even outside China. It has been in Google Play since late 2014. In fact, is the oldest in Google Play with this version of the backdoor, as far as we know.

Some of the detected apps in Tacyt
Although we could not get to make it work and actually send a command (not sure why), the nanoHttp service was up, and code to receive commands is there... so there are strongs reasons not to trust this app, and reverse it even deeper to know exactly what is happening and how it works.

Of course, there are a lot of APKS outside Google Play (aptoide, mobogenie...) with this backdoor as well.

The good part is that most of these programs are already detected by several antiviruses, not all of them because of this, but detected, anyway.

Sergio de los Santos
ssantos@11paths.com
@ssantosv

Juan Manuel Tirado
juanmanuel.tirado@11paths.com