Shuabang botnet: BlackHat App Store Optimization (BlackASO) in Google Play

ElevenPaths has detected malicious apps in Google Play (already removed by Google), aimed at performing Shuabang techniques, or BlackASO (Black Hat App Store Optimization). These malicious apps link fake accounts with the real device of the victim, getting very “real” accounts. With these accounts, the attacker sends tasks to the victims so they download apps (although not effective on the victim’s device). The victim’s account remains safe, but not the data about the phone. We describe in this report the details of this interesting attack.

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.

Sergio de los Santos

ssantos@11paths.com