Androidアプリケーションのセキュリティ。 Yandexでの講義

開発者のDmitry Lukyanenkoは、今日公開している講義で、Yandexの専門家であるだけでなく、他社の開発者のソリューションの強度をテストする方法も知っています。 これにより、他人の間違いから学ぶことができます-もちろん自分の間違いを除外しないこともあります。 レポートでは、DmitryがAndroidの脆弱性の例を共有します。これには彼が個人的に見つけたものも含まれます。 各例には、Android用のアプリケーションを作成する方法としない方法という推奨事項が付随しています。







私の名前はDmitryです。私はMinskオフィスのYandexで働いており、アカウントマネージャーを開発しています。 これは、ユーザーの承認を担当するライブラリです。 したがって、Androidアプリケーションのセキュリティについて説明します。



次の問題の原因を特定します。 1つは、サーバーとの通信に関連するネットワークです。 これは、データがあまり安全でない方法で転送される場合です。 2つ目はデータストレージの問題に関連しています：これは、データがクリアな場所に保存される場合、SDカードのどこかに保存される場合、または一般的に外部からアクセスがある場合に暗号化されない場合です。



3番目のタイプの問題は、サードパーティのアプリケーションがあなたに与える影響です。 これは、サードパーティのアプリケーションがあなたのアプリケーションに不正にアクセスしたり、ユーザーに代わって何らかのアクションを実行したり、何かを盗んだりする可能性がある場合です。



このレポートでは、サードパーティアプリケーションの影響に関連する3番目のタイプの問題に焦点を当てます。 理論だけでなく、実際のアプリケーションからの特定の例を検討します。 さらに、これらの例のいくつかはまだ関連性があり、明らかに、彼らはそれらを採点したばかりですが、私には非常に興味深いようです。



このレポートは、Android開発に携わる人々に役立ちます。 アプリケーションを作成するすべての人にこれらの側面に注意を払うことをお勧めします。 たとえば、テスター。 テスターは、これらのニュアンスを見ると、ボーナスをノックアウトすることができ、プログラミングを実際に学ぶことができなくても、開発をより深く掘り下げ始めるでしょう。 マニフェストファイルは、潜在的に危険な場所を分析および識別することができます。 そして、そのようなセキュリティ問題に興味がある他のすべての人に。



始める前に、便利になるソフトウェアに言及する価値があります。 まず、非常に便利なプログラムであるBytecodeViewerを使用すると、1回のクリックでapkファイルからすべてのソース、マニフェストファイルを含むすべてのリソースを取得できます。



Androidの便利なユーティリティであるManifestViewerは注目に値します。 これにより、インストールされているすべてのアプリケーションのマニフェストファイルを非常にすばやく表示できます。 たとえば、人々が私のところに来て、「アカウントマネージャーが働いていません」と言ったとき、私は仕事でそれを使用します。 まず、マニフェストファイルを常に見て、アカウントマネージャーが正しく統合されていること、つまり、すべてのコンポーネントが必要に応じて宣言されていることを確認します。

このプログラムは、マニフェストファイルからの攻撃のベクトルであるエントリポイントをすばやく開いて確認するのに役立ちます。



コンソールからすべてを実行する場合、これらのプログラムはすべて個別に用意されています。 apktoolを使用すると、すべてのリソースとマニフェストファイルを引き出すことができます。 Dex2jarおよびenjarifyを使用すると、apkファイルをjarに変換できます。 Dex2jarはapkを変換しない場合があります。いくつかの例外があります。 絶望しないでください：多くの場合、enjarifyはこれらのファイルを食べ、jarを取得します。 これらは2つの優れたユーティリティです。



jarファイルを取得したら、Java Decompilerを使用して、より便利なビュー（クラスビュー）に変換できます。 起動できないことは明らかですが、そこで取得されたコードなどよりも分析がはるかに簡単です。



最も基本的な問題を見てみましょう。 まず、マニフェストファイルを分析する必要があります。これは、Androidアプリケーションのすべてのコンポーネントを必ず記述する必要があるためです。 これらは、アクティビティ、サービス、ブロードキャストレシーバ、ContentProviderです。 Broadcast Recieverを除いて、すべてがそこになければなりません。



したがって、いくつかの問題の検索を開始するとき、これらのコンポーネントを調べます。 以下に具体例を示します。 これは、1つのアプリケーションのマニフェストファイルで宣言されたサービスであり、明示的にエクスポートされます。 エクスポートされていることも明示的に述べられています。 これは、他のサードパーティアプリケーションで使用できることを意味します。 次に、他のアプリケーションがこのサービスにインテントを送信でき、サービスが提供されている場合、サービスはいくつかのアクションを実行できます。



この場合、攻撃の潜在的なベクトルがわかります。 深く掘り下げてソースを見ると、このプログラムで許可されたユーザーを削除するなど、このサービスで許可されていることが明らかになります。 開発者が一部のサードパーティアプリケーションにそのような機能を提供したとは思えません。 これは対処すべき具体的な例です。



もう1つのポイント：一部のコンポーネントがインテントフィルターを使用すると、デフォルトでエクスポートされます。 ここで、おそらく、初心者の開発者はつまずくかもしれません。 インテントフィルターがある場合、それだけです。このコンポーネントは既にパブリックです。 注意する必要があります。



対応するパネルに表示される通知に対していくつかのアクションを実行できる場合、この種の問題に遭遇しました。 たとえば、これはYandex.Mailおよびその他のアプリケーションで発生しました。



このイベントは何をしましたか？ パブリックBroadcastRecieverを使用して処理されました。 つまり、攻撃者は任意のブロードキャストを送信することもできます-レターのIDを取得して、たとえば削除します。 そして、これがパネルのメッセージである必要はありません。



昔々、Yandex.Mailにはこのような脆弱性がありました。 すべてがすでに修正されているので、あなたはそれを使うことができます、すべては大丈夫です。 Ildarのおかげで、彼らはすぐにこれをすべて実行します。



これはどのように決定されましたか？ コンポーネントは単に外部からアクセスできなくなり、許可が追加で設定されました。 それをインストールしないことは可能でした。主なことは、それがエクスポートされない場合、誰もそれに接続して何かをすることができないということです。



次のタイプの問題は、インテントが特定の場所を指定しない場合の暗黙的なインテントの使用です。 これは、このインテントが希望する場所に行くという保証がないことを意味します。 彼は別の場所に来るかもしれません。 したがって、ここで注意する必要があります。



暗黙的な意図に起因するもう1つのニュアンスは、ブラウザーからサードパーティアプリケーションのアクティビティを開くことができるときの、閲覧可能なアクティビティです。 これは、ある種のスキーム、ホストが指定されたときに発生し、クリックするとウィンドウが開きます。 ウィンドウが開いたばかりで、たとえば地図上の位置が送信された場合に便利です。 これは怖くない。 そして怖い-次。 会社でSlackを使用することを提案する人がいるとします。 Slackには非常に興味深い承認があります。 Androidブラウザーにログインしている場合は、インストール済みのSlackアプリケーションにログインできます。 これはこのスキームに従って動作します。ブラウザにURLがある場合、それをクリックしてSlackアプリケーションがインターセプトします。



ただし、URLが他の誰かに傍受されないという保証はなく、トークンがURLを介して送信されます。 スキームは非常に単純です。ブラウザをクリックすると、Slackアプリケーションですぐに承認されます。 したがって、このURLは認証に十分です。



ブラウザでクリックできるボタン、およびこの開始を開始するボタンは、ここでマークされています。 これは「Open Slack」であるだけでなく、ロゴでもあります-どの画面でも常に一番上にあります。



この問題の使用方法を示すビデオを見てみましょう。 ログインして、ディレクトリに移動し、Slackのロゴをクリックしましたが、Slackアプリケーションはありません。攻撃者はインテントフィルターを設定しました。 彼らは戻ってきて、クリックしました...フィッシングができます-Slackとまったく同じです。 許可が機能しなかったと書いてください。 ユーザーは何も理解せず、トークンを取得します。 したがって、Slackを使用する場合は、このブラウザー認証に注意してください。



解決策は非常に簡単です。 私の同僚が言ったように、ブラウザから開く明示的なインテントを使用できます。 しかし、私がSlackに登録し、私のチケットが80,000の数字を受け取ったとき、彼らはそれが複製であり、すでに50,000のチケットがあると言いました。 推定すると、6か月以上前に通知されたことがわかります。 非常に単純に修正されているようですが、修正されていません。 これは、これは重大な問題ではないことを意味し、それから私たちはそれについて話すことができます。



ここでは、常に明示的な意図を使用することが最善であるという推奨事項があります。 読んで深く掘り下げてみると、Androidにクールなタイプミスがあることがわかります。 彼らは1つの場所で暗黙の保留インテントを使用しました。 このため、システム権限を持つユーザーにアクセスできました。 彼らはAndroid 5でこれらのエラーを修正しました。Googleでさえ、誰もがそのようなエラーを持っています。



明示的な意図を使用するか、これが不可能な場合は、常に何らかの許可を設定することをお勧めします。 アクセスを制限できます。



ユーザーデータに基づく別のタイプの脆弱性を検討してください。







ユーザーからデータを受信できるアプリケーションがあります。たとえば、ファイルを送信したり、開いたり、表示したりできます。 これは通常、viewやsendなどの意図で行われます。



この悪意のあるアプリケーションは次のことを伝えることができます。自分のサンドボックスにあるプライベートディレクトリにあるファイルを送ってください。 このファイルが、すべての通信を含むデータベース、またはいくつかのトークンが保存されている場合の設定であるとします。 一部のアプリケーションは、これらのファイルに対していくつかのアクションを実行する場合があります。 たとえば、ファイルをSDカードにキャッシュしたり、どこかに送信したりできます。 はじめに、このファイルが攻撃者に利用可能になるようなアクションを実行できますが、最初は攻撃者は内部ファイルであると想定していました。



getAbsolutePath（）を使用して、ディレクトリがプライベートディレクトリと一致するかどうかを確認できます。 しかし、これは間違っています。



攻撃者はファイル自体ではなく、ファイルへのリンクを送信する場合があります。



このリンクはどのように作成できますか？ 攻撃者はreadme.txtを作成します-アプリケーションのプライベートファイルへのリンクを作成しました。 その後、彼はこのリンクをあなたに詰め込み、getAbsolutePath（）を使用すると、リンクパス（readme.txtファイルへのパス）が返されます。 そして、あなたはすべてがうまくいくと思います。



これを修正するには、getCanonicalPath（）メソッドを使用することをお勧めします。 彼は完全なパス、実際のパスを返します。 この場合、システムはreadme.txtではなく、何らかのメールボックスを返します。 これらの問題を考慮してください。



5000万人を超えるユーザーを持つ1つのアプリケーションが同様の問題を抱えている状況に遭遇しました。 あなたは言う：このファイルを見せて。 SDカードにキャッシュしてから、開こうとします。 そのため、すべてのトークンを盗むことができました。 彼らはすでにすべてを修正しましたが、まだ公開しないように頼みました。 ただし、これは発生します。



次の興味深い点：彼らはあなたにコンテンツプロバイダーへのリンクを送ることができます、そしてそれはまた送信することができます。 許可によって保護されていても、エクスポートできない場合でも、すべて同じです。アプリケーションがそれを開こうとすると、コンテンツプロバイダーにあるクエリメソッドが実行されます。



ここで注意する必要があります。 別のアプリケーションの別の実際の例を次に示します。 クエリメソッドからデータベースのバックアップを作成しました。 そこでは、バックアップタイプのアクションを転送することが可能であり、プログラムはすぐにSDカード上のデータベース全体を複製しました。 プロバイダーは保護されていることがわかりますが、データベース全体を取得するような方法でプロバイダーをスリップすることができます。





クエリメソッドで書くために誰にも会ったことはありませんが、読むために何かを開く方が常に良いです。 また、SQLインジェクションが発生する可能性があることも考慮してください。 現在、SQLインジェクションの可能性を発見したアプリケーションがいくつかあります。 しかし、それらには読み取り専用アクセスがあり、私はまだそこにさらに何かをすることが可能であるかどうかを理解していません。 しかし、SQLiteデータベース自体に脆弱性があり、既にそれほど害のない注入を実行できる場合はどうでしょうか？ それでも、開いたときに読み取り専用のアクセス権がある場合でも、許可しない方が良いでしょう。







次に、WebViewの1つの問題を見てみましょう。これは、バージョン5.0までのすべてのAndroidで機能し、SOPをバイパスできます。 このことから、WebViewでは誰にもファイルを開かせない方が良いと結論付けました。



このタイプの攻撃を検討してください。 悪意のあるアプリケーションがWebViewにアクセスできるかどうかをアプリケーションに尋ねる場合があります：index.htmlファイルを見せてください。 アプリケーションがindex.htmlを開いたとします。 ファイルの内容は非常に単純です。JavaScriptは、5秒後にファイル自体をiframeにロードし、そのままリロードします。



この期間中に、悪意のあるアプリケーションは指定されたファイルを削除し、アプリケーションからプライベートファイルへのシンボリックリンクに置き換えます。 5秒が経過すると再起動しますが、そのコンテンツはすでに同じプライベートファイルのコンテンツになります。 5.0より前のAndroidでは、WebViewの前でも、明らかにこれがシンボリックリンクであるという誤ったチェックがあります。 これにより、コンテンツを読むことができます。 見た目-ファイル名は同じであるため、SOPは破損せず、コンテンツを送信できます。つまり、JavaScriptはコンテンツを取得してサーバーに送信できます。



このタイプの攻撃は、WebViewで発見されるだけではありません。 彼は今でも1億以上のインストールがあるUCBrowserで働いています。 これは、Android 5.0より前のAndroidブラウザーのいくつかのバージョンでこれを見てきました。 彼はおそらくWebViewにも基づいています。 たとえば、Samsungの携帯電話ではこれを再現できませんでしたが、携帯電話ではAcerが動作します。



これがUCBrowserでどのように機能するかについての短いビデオをご覧ください。 これは小さな悪意のあるアプリケーションですが、動作する可能性があります。 あなたもベッドに行き、電話をかけ、突然活動が始まります、ページ。 あなたは眠り、そこで始まりました-ある種のiframe、確認、警告。 アラートがコンテンツを読み取った場合、このコンテンツをまったく同じ場所に送信できることを意味します。 これはbookmark.dbで、ブックマークはここに保存されます。 興味がある人は調査できると思います。 より多くのプライベートユーザーデータを検索できる場合があります。 クッキーを盗むこともできます。 ただし、サイトにちなんで命名されたCookieがあるため、並べ替える必要があります。 VKontakteを取ることができます。 まだ脆弱性がありますが、まだ修正されておらず、修正を急ぐ必要はないようです。





結論： WebViewがある場合、だれにもリンクを開かせないでください。 そして、あなたがまだ与えるなら、少なくともローカルファイルのオープンを禁止します。 この点で、Qiwi社は非常に優れた仲間です。私は彼らのアプリケーションを試しました。今すぐファイルを開くことができて嬉しかったです。しかし、彼らはローカルファイルを開くことを禁じ、何もしませんでした。



次のような重要な問題を考えてみましょう。 これは、Androidの逆シリアル化の機能に基づいています。 おそらく、Javaの開発者自身が役に立つかもしれません。



アプリケーションに転送されるデータを含むインテントがあると想像してください-1つのフィールドを取り、インテントからそれを読み取ります。 また、アプリケーションが少なくとも1つのフィールドを読み取る場合、インテント内のすべてのデータの自動逆シリアル化が行われます。 使用されていない場合でも、デシリアライズされます。 ここで何が危険であるかを理解できます。



5.0までのAndroidにはこのようなボーナスがあります。一部のバージョンでは、逆シリアル化中に、クラスが実際にシリアル化インターフェイスを実装するかどうかはチェックされません。



これは、アプリケーション内にあるすべてのクラスが脆弱である可能性があることを意味します。 はい、それらはシリアル化できない場合がありますが、後で説明する基準に適合する場合は...



それで、何がそんなに危険なのですか？ オブジェクトが作成された場合、いつか削除されます。 通常、finalizeメソッドが呼び出されますが、危険なことはなく、実装されているものもありません。 ただし、ネイティブ開発がある場合、通常はfinalizeメソッドでネイティブエリアからデストラクタを呼び出し、そこにポインタを渡します。 ネイティブ開発はしませんでしたが、ポインターがどのように渡されるかを研究しました。 このポインターがシリアル化されている場合、攻撃者は自分のポインターを置き換えることができ、その結果、攻撃者はエラーをメモリの境界を越えたり、別のメモリをポイントしたりして、コードを取得して実行できます。



IBMのスタッフはこれを利用しました。 彼らは、Androidプラットフォーム上のクラスのリスト全体を分析しました-1000以上、またはいくつあるかをチェックしました。 そして、彼らは基準を満たすものだけを見つけました。それはシリアライズ可能であり、ネイティブポインターをシリアライズしました。 彼らはこのクラスを取り、ポインタを置き換え、シリアル化および非シリアル化されました。 彼は毎回新しいわけではありませんでした。 概念実証、デモンストレーション、ビデオがあります。 この脆弱性により、彼らはこのクラスを使用してシステムアプリケーションにインテントを送信することができました。 たとえば、元のFacebookアプリケーションを削除して、偽のアプリケーションに置き換えることができました。 ビデオは約7分間続きますが、そこでメモリをクリアしながらファイナライズが呼び出されるまで、回転させる必要があります。 ただし、結論は、ネイティブポインターを逆シリアル化する必要はないということです。







まとめると。 アプリケーション内のコンポーネントをエクスポートしないでください。 または-許可によりアクセスを制限します。 インテントは常に、明示的に設定するか、アクセス許可を設定する方が適切です。 ユーザーから送られてくるデータは絶対に信頼しないでください-プライベートエリアであっても、あらゆるデータを収集できます。 後で損傷する可能性があります。 SQLインジェクションなどを含むContentProviderに注意してください。



WebViewのようなものはおもちゃ用ではありません。 アプリケーション内にある場合は閉じて、だれにも遊ばせないでください。



シリアル化、つまりネイティブ開発も一致するようになりますので、注意してください。 ご清聴ありがとうございました。