With Google Play more vigilant about SMS premium apps in their market, the attackers have tried some other techniques that avoids Java and focus in JavaScript received from the servers. Besides, they do not only subscribe to SMS premium services, but they make phone calls to premium rate numbers. Everything in a very smart way, because, for example, they try to mute the telephone and microphone during the phone calls, tries to hide the phone call itself from the screen… and take the whole code from the servers instead of embedding it.

What the user perceives

When the user downloads and installs any of these apps, something like this will be shown.

First views of the apps

These are the typical “terms and conditions” that probably nobody will read. Accepting them implies making the phone call in an automatic and transparent way for the user. The image “Aceptar” image shown, is taken from this jpg file:

hxxp://www.contentmobileapps.com/called/images/continuar_call_100.jpg

Whatever the user responds about the age, the device will show an animation (a GIF taken from here hxxp://www.contentmobileapps.com/called/images/loading.gif) while the actual phone call is done to a premium rate number.

GIF shown to the user while the phone call is done

It seems that, depending on the phone, a green bar may appear during a few seconds, but the developer tries to hide it.

The device making the call may be detected in the background

The attacker mutes the telephone and microphone so the user is unable to hear the message of the phone calling and the locution.

On the last line one can observe the attempt to mute the microphone and device volume

The victim will be subscribed to this service and will have to face the costs of premium rate calls. The user will now be able to browser the recipes, but the phone call has already been made.

The app is just some links to a web, but the phone call has been made

Once clicking on the “Help” button, the option to unsubscribe is given.

The app offers instructions on how to cancel the subscription

What happens and how does it work?

These apps depend strongly on the servers and work via Cordova plugin. It is a set of device APIs that allow a developer to access device functions via JavaScript… The permissions of the analyzed app are these, although they are not the same in all of them. Some of them lack of the SMS permissions.

Permissions in one of the apps. Some of them lack SMS permissions

The first thing the app does is executing a WebView with Cordova that shows an internal HTML.

The obfuscated domain starts the real communication with the server

A request like this is done: hxxp://highmas.com/alcalinas/home.php?movil=ffffffff-XXXX-ffff-ffffd6de17fd&version=16&modelo=GT-XXXX%20(goldenxx). The user will receive a welcome screen and will be asked for his/her age. Whatever is clicked, the app will go to the same function that gathers some information with a form. The value in CAPTCHA field is useless. It seems to belong to some discarded proofs.

Form sent to the server

A web redirect after the request, takes the user to a webpage where the country and carrier is checked.

The app checks the country and carrier via JavaScript

Once everything is checked, terms and conditions are shown. When accepted, the app calls”term_acept.asp”, which finally returns dynamically the premium rate number to be called.

The premium rate number is returned. The app will make an unnoticed phone call

With Cordova’s help and a dialler plugin, it finally makes an actual phone call.

Some other interesting info and more apps

The developers have found a way to get back to fraudulent activity with premium rate phone calls. Who is behind these apps? The domains being used and terms and conditions are very clear. We are investigating the developers and some other apps they have, and will try to offer a report soon.

With Path5, we could find similar apps. Some of them have already been removed, but not all of them. They are working on uploading fraudulent apps since early January.

Some examples of found apps

Some apps have mutated from apps related with cars (in Japanese), to porn. This is the preferred way to hide better in Google Play.

App that changed at some point

These are the applications, package names and hashes. Only one of these apps has been analyzed in Virustotal, and it was not detected by any engine so far.

• Videos hd peliculas porno sexo, com.gepekline, 6f1c3a596920298873f1e38842f751991875e6d6
• Peliculas videos sexo Porno hd,com.wheelpvies,34b2bba921e9b7d9c8242d31e2cc011908684d9a
• Videos hd peliculas porno sexo ,com.spportss,ada71fc53f9aae5f84cc69814b58f65f1e273067
• Canciones infantiles y videos, com.sursongsonline, 1fcce1b8effdcbdef54cc02675eefc5214fec67b
• Peliculas videos porno sexo hd,com.escarsysview, 031490dd0b824c02be7d0fe728d67f998ef7c914
• Cine estrenos peliculas online, com.filmsmeka, e856cd2d4a366abbb1df18c8bc53c7a35a6da535
• Un millón de recetas de cocina, com.recippes, 194362c46b124161a5289d1d3c4c56f93b142044

With our database, we have been able to locate some other apps, and prove that the developers behind  them come from Valencia and have been working on these frauds for a few months now.

Fraudulent JSDialers in our data base

The whole document is available here:

Since December, a developer has been uploading apps to Google Play, with the only intention of booting with the device and make GET requests in the background. Promising different kind of apps (from remote controls and X video searchers to flight simulators and games) these apps sum up to 50.000 downloads between all of the 32 apps we have spotted. Obviously not all the downloads translate into an infection (VerifyApps and other factor may affect) but they seem to be quite popular.

Some of the apps are just “clickers” under different “disguises”to attract victims

One of the apps is a scientific calculator with the description text in Italian. We have asked Google to remove the application that was still online (maybe because it was a little more advanced than the others and passed unnoticed) and that we have located thanks to Path5.

App that wasn’t removed from Google Play. One of the latest remaining. It worked in a more sophisticated way than the others.

What the app does

When it starts, it always shows a dialog with the text “Application is not compatible” in Italian, Turkish and Spanish, between other languages.

The app always shows the same dialog when it starts

It hides its icon, modifiying values in the Manifest, after the first time it runs and after showing the message. It does nothing else until it receives a change in WiFi, data connection or a reboot. It connects to this encoded URL (it is not base64, although it looks like it).

Encoded URL

Decoded, it turns out to be: hxxp://1.oin.systems/check.php. If it responds with a “True” (which is  pretty much always by now), its activity will start.

Other variants connect to other URLs like this one:

Or this, depending on the sample: hxxp://pop.oin.systems/commands.php.

Every time a new request is made, the apps get instructions on where to go and click. In every connection they get new domains to connect to.

Request for the place it has to visit

In just a few minutes, the device has generated dozens of requests. For the user standpoint, the problem will be the data consumption if he has a paying data plan. Apps are activated when the device boots so, although the app itself is not active or launched, the device will be consuming data all the time.

Extract of the traffic generated by the device during a few minutes. Most of them are porn sites

Indiscriminate visits will be done through a service that builds a WindowManager with a weight and height of “-2” so the user is not able to actually see it in the screen, where a WebView is added. There is where the URLs are loaded.

It will take some other values from some other URL. Every 15 seconds (time to load the web) it will call:

Another task will take care of executing this JavaScript over the loaded URLs. This will result in random clicks on the web.

This strategy of hiding the icon, avoids the user to even bothering in uninstalling an app, because he will think it was never installed in the first place. Moreover, if it keeps quiet until next reboot or when connectivity changes, there are more chances of the user forgetting about it.

Permissions are not very blatant.

Permissions of these apps

Detection

The app was not deteced by any engine during December and January. January 20th we sent it (for the first time) to VirusTotal from ElevenPaths’ lab.

Detection in January

Eventually in February, some engines started detecting it. Engines have created a specific signature for this family, called Riskware.Clicker.

Detection in February

The attacker

This is a typical schema, but quite witty in its implementation. We have detected that the attacker has been acting since later December and that he probably is Turkish (thanks to the information obtained from its ad-hoc certificate). Its current timezone is GMT+2, added to the language used in some apps, makes us think that it’s someone developing from Turkey, although with some Italian relationship. Some other specific characteristics has allowed us to spot the other apps very quickly.

The strategy has been the usual one. During most of the time, the app starts in Google Play like an anodyne app. It consolidates in the market and maybe someone downloads it. For the next version, the apps mutate into something more attractive to the user, maybe it changes the code, maybe the icons and description. In this moment a “race” starts, because Google will remove it quickly but it will try to get the more the better installations.

The app was something called Beklre (up in Google Play) and then mutated into a fake Talking Tom (down in Path5)

The app was something called “Sebebi Neydi ki” (“Which is the reason” in Turkish)  and then mutated into a fake Cut the Rope for some hours (down in Path5)

Some other apps that seem to belong to the attacker

Shuabang

Shuabang techniques, or BlackASO (Black Hat App Store Optimization). This is a real industry in China that has been active for years. The method consists in creating an infrastructure to score or artificially inflate the number of downloads of an app so they rise up their position on the markets. This infrastructure requires fundamentally Google or iOS accounts so they can distort actions, as if they were generated by real users. This “service” is usually sold to a third party intermediary (companies) that claim to enhance and optimize positions in any market but they do not really care about the methods to achieve it.

To carry out the fraudulent scheme, the attacker needs active Google accounts associated with real devices that do not appear suspicious to Google, which would quickly eliminate them otherwise. Different techniques are used for this purpose. The most usual is to manually hire users that will create accounts in the market and rate apps they are told to. On this particular occasion, they came up with a system that starting from a set of fake Google accounts, distributes and associates them to different devices, so they take full advantage of the number of phones associated with an account. Besides, it allows sending tasks to the device so it simulates downloading apps under fake accounts. The potential of these malicious apps spotted for Shuabang is above average, since it demonstrates in-depth knowledge of the specific operation of Google’s authentication protocols. Before getting into the details, let’s see how Google accounts work.

How Google accounts work

When a user creates a Google account, once the username and password are provided, he has access to dozens of Google services, as a Single Sign On.

Google account working schema

The user enters the account password in the device only once. From that point on, he is registered in a Google service (for example Google Play, sending user, password, device ID…) that will return a token. This master token is stored in the device account manager (that remains associated) and will be used from then on in the device  (that remains associated to it) so the password does not have to be entered again. Other temporary tokens are derived from this master token. It is common for users to have several devices registered with the same account. This, for example, allows users to choose where to install apps. For linking or associating a device to an account, the usual process is:

Registering and associating and account with a device

• Either creating the account from the device itself. Google prevents automatic creation of fraudulent accounts by discarding accounts created on devices that are not “real”, as well as inserting a CAPTCHA.
• Or using an existing Google account and signing in with it on the device that it is to be associated with. This process only requires entering the username and password in the phone to add a new account.

What Google does, is associating a device identifier with the account. The Android phone or device will appear as a device associated with the account on the Google Play settings panel.

This low-level registration and association protocol has been studied by the community and specially by attackers who carry out fraudulent practices. Registration and association can currently be programmed with raw calls to Google services and providing the necessary information. This process isn’t officially documented, though.

This kind of botnet is a sophisticated system by which attackers use apps with minimum privileges to associate accounts created by them to real devices. Thus, attackers obtain a number of fake accounts associated with “real” phones and therefore valid for Google services, allowing them to carry out a variety of fraudulent schemes. Specifically, artificially increase app downloads or fraudulent app rating.

The attack

The attacker had a pool of 12.500 Google accounts, created with valid username and passwords, but not registered with any device. The vast majority of accounts in this database were created by the attacker, and were delivered to the victims to register them with their devices.

Brief attack scheme

Fundamentally, the attacker gets the victim to make two actions:

• Associate accounts to devices in an automatic way so he can get tokens.
• Use these tokens in a distributed way, so downloads may be simulated.

Real example of a response to an infected device, getting an account that will be associated to the device

The applications turn the device into a zombie that collected these fake accounts from the central server every 10 minutes and associated them with the information on the victim’s phone. The “original” Google account on the victim’s device remains safe and the attacker cannot access it at any time. Each account was associated with between 10 and 30 physical phones of victims. The combinations between Google accounts and associated phones are countless. The image shows an example of an attacker account associated with 18 victim devices.

Example of an account associated with different victims’ devices

The attacker published more than 300 applications on Google Play throughout the month of October. They were disguised as games, jokes, wallpapers and general entertainment. Of these, approximately 100 committed the fraud by associating these fake accounts to the device’s settings and identifier. The remaining 200, although harmless in their first version, were usually later updated to commit the fraud. The permissions the apps requested are:

Permissions requested by the apps infecting the users

With this attack scheme, the attacker has obtained a database of  60,000 tokens. The attack was focused on victims in Brazil, India and Russia, although it was prepared to add any other country.

The complete attack scheme is this:

General scheme of the attack

Conclusions 

Although the attacker seems to have a known ultimate goal (black ASO), he achieved several interesting milestones by developing these malicious apps:

• He created or bought 12,567 Google accounts, most of which were automatically created. Account creation requires breaking a CAPTCHA.
• He achieved a low level understanding of the Google registration and device to account association process. He was able to program them to work automatically. This is not officially documented and there is very little documentation about this.
• He was able to introduce some 100 malicious apps in Google Play with apparently harmless permissions.
• He was able to manage a task system that fully optimized the activity of the infected network by distributing download and account association tasks, etc.
• He was able to use the victims’ devices features to associate them with accounts and thus perpetrate the fraud, as if a fake user was registered in the victim’s device.
• Although the victim’s account data is not affected, these malicious apps imply taking advantage of resources and violating privacy.

Although the Shuabang technique has been known and developed for some time via a variety of apps, the attackers’ target is usually Google Play as an area for privileged distribution. This is the market that poses the most problems for publishing, but once they get it, and thanks to this intelligent technique described, the success for the attacker is remarkable. These malicious apps seem to be in a development phase, and it seems they were experimenting with these techniques.