IT knowledge base
CTRL+F per cercare la tua parola chiave

Vulnerabilità di Android Account Manager di cui devi essere a conoscenza

Saluti, caro lettore! Molti sviluppatori utilizzano le funzionalità di Account Manager (AM) nelle loro applicazioni. E giustamente, perché questo strumento ti consente di semplificare alcune cose. Ti consente di memorizzare una password, un token e, in linea di principio, qualsiasi dato di stringa utente. Ti consente anche di aggiornare automaticamente il token se va male e molte altre cose utili. Ma questa comodità ha un altro lato: la sicurezza. Per questo motivo, in realtà ho scritto questo testo.
Poiché AM ti consente di memorizzare dati così importanti come una password e un token, allora forse è semplicemente obbligato a farlo in sicurezza, perché se perdono, non ne verrà fuori nulla di buono. Puoi dire che nulla è archiviato in modo sicuro su dispositivi Android con root e sono d'accordo qui. Tuttavia, se tutto fosse limitato solo alla radice, non leggeresti questo "lavoro". Per spiegare perché siamo qui riuniti, comincerò dall'inizio.
In generale, per lavorare con AM nell'applicazione, è necessario eseguire diversi movimenti del corpo e creare due componenti: il successore di AbstractAccountAuthenticator e Service ( maggiori dettagli qui ). Questi ultimi dovranno essere registrati nel manifesto di domanda in questo modo:
        <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>
Inoltre, se l'hai notato, dobbiamo creare un determinato file xml nelle risorse chiamate authenticator.xml . Anche se il nome non è importante qui, ma il contenuto è importante. Quindi gioca un ruolo chiave nella storia. Il file è simile a questo all'interno:
<account-authenticator 
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:accountType="@string/account_type"
    android:label="@string/app_name" />
Il parametro label è responsabile del nome nell'elenco degli account nelle impostazioni del dispositivo e il più interessante è accountType . Senza di esso, l'applicazione non sarà in grado di aggiungere e ricevere account. E usando questo parametro, puoi intercettare gli account di un'altra applicazione, anche su dispositivi senza root. Vediamo come questo può accadere.
Sul dispositivo è presente l'applicazione A con accountType = "someType", questa applicazione crea un account, aggiunge un token, una password e altre informazioni. A un certo punto, sul dispositivo viene installata l'applicazione B con lo stesso accountType = "someType". E se elimini l'applicazione A , tutti gli account creati passeranno al potere dell'applicazione B con accesso completo. È vero anche il contrario, gli account dell'app B verranno trasferiti all'app A se B viene eliminato.
Esempio video:
Prima delle domande sulle firme apk, non dipende da quale chiave è stata firmata l'applicazione, rilasciata o debug, il trasferimento avverrà in ogni caso. Terribile, non è vero?
Tutto questo può essere fatto in carne e ossa fino alla versione API 23. Risolto solo con il rilascio di Android 7.0 (API 24). La tristezza in questa situazione è una percentuale trascurabile di dispositivi con questa versione di Android. A proposito, ho appreso di questo problema dal rapporto sulla sicurezza in Android . Sfortunatamente, nel testo, la rivisitazione della presentazione, non c'è proprio nulla a riguardo, ma nel video se ne è parlato di sfuggita, senza attribuire molta importanza.
Quindi cosa suggerisci? - potresti chiedere. E ti offro due opzioni per risolvere il problema. Il primo è continuare a utilizzare AM, ma archiviare tutti i dati importanti al suo interno in forma crittografata. Se smetti di fidarti di AM, puoi continuare a utilizzarlo, ma non memorizzarvi dati importanti e utilizzare AM insieme alla seconda opzione. Il secondo è rinunciare del tutto all'AM e utilizzare lo spazio di archiviazione che può essere crittografato. Ad esempio SQLite in combinazione con sqlcipher o Realm , che supporta la crittografia immediatamente . Ho scelto quest'ultimo. Ecco un esempio per realm che mostra come generare e memorizzare una chiave di crittografia.
Non ho fornito esempi di codice nell'articolo, poiché non ha senso. Puoi familiarizzare con il codice sorgente della vittima e l' intercettore su github.
Grazie per l'attenzione!