In any news about malicious applications for the Android platform, the mechanism by which Google remotely removes unwanted software from all devices at once is mentioned. How does this system work, and can it not become the largest distribution channel for Malvari?
I'll start with statistics. The first Android-based device, the HTC Dream / G1, was launched in the US and the UK in October 2008. The beginning of the rapid spread of the platform is associated with the advent of the Motorola Droid smartphone in November 2009. Since then, the number of devices that are activated daily is growing in a phenomenal way. At the last Google I / O conference, a fabulous number was announced: 400,000 activations every day! Just think: this is half the population of Cyprus or, for example, the whole of Brunei. In total, over 100 million Android devices are currently activated. Not bad. Now imagine that Google can manage a little of each of them. Perhaps I am slightly exaggerating and the word "manage" is not the most appropriate here. It is reliably known that Google can install and remove arbitrary applications through the GTalkService mechanism. Linking this with impressive statistics on activations of new devices, you’re willy-nilly thinking about the potentially largest botnet in the world that users enter voluntarily with hundreds of thousands. And although the idea smacks of science fiction, it was interesting for me to understand the insides of the GTalkService mechanism. How does it work? In what form do the messages come from the server? How secure is the transmission channel? Is there any danger that someone else can send a message with the control commands to my device?

Applications removed by Google command
It's all about GTalkService
Any device on Android maintains a permanent TCP / SSL / XMPP connection to GTalk servers. All the time when he has access to the network. The connection is managed by a special service GTalkSerive. He constantly sends pings (so-called “heartbeat messages”) to Google servers to check connection activity, and in case of a connection break, it automatically reconnects. This link allows Google to manage devices remotely. A message sent via GTalkService will certainly be sent to every smartphone. Using this mechanism, the C2DM service (Cloud to Device Messaging Framework) works with the help of which developers can send special commands to the applications installed on users' smartphones (for example, to download updates). However, while C2DM is limited only for some developers who have left a special application. It is known that the Android OS supports at least two commands: REMOVE_ASSET and INSTALL_ASSET, which allow Google to remove and install arbitrary applications. Thus, having detected the malware in the Android Market, the company's engineers can send a message REMOVE_ASSET through GTalkService, and the malicious program will be deleted from all devices connected to the Internet at once. This, as we know from the news, the company used more than once. And the opposite situation. As soon as Google gives the INSTALL_ASSET command, each received smartphone message on Android downloads an APK distribution kit with the program and installs it. On the one hand, such an opportunity is good: Google can quickly remove all appearing malware. But on the other hand, scary. But what if someone can realize a MITM attack on the SSL connection of a particular phone before GTalkService and send the message INSTALL_ASSET to pour some infection on the phone? Is the system safe?
Data channel reliability
We will not consider the option of capturing the infrastructure of Google, through which theoretically it would be possible to download an arbitrary application to all Android devices at once. At this stage, we will consider it fiction. But what seems more real is sending fake commands to a specific device. Yes, the GTalkService connection, as I noted above, is secure: all data is transferred via SSL. Thus, the basic security and integrity of messages is guaranteed by the protocol itself. But we know the price of these guarantees (read the material
“We open SSL ”). If desired, SSL-connection can be compromised, intercepted and reverse the packets transmitted between the device and Google servers. If we understand their structure and correctly fake the message INSTALL_ASSET, then we can forcefully install an arbitrary application on the device. In theory. The question is, is there any other level of protection, for example, a digital signature? To investigate incoming messages from Google, you need to get them. Now you might think that you will have to turn on the sniffer and wait until the engineers of the company send the INSTALL_ASSET command again via GTalkService. But when will it be? In fact, everything is easier. Running a little ahead, I will say that the same service is used whenever a user installs messages through the Android Market. Pressing the “Install” button causes INSTALL_ASSET to be sent via GTalkService, which initiates on the device the process of downloading the desired APK package of the program and its installation. We'll talk more about this, but one thing is important now: getting the message INSTALL_ASSET for research is not a problem. In general, to view traffic (despite the fact that it is transmitted via an SSL connection), very little is needed:
- Get the image of the Android emulator, which includes the ability to work with the Android Market.
- Add your CA certificate to the /s//cc/security/cacerts.bk repository using keytool or portecle.
- Implement a MITM attack by using sslsnif with a CA certificate.
Now that GTalkService wants to establish a connection, we will be able to intercept traffic, because the device trusts the CA certificate we created. If you try to install any application from the Android Market on the emulator, then we, respectively, take out the INSTALL_ASSET message. It will look something like this:
')
tickle_id: 1277687266074
assetid: -155863831473120556
asset_name: Replica Island
asset_type: GAME
asset_package: com.replica.replicaisland
asset_blob_url: android.clients.google.com/market/download/Download?assetId=-155863831473120556&userId=986032118775&deviceId=1094117203906638597
asset_signature: Ayn2bWDqckQkKsBY4JurvCFpYN0
asset_size: 5144485
Most of the parameters describe the application that the user requested from the Android Market. Of interest is the attribute asset_signature. It can be assumed that this is a cryptographic signature of the message INSTALL_ASSET, with the help of which its integrity is additionally guaranteed. Alas, it is not. Enthusiasts have long established that this is nothing but a base64-encoded hash of an APK file (that is, the distribution of the program) that the user requested from the Android Market. We can only verify this time by downloading the APK package and performing the appropriate conversions with its checksum. It becomes clear that there is no additional protection for the INSTALL_ASSET message (and, therefore, any others). If an attacker can intercept an SSL connection between GTalkService, then theoretically he can send arbitrary messages to the phone, including for installing applications! Of course, there are a lot of “buts”, and it’s rather difficult to imagine such an attack. To do this, at least, you need to be with the victim in the same network in order to be able to implement the MITM attack. There can be no talk of any massive infection of users. This does not detract from the lack of security of the communication channel, but the prospects for exploiting flaws here, frankly, are weak. Therefore, we will not dwell on this anymore, but let us see what other surprises are fraught with the Android platform and the GTalkService mechanism.

GTalk Service Monitor Interface
Interaction with Android Market
Above, I said that GTalkService is involved in the installation of applications from the Android Market. This is generally an interesting story. Here, too, there are interesting nuances. Consider to begin with the stages that the user goes through to install the program from the market:
- Launch Android Market.
- Search for the desired application to install.
- Clicking on the “Install” button.
- Confirmation of privileges required for the application.
- Download and install the application.
After that, the user in the notification panel displays messages about downloading and installing the application. Everything is simple and transparent, but ... If you look at the process from the inside, then everything happens a little more complicated. If the first four steps are performed by the Android Market application, then the fifth (most important) stage is answered by a completely different system component, namely the already familiar GTalkService. The scheme of work (see the illustration for more understanding) is as follows:
- The user clicks on the application installation button in the Android Market.
- The application sends a POST request to the Android Market servers.
- Android Market servers send information about the application installation request to the C2DM system.
- C2DM servers send the INSTALL_ASSET message to the user's smartphone via the GTalkService connection.
- The GTalkService component accepts the INSTALL_ASSET message and activates the Vending component.
- The vending component downloads the application's APK package and, in the end, installs the application.
The first thing that arouses interest is, of course, the POST request that is sent to the server. Since it can be sent to the Android Market, then maybe we can do it with a special application? Let's try to figure it out.
The intercepted request is as follows:
POST /market/api/ApiRequest HTTP/1.1
Content-Length: 524
Content-Type: application/x-www-form-urlencoded
Host: android.clients.google.com
Connection: Keep-Alive
User-Agent: Android-Market/2 (dream DRC83); gzip
version=2&request=CuACCvYBRFFBQUFLOEFBQUJvZWVEVGo4eGV4OVRJaW9 . . .
Everything is trite except the request parameter, in which everything interesting is obviously hidden. Knowing Google, we can easily assume that this data is packaged in
the protobuf corporate
structure and encoded in base64 after that. And there is. Decoding the hash and unpacking the structure, we get the request data:
1 {
1: "DQAAAK8AAABoeeDTj8xex9TIio . . ."
2: 0
[... ...]
13: "-606db3000d480d63"
}
2 {
10 {
1: "353999319718585473"
}
}

Request structure after decoding from protobuf
Already something, but there is a problem: we do not know what this or that parameter is responsible for. Most likely, these are some identifiers of the device, information about the platform, some data for authorization and, of course, the identifier of the application requested from the Market. Here it must be said that for many protobuf structures that are involved in working with the Android Market, a description made up by enthusiasts as a result of reversing is available. And
code.google.com/p/android-market-api even lined up a collectively written API that allows you to request various data from the market (description, program icons, etc.). True, data on the structure of the application installation request is not there. But the reverse was performed by the well-known Android platform researcher John Oberheid, who subsequently implemented an interesting attack, which I want to tell you about. So, the abbreviated query structure looks like this:
[.. ..]
message InstallRequest {
optional string appId = 1;
}
message RequestContext {
required string authToken = 1;
[.. ..]
required string androidId = 4;
optional string deviceAndSdkVersion = 5;
[.. ..]
Most of the fields from the request can be extracted from the device itself (for example, the interface language, the system version, etc.). But not the appId and authToken parameters:
- appId - is a unique identifier of the application in the Android Market. This identifier is not displayed anywhere, so the only way to get it is to request an application from the Android Market and remove the traffic by pulling its identifier from the protobuf structure.
- authToken is a ClientLogin system token with which the Android Market servers can authenticate your request.
If the authToken remains secret, then the request will not be issued. But you can notice that since the device has it, it means that it is still stored in some place of the system. Exactly! This storage is called the Account Manager and is an important component of the Android platform that provides authentication data. For example, if an application wants to post a Twitter message, then it does not need to know the login and password for a Twitter account - it can request a token from AcountManager, which will allow it to send a tweet. So in the same place is stored and authToken, used to interact with the servers of the Android Market. But the funny thing about this story is that you can extract it with just a few lines of code:
AccountManager accountManager = AccountManager.get(getApplicationContext());
Account acct = getAccount(accountManager);
accountManager.getAuthToken(acct, "android", false, new GetAuthTokenCallback(), null);
What does it mean? It turns out that we have all the data to create the protobuf-structure, which I cited above, and to construct a POST request for sending to the Android Market servers. If the request is correct (and it will be, in what I assure you), then a message INSTALL_ASSET will be sent to the device via GTalkService, which will lead to the installation of the application specified by us! And since the system is designed so that the user gives installation permission even before sending the request (again, see the diagram), no one will ask him anything at all. And the application will be installed in the system with all the necessary permissions!
Attack through the application
Now that we know some of the subtleties of the mechanism for installing applications from the Android Market, we can talk about the graceful attack that John Oberheid managed to do. The idea is as follows. If we can construct installation requests ourselves, then nothing prevents us from writing an application that will do this automatically. If you add this functionality to a completely innocent program and start distributing via the Android Market (which is easy if you don’t have control), then all users who installed it can download anything you want! No sooner said than done. John wrote a PoC application and called it Angry Birds Bonus Levels, which should have attracted the attention of Android Market users. The simplest social engineering worked: users began to install the program. The most attentive of them probably noticed that in the update area there were messages about installing three more programs: to track the location, make calls to premium numbers and steal the contact list. All of them really had malicious functionality, but were not used in any way. Here I must say that the researcher immediately after testing PoC reported a problem with Google, and the company has already fixed a bug. The solution, by the way, was very simple. The system now notes for itself all installation requests for applications made through the Android Market, and checks that the corresponding request was previously made for the incoming INSTALL_ASSET message. If the Vending component receives an INSTALL_ASSET message for an application that it does not expect, then the command is simply ignored. It would seem that the problem is no more. But! In the body of the message there may be a special flag that allows you to cut off the check (including to preserve the functionality for remote removal of applications), but this is a slightly different story.
The article was prepared on the materials of the researcher
John Oberheid .
Hacker Magazine, July (07) 150
Subscribe to "Hacker"