知っておくべきAndroidアカウントマネージャーの脆弱性

読者の皆様、ご挨拶！ 多くの開発者は、アプリケーションでアカウントマネージャー（AM）の機能を使用します。 このツールを使用すると、いくつかのことを簡素化できるため、彼らはそれを正しく行っています。 これにより、パスワード、トークン、および原則として任意の文字列ユーザーデータを保存できます。 また、トークンに問題が発生した場合にトークンを自動的に更新することや、その他の多くの便利な機能を使用できます。 しかし、この便利さには別の側面があります-セキュリティ。 このため、私は実際にこのテキストを書きました。



AMを使用すると、パスワードやトークンなどの重要なデータを保存できるため、おそらく彼は安全にそれを行う必要があります。 rutovanny androidデバイスには安全に何も保存されていないと言うことができます。ここで同意します。 ただし、すべてがルートのみに制限されている場合、この「作業」は読みません。 私たちがここにいる理由を説明するために、最初から始めます。



一般に、アプリケーションでAMを使用するには、いくつかのジェスチャーを作成し、 AbstractAccountAuthenticatorとServiceの後継である2つのコンポーネントを作成する必要があります （ 詳細はこちら ）。 後者は、この方法でアプリケーションマニフェストに登録する必要があります。

<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>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、気付いた場合は、 authenticator.xmlというリソースに特定のxmlファイルを作成する必要があります。 ここの名前は重要ではありませんが、内容は重要です。 そして、物語の中で重要な役割を果たします。 内部のファイルは次のようになります。

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

labelパラメーターは、デバイス設定のアカウントのリストにある名前を担当します。最も興味深いのはaccountTypeです。 これがないと、アプリケーションはアカウントを追加および受信できません。 また、このパラメーターを使用すると、ルートのないデバイスでも、別のアプリケーションのアカウントをインターセプトできます。 これがどのように起こるかを見てみましょう。



accountType = "someType"のデバイスAにアプリケーションAがあり、このアプリケーションはアカウントを作成し、トークン、パスワード、およびその他の情報を追加します。 ある時点で、アプリケーションBは同じaccountType = "someType"でデバイスにインストールされます。 そして今、アプリケーションAを削除すると 、作成されたすべてのアカウントは、フルアクセスでアプリケーションBの権限に入ります。 逆も同様です。Bが削除されると、アプリケーションBのアカウントはアプリケーションAに転送されます。



ビデオの例：





apk署名に関する質問に先立ち、アプリケーションが署名されたキー、リリースまたはデビットに依存せず、いずれの場合でも転送が発生します。 ひどいですね



これはすべて、APIバージョン23までの肉体で実行できます。Android7.0（API 24）のリリースでのみ修正されました。 この状況では、このバージョンのアンドロイドを搭載したデバイスのごくわずかな割合が悲しいです。 ところで、私はandroidのセキュリティに関するレポートからこの問題について学びました 。 残念なことに、プレゼンテーションのテキスト、リテールでは、これについてはまったく何もありませんが、ビデオでは彼らはあまり重要視せずにさりげなく言及しました。



それでは、あなたは何を提案しますか？ -あなたは尋ねることができます。 そして、問題を解決するための2つのオプションを提供します。 1つは、AMの使用を継続することですが、すべての重要なデータを暗号化された形式で保存することです。 AMを信頼しなくなった場合は、AMの使用を継続できますが、重要なデータをAMに保存せず、AMを2番目のオプションと組み合わせて使用​​します。 2つ目は、AMを完全に放棄し、暗号化可能なストレージを使用することです。 たとえば、SQLiteとsqlcipherまたはRealmを組み合わせて、 すぐに使用できる暗号化をサポートします。 最後のものを選びました。 暗号化キーを生成および保存する方法を示すレルムの例を次に示します。



この記事ではコードの例を引用しませんでした。これは意味がないからです。 githubの被害者とインターセプターのソースコードに慣れることができます。



ご清聴ありがとうございました！