Android Account Manager Vulnerability to Know About

Published on November 05, 2016

Android Account Manager Vulnerability to Know About

    Greetings, dear reader! Many developers use the capabilities of Account Manager (AM) in their applications. And they’re doing it right, because this tool allows you to simplify some things. It allows you to store a password, token, and, in principle, any string user data. It also allows you to automatically update the token if it goes bad, and many other useful things. 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 probably he just has to do it safely, because if they leak, then nothing good will come of it. You can say that on rutovanny android devices nothing is stored safely, and here I agree. However, if everything was limited only to root, then you would not read this “work” to you. To tell you why we are here, I will start from the very beginning.

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

            <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 notice, then we need to create a certain xml-file in the resources called authenticator.xml . Although the name here is not important, but the content is important. It then plays a key role in the story. The file inside looks like this:

    <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 thing is accountType . Without it, the application will not be able to add and receive accounts. And with this parameter you can intercept accounts of another application, even on devices without root. Let's see how this can happen.

    There is 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 now, if you delete application A , then all created accounts will go into the power of application Bwith full access. The converse is also true, the accounts of application B will be transferred to application A if B is deleted .

    Video example:


    Ahead of questions about apk signatures, it does not depend on which key the application was signed with, release or debit, the transfer will occur in any case. Awful, right?

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

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

    I did not cite examples of code in the article, since this makes no sense. With the source of the victim andinterceptor, you can be found at githabe.

    Thanks for attention!