Android Account Manager Vulnerability You Should Know About

Greetings to you, dear reader! Many developers use Account Manager (AM) capabilities in their applications. And rightly so, because this tool allows you to simplify some things. It allows you to store a password, token, and in principle, any string data of the user. It also allows you to automatically update the token if it gets rotten, and many other useful pieces. But this convenience has another side - security. Because of this, I actually wrote this text.

Since AM allows you to store such important data as a password and a token, then he probably just has to do it safely, because if they leak, then nothing good will come of it. You can say that nothing is stored safely on a rudimentary android device, and I agree. However, if everything was limited only to the root, then you would not read this “work”. To tell what we are here for, I will start from the very beginning.

In general, to work with AM in the application, you need to make several body movements and create two components - the heir of AbstractAccountAuthenticator and Service ( more details here ). The latter will have to be registered in the application manifest as follows:

<service android:name=".account.AuthenticatorService" android:exported="false"> <intent-filter> <action android:name="android.accounts.AccountAuthenticator" /> </intent-filter> <meta-data android:name="android.accounts.AccountAuthenticator" android:resource="@xml/authenticator" /> </service> 

And also, if you noticed, we need to create in the resources a certain xml file with the name authenticator.xml . Although the name is not important here, but the content is important. That is what plays the key role of the story. The file looks like this inside:
')

 <account-authenticator xmlns:android="http://schemas.android.com/apk/res/android" android:accountType="@string/account_type" android:label="@string/app_name" /> 

The label parameter is responsible for the name in the list of accounts in the device settings, and the most interesting is the accountType . Without it, the application will not be able to add and receive accounts. And with the help of this parameter you can intercept the accounts of another application even on devices without root. Let's see how this can happen.

There is an application A on the device with accountType = "someType", this application creates an account, adds a token, password and other information to it. At one point, application B is installed on the device with the same accountType = "someType". And here if to delete the application A , then all created accounts will pass into the power of the application B with full access. The reverse is also true, application B accounts will be transferred to application A if you delete B.

An example on the video:


Ahead of the apk signature questions, it doesn’t depend on which key the application was signed with, release or debug, the transfer will happen anyway. Awful, right?

All this can be done in the flesh to API version 23. Fixed only with the release of Android 7.0 (API 24). Sadly in this situation, a negligible percentage of devices with this version of android. By the way, I learned about this issue from the security report on android . Unfortunately, in the text, the retelling of the presentation, there is nothing at all about it, but in the video they mentioned it in passing, without attaching special significance.

So what do you suggest? - you can ask. And I offer you two solutions to the problem. The first is to continue using AM, but store all the important data in it in encrypted form. If you no longer trust AM, you can continue to use it, but not store important data in it and use AM in conjunction with the second option. The second is to completely abandon AM and use a storage that can be encrypted. For example, SQLite in conjunction with sqlcipher or Realm , which supports encryption out of the box. I chose the latter. Here is an example for realm, which shows how to generate and store an encryption key.

I did not give examples of the code in the article, since this does not make sense. The source code of the victim and interceptor can be found on the github.

Thanks for attention!