Clever Geek Handbook

Androidアプリケーションのセキュリティに関する懸念：分類と分析





画像 ： etnyk 、 CC BY-NC-ND 2.0



日常生活でスマートフォンを使用することは、音声通話とSMSに限定されません。 プログラムのダウンロードと実行、およびモバイルインターネットアクセスにより、膨大な数のモバイルアプリケーションが登場しました。 最新のスマートフォンの機能は、ブラウザー、ソーシャルネットワークのクライアントプログラム、オフィスアプリケーション、およびWeb上で動作するあらゆる種類のサービスで構成されています。 Androidプラットフォームのオープンアーキテクチャと便利な開発者APIにより、Androidデバイスはスマートフォン市場の大部分を占めています。 Androidは現在75％以上の市場シェアを持つ最も人気のあるモバイルOSです。 2016年にGoogle Playストアからダウンロードされたアプリケーションの数は、650億に達しました[1] 。



同時に、悪意のあるアプリケーションの数が急速に増加しています。2015年には230万が検出されました[3] 。 さらに、Androidデバイスの約60％は既知の脆弱性を持つOSのバージョンで実行されており、サイバー犯罪者によって潜在的に攻撃される可能性があります[6] 。 これらの脅威は、順番に、防御の開発につながりました。 公式のGoogle Playストアでは、Google Bouncerサンドボックスを使用したアプリケーションフィルタリングを導入しました。 アンチウイルス企業は、Android向けの製品のリリースを開始しました（ただし、 [8]に示されているように、それらの多くには危険な脆弱性が含まれています）。 このトピックに関する科学出版物の数も増加しています。Androidのセキュリティソリューションに関する2015年のレビュー作業の1つ[2]には40以上のプロジェクトがあり、現在知られているすべての研究が言及されているわけではありません モバイルデバイスは大量の機密データのソースおよびストレージであるという事実により、Android OSとそのアプリケーションのセキュリティ問題は特に深刻です。



Androidプラットフォームはフリーソフトウェアであり、そのソースコードベースは完全にオープンです。 デバイスメーカーは独自にコードベースを開発し、より優れた機能とパフォーマンスを実現するために専用のファームウェアを作成します。 このアクティビティの副産物は、メインコードベースにはないが、多くの実際のデバイスに存在するアルゴリズムの実装における脆弱性と弱点です。 悪意のあるソフトウェアはこれらの脆弱性を悪用して特権を昇格させ、防御メカニズムを克服します。 ソースコードがない場合にファームウェアの脆弱性を識別することは非常に困難です。 主な問題は、動的分析に必要な制御された実行環境の欠如です。



したがって、デバイスのセキュリティを完全に分析するには、システムとアプリケーションソフトウェアのプロパティ全体を調査する必要があります。 この記事では、Androidセキュリティ問題の独自の分類と、Androidプラットフォームのシステム全体の分析の要件のリストを示します。



1. Android OSデバイス



Android OSは、Linuxカーネルに基づいており、Googleのエンジニアによってアーキテクチャが変更されています。 Androidオペレーティングシステム用のアプリケーションは、Java言語で開発されています。 Android 1.5以降、Android NDKツールキットが導入されました。これにより、CおよびC ++でアプリケーションモジュールを開発し、それらをマシンコードにコンパイルできます[4] 。 アプリケーションは、特定のディレクトリとファイル構造を持つZIPアーカイブである特別なAPK形式のファイルの形式で配信されます。 アプリケーションのAPKファイルには以下が含まれます。





Android 4.4以降では、Dalvik VMとARTという2つのアプリケーションランタイムがサポートされています。 APKファイルを準備するプロセスは変更されておらず、新しいARTランタイム環境にアプリケーションをインストールするプロセスのみが変更されていることに注意してください。 バージョン5.0以降、Dalvik VMの代わりにARTランタイムがデフォルトで使用されました。



Android上のDalvik VM Javaプログラムのランタイム環境は、「通常の」Java VMとは大きく異なります。 まず、Javaプログラムをコンパイルすると、Dalvik仮想マシンのバイトコードにコンパイルされます。これは、HotSpot仮想マシンのバイトコードとは大きく異なります。 Dalvik仮想マシンはレジスタベースであるため、モバイルデバイスでよく使用されるRISCアーキテクチャでの実行がより効率的になります。 Dalvikの開発では、モバイルデバイスのメモリ制限も考慮しました。 Android 2.2以降、Dalvikランタイムには、「ホット」なJavaプログラムコードをマシンコードにコンパイルするJITコンパイラが含まれています[5] 。



標準のJavaライブラリは、Apache Harmonyパッケージから変更されたライブラリに置き換えられるか、書き直されました。 Javaプログラムをコンパイルすると、Dalvik仮想マシンのバイトコードを含むDEX（Dalvik Executable）ファイルが取得されます。 ファイル形式はメモリフットプリントを削減するように設計されており、標準のJAR形式とは大きく異なります。 Javaプログラムからマシンコードに実装されたモジュールを呼び出すには、JNIインターフェイスが使用されます。 DexClassLoaderコンポーネントを使用して、ネットワーク経由でマシンモジュールを動的にロードできることは注目に値します。



2.セキュリティ上の懸念



Android OS上のすべてのアプリケーションの親プロセスは、Zygoteプロセスです。 このプロセスは、Android環境に必要なすべてのライブラリが既にロードされているAndroidアプリケーションフレームワークですが、アプリケーション自体のコードが欠落しています。 オペレーティングシステムに関するAndroidアプリケーションの起動は次のとおりです。



  1. 最初に、Zygoteプロセスの子孫を作成するためにforkシステムコールが作成されます（図1を参照）。
  2. この新しいプロセスでは、起動されたアプリケーションのファイルが開かれます（システムコールを開きます）。
  3. アプリケーションファイルからクラスファイル（classes.dex）およびリソースに関する情報を読み取ります。 IPC用のソケットの開口部があります。
  4. mmapシステムコールは、アプリケーションファイルをメモリにマップするために行われます。
  5. ランタイムは必要な環境を調整し、アプリケーションを実行します（Dalvikバイトコードを解釈するか、ART [7]の場合、実行可能コードの機能に制御を転送します ）。


Android OSのカーネルレベルでは、各アプリケーションは、インストール中に付与される一意のユーザー/グループID値を持つ個別のプロセスです。 したがって、各プログラムは独自のサンドボックスで動作します。 バージョン4.3以降、このセキュリティポリシーに加えて、必須アクセス制御コンポーネントSELinux [10]の使用が追加されました。







図 1. Android OSで新しいアプリケーションを起動する



デフォルトでは、アプリケーションの機能は制限されており、他のアプリケーションやユーザーに悪影響を与えることはできません。ユーザーデータを読み取ったり、システムアプリケーションを変更したりすることはできません。 ネットワークアクセスなし。 さまざまなリソースにアクセスするために、アプリケーションはAndroid OSのサービスにアクセスします。 アクセス許可は、アプリケーションマニフェストファイルで静的に設定され、必要に応じて操作中にアプリケーションに発行されます。 システムは、インストール中またはアプリケーションの更新中にこれらの権限を発行するための同意をユーザーに求めます。 アプリケーションへのアクセスを許可する責任はユーザーにあり、インストール中に特定のアクションに対して許可するアプリケーションと許可しないアプリケーションをユーザーが独自に決定します。 このアプローチでは、アプリケーションのインストール時にすべてのアクセス許可が一度に発行されるため、ユーザーは結果を考慮せずにアプリケーションにアクセス許可を与えることになりました。 次に、機能が拡張されるにつれて、アプリケーションはますます多くの許可を要求し始めました。 Android 6 Marshmallowでは、このシステムは別のシステムに置き換えられます。アプリケーションは、作業中にユーザーにリソースへのアクセスを要求し、ユーザーはアクセスを許可または拒否できます[11] 。



Androidアプリケーションは4種類のコンポーネントで構成されており、main（）関数やその他の単一のエントリポイントは含まれていません。 アプリケーションコンポーネントは、Intentと呼ばれる特別なメッセージを使用して相互に通信します。



アクティビティと呼ばれるコンポーネントは、ユーザーインターフェイスを定義します。 通常、単一のアクティビティコンポーネントを使用して、単一のアプリケーション画面を記述します。 アクティビティは、インテントメカニズムを使用してパラメータを渡すことにより、別のアクティビティを開始できます。 操作中、ユーザー入力を処理および処理できるアクティビティは1つだけであり、選択されたアプリケーションモードに応じて、この時間の残りは凍結または破棄されたままです。



サービス[9]と呼ばれるコンポーネントは、バックグラウンド処理を実行します。 アクティビティがファイルのダウンロードや音楽の再生などの何らかの操作を実行する必要があり、ユーザーが別のアプリケーションに切り替えたり、現在のアプリケーションを最小化したときに作業を続けると、アプリケーションはこの操作を実行する目的のサービスを開始します。 開発者は、ブート時に起動するデーモンアプリケーションとしてサービスを使用できます。 原則として、サービスコンポーネントはRPC（リモートプロシージャコール）をサポートしているため、システムの他のコンポーネントがRPCにアクセスできます。



コンテンツプロバイダーコンポーネントは、リレーショナルデータベースインターフェイスを使用してデータを保存および交換します。 各コンテンツプロバイダーには、データの一意のURIが含まれ、SQLキュー（選択、挿入、削除）の形式でデータへの要求を処理します。



ブロードキャストレシーバーコンポーネントは、他のアプリケーションからのメッセージボックスとして機能します。



Android OSで発生するセキュリティ問題は[ 2、12、13 ]で検討されましたが、カテゴリによる問題の分類は記事[2]でのみ説明されています。 この分類は非常に詳細であり、多くのセキュリティ上の問題をカバーしていますが、いくつかの重大な欠点があります。一部のカテゴリは広範な脆弱性をカバーし、他のカテゴリは非常に専門的です。 指定された脆弱性のカテゴリは、Android OSアーキテクチャのソフトウェアレベルとは相関しません。 インターネットソースからの脆弱性はカバーされておらず、プロトコルとハードウェアの脆弱性はほとんどカバーされていません（分類の2.7節と2.8節）。 以下に提案する脆弱性分類は、これらの欠点に対処しています。



2.1。 Linuxカーネルとそのモジュールの脆弱性



このカテゴリの問題には、Android OSと同じバージョンのLinuxカーネルに基づくすべてのOSに固有の脆弱性が含まれます。 カーネルの脆弱性を悪用するエクスプロイトは、ユーザーデータまたはシステム管理者権限を取得できます。 プロセスの特権をシステム管理者権限に引き上げることにより、悪意のあるプログラムはAndroidセキュリティシステムを無効にし、悪意のあるコードを既存のプログラムに挿入し、ルートキットをインストールできます。 さらに、さまざまなデバイスのメーカーは、デバイスのモジュールをカーネルに追加します。 これらのモジュールにも脆弱性がある可能性があります。 特権エスカレーションの脆弱性の例は、[ 14、15、16、64 ]で説明されています。 また、Androidのプロセス間通信のashmemコンポーネントに脆弱性が最近発見されたことも注目に値します[62] 。



2.2。 デバイスメーカーの変更およびコンポーネントの脆弱性



最近、さまざまなモバイルデバイスのメーカーが、変更されたAndroidファームウェアのリリースを開始しました。 これらのファームウェアには、デバイスの製造元が開発したさまざまなアプリケーションやサービスが含まれている場合がありますが、ほとんどの場合、これらは削除できません。 たとえば、2016年10月に、Foxconnファームウェアで非表示のバックドアが発見されました[63] 。 記事[17]に示されているこれらのサービスの分析では、システム全体で見つかった脆弱性の65〜85％が含まれていることが示されています。 さらに、メインのAndroidブランチで発見および修正された脆弱性は、デバイスメーカーのブランチに長期間残る可能性があることに注意する価値があります[ 18、19 ]。



2.3。 マシンコードのモジュールの脆弱性



Androidアプリケーションは、JNIインターフェイスを介したマシンコードの実行をサポートしています。 これにより、低レベル言語（CやC ++など）のメモリリークで広く知られている脆弱性に関連する、さらに別のカテゴリの脆弱性が発生します[20] 。 Android OSのプロセスレベルにはLinuxカーネルによって課せられるもの以外の制限がないため、マシンコード内のサードパーティライブラリは、アプリケーション全体に発行された権限を使用して悪意のあるアクティビティを実行できます（次のカテゴリの脆弱性、セクション2.4も参照してください）。 また、悪意のあるアプリケーションの作成者は、マシンコードのアプリケーションモジュールを使用して、Androidレベルの分析および監視ツールを回避します。 これらのモジュールは、従来のプログラムで使用されている分析防止技術も使用できます。



2.4。 インターコネクトメカニズムの脆弱性



このカテゴリには、さまざまなアプリケーションコンポーネント間の相互作用に関連する脆弱性が含まれます。 アプリケーションはオペレーティングシステムレベルでプロセスサンドボックスによって制限されるため、Android OSコンポーネントにアクセスしてそれらとやり取りするためのメカニズムが必要です。 これは、/ dev / Binderデバイスおよびその他のさまざまなAndroid OSサービスを介して発生します。 前述のように、このアクセスのパラメーターは、許可を持つXMLファイルとしてマニフェストファイルで設定されます。 記事[12、21、22、23、24、25]に記載されている分析は、この制限システムの欠点を示し、それらを回避する方法を示しています。 そのため、たとえば、アプリケーションは別のアプリケーションのアクセス権を使用し、ICCを介してそれを使用してデータを受信できます。 サードパーティのライブラリに関連する脆弱性もあります。 アプリケーションで使用されるサードパーティライブラリは、アプリケーション自体と同じ制限のセットを受け取ります。 したがって、サードパーティのライブラリは、アプリケーション全体に付与された権限を使用して、悪意のあるアクティビティを実行できます。 アプリケーションは、ブロードキャスト要求を介して転送されるシステムイベントをインターセプトし、着信コールとSMSに関する情報を保存することもできます。



2.5。 アプリケーション自体の脆弱性



各アプリケーションは、ユーザーに関するデータを保存します。 このデータは、他のアプリケーションがアクセスできないように適切に保護する必要がありますが、そのような保護が常に提供されるとは限りません。 たとえば、アプリケーションの1つのバージョンのSkypeは、連絡先データベースをディスク上のクリアテキストで保存しました。 したがって、連絡先はディスクにアクセスできる他のアプリケーションによって読み取ることができます[26] 。 また、アプリケーションはエラー[27]または独自の実装で暗号化ライブラリを使用できます。 さらに、すべてのアプリケーションが適切な認証とユーザー承認を生成するわけではありません。 さらに、アプリケーションはSQLインジェクションを許可でき、XSS攻撃を受けやすくなります。 また、開発中のアプリケーションのほとんどはバイナリコードの保護を使用せずにJavaで記述されており、ご存じのようにJavaバイトコードは簡単に分解および分析できます。 有名なMobile OWASP-10リストもこのカテゴリの脆弱性に属していることに注意してください。 これらの脆弱性の多くは、[ 28、29 ]で説明されています。



2.6。 組み込みサービスとライブラリの脆弱性



Androidで実行されるライブラリとサービスの標準セットにも脆弱性が含まれています。 たとえば、MMSメッセージにビデオを表示するためのライブラリでStagefrightの脆弱性が最近発見されました。これは、2.2から始まるすべてのバージョンのAndroidの影響を受けました[30] 。 その後、MediaServerコンポーネントに脆弱性が発見され、2.3から5.1までのAndroidのすべてのバージョンに影響します[31] 。 [13]の記事には、Dalvikランタイムの脆弱性が示されています。システムで多数のプロセスを実行することにより、後続のプロセスが管理者権限で開始されることを保証できます。



2.7。 インターネットソース



Androidアプリケーションは、公式アプリストアに加えて、さまざまなソースを介して配布されます。 Androidアプリケーションは主にJavaで記述されているため、悪意のあるコードを使用して簡単にリバースエンジニアリングおよび再パッケージ化することができます[ 32、33 ]。 さらに、 [34]に示されているように、公式カタログで使用されているバウンサーアプリケーション分析サンドボックスは簡単にバイパスできます。 そのため、公式ストア自体には多数の悪意のあるプログラムが含まれています。 さらに、Androidは、Googleアカウントに関連付けられたデバイス上で、Google Playを介したアプリケーションのリモートインストールをサポートしています。 したがって、デバイスのGoogleアカウントをハッキングすると、攻撃者が以前にダウンロードした悪意のあるアプリケーションをGoogle Playからインストールできます。 さらに、携帯電話の画面では、ブラウザウィンドウで要求され、インターネットにアクセスするときにアプリケーションがバックグラウンドで電話にインストールされるため、これらのアクションの確認は必要ありません。 また、ソーシャルエンジニアリングの使用は、このカテゴリの脆弱性を指し、許可されていないソースからアプリケーションをインストールして作業を継続することを提案します[35] 。



2.8。 ハードウェアおよび関連するモジュールとプロトコルの脆弱性



Android OSを実行するモバイルデバイスには、外の世界とやり取りするためのさまざまな機器があります。 対応する脆弱性は、デバイスのすぐ近くで、またはデバイスに物理的にアクセスして悪用される可能性があります。



このような攻撃の例には、Wi-Fi Directテクノロジーに対するサービス拒否攻撃[36] 、NFCを使用したクレジットカードデータの盗難[37] 、Bluetoothによるリモートコード実行[38] 、adbによるユーザーの知らない悪意のあるアプリケーションのインストールが含まれますバックアップメカニズムの使用[39] 。 作業[13]は、adbプロトコルの実装のエラーを使用して、アプリケーションの特権を高めるために使用できる脆弱性を示しています。



3. Androidアプリケーションを分析するためのツール



最初のAndroidフォンがリリースされてから、Androidアプリケーションを分析するための多数のツールが作成されました。 これらのツールの最も完全なレビューは、記事[ 40、41、42、2 ]に含まれています。 最初の3つのソースでは、ツールは分析のタイプ（静的、動的、およびそれらの組み合わせ（混合））によって分類されています。 記事[2]では、Androidデバイスでのアプリケーション展開の段階ごとにツールの分類を使用しています。 私たちの仕事では、分析のタイプによる分類が使用されます。



静的解析



静的分析ツールは、次のカテゴリに分類できます。





最も一般的なリバースエンジニアリングツールの1つはApktoolです[43] 。 ほぼ元の形式でアプリケーションリソースをデコードし、アプリケーションをAPK / JARファイルに再パッケージし、smaliバイトコードをデバッグする機能があります。 apktoolでDalvikバイトコードを逆コンパイルしてコンパイルするために、別の有名なsmali / backsmaliプロジェクトが使用されます[44] 。 また、Delvikバイトコードを逆アセンブルするためにDedexerツール[45]がよく使用されます。



Radare2 [46]は、Androidアプリケーションのバイナリファイルを分解、分析、デバッグ、および変更するためのオープンソースツールです。



静的解析のための最も汎用性の高いツールの1つは、アンドロガード[47]です。 アプリケーションを逆アセンブルして逆コンパイルし、Javaソースコードに戻すことができます。 2つのAPKファイルを受け取った彼は、再パッケージ化されたアプリケーションまたは既知の悪意のあるアプリケーションを検出するための類似度係数を計算できます。 その柔軟性により、一部の混合分析ツールで使用されます。



静的解析ツールのより完全なリストは、上記の記事に記載されています。 静的解析には、プログラムの抽象概念しか存在しないという事実に関連する多くの重要な制限があることに注意してください。 たとえば、プログラムに難読化変換を適用すると、静的分析ははるかに複雑になります。 難読化の複雑さに応じて、一部の（またはおそらくすべての）静的アプローチは完全に役に立たなくなる可能性があります。 各メソッドが間接的にのみ呼び出される場合、プログラム呼び出しのグラフを作成することは不可能です。 Androidでは、通常の呼び出しと命令を使用して新しいオブジェクトを作成する代わりに、Java Reflection APIを使用してメソッドを呼び出してオブジェクトを作成することで、このような変換を行うことができます。 Androidアプリケーションファイルを難読化するためのいくつかの製品は、ソースコード保護ソリューション市場で既に発表されており、静的分析のすべての利点を無効にする可能性があります[ 48、49 ]。 静的解析に対抗するための手法の詳細については、 50をご覧ください。



動的および混合分析ツール



動的分析ツールは、動作トレースを取得するために制御されたサンドボックスで起動されたときに、実行時に不明なアプリケーションの動作を追跡します。 これを行うために、サンドボックスは、アプリケーションとAndroid OSの動作を追跡するコードセクションを備えたさまざまなレベルのアーキテクチャで装備されています。







図 2. Android Sandboxアーキテクチャレベル



Androidサンドボックスのアーキテクチャは、Androidエミュレーター（ほとんどの場合QEMU）であり、内部でAndroid OSが動作します。 インストルメンテーションは、エミュレータレベル、Android OSレベル、またはその両方で実行されます。 Android OSレベルも4つのサブレベルに分かれています。





動的アプリケーション分析で使用される手法：





混合分析ツールには、動的分析手法と静的分析手法を組み合わせたツールが含まれます。



4. Androidプラットフォームの完全なシステム分析に理想的なシステム



記事[40、41、42、2]には、Androidアプリケーションの分析とAndroid OSの一般的な分析の両方のための40を超えるさまざまなツールが含まれています。 記事[ 34、60、61 ]で述べたように、既存の動的解析ツールには多くの重大な欠点があります。 これらの欠点は、Google Playストアの標準的なアプリケーション分析ツールであるGoogle Bouncerに固有のものであり、その結果、悪意のあるアプリケーションが検出されずに公式ストアを介して配布される可能性があります。



レビューされた出版物のアプローチとシステムの機能の比較により、アプリケーションとシステムソフトウェアのすべての層を一緒に分析できるAndroidプラットフォームの理想的な分析システムの要件を策定できます。 システムは、既存のソリューションの欠点を克服するために、検討中の作品からいくつかの効果的な手法を取り入れ、それらを組み合わせます。







システムのアーキテクチャを図に示します。 3.メインコンポーネントはフルシステムエミュレーターで、実際のデバイスからAndroid OSファームウェアとエミュレーターの公式Androidイメージの両方をダウンロードできます。 エミュレータは、実際のデバイスからのセンサーのプローブ、および実際のデバイスでのコードの個々のセクションの実行をサポートします。 エミュレーター内では、次の機能を提供するモジュールが機能します。





このシステムの要件のリスト：



1.さまざまなデバイスのメーカーからのファームウェアのダウンロードのサポート



Android OSとそのアプリケーションの既存のすべての分析ツールの重大な欠点は、アクセス可能なエミュレーターでデバイスメーカーのファームウェアを実行できないことです。 セクション2.2に示すように、デバイスメーカーから変更されたファームウェアには、システム全体で見つかった脆弱性の65〜85％が含まれています。 現時点では、メーカーのファームウェアを実行できる分析ツールはありません。 既存のすべてのソリューションは、GoldFish仮想プラットフォーム用の特別なAndroidアセンブリで動作します。



2.実際のデバイスでマシンコードの個々の部分を実行する機能



記事[ 34、61 ]の情報によると、エミュレーター内の作業を検出する方法があります。 原則として、ほとんどのサンドボックスはそれに基づいているため、バイナリ変換モードのQEMUエミュレーターで実行が検出されます。 これらのメソッドは、エミュレーターと実際のデバイスのマシンコードの特定のセクションの異なる動作に基づいています。 バイナリ変換のメカニズムを変更するのは難しいタスクであるため、エミュレータを検出するこれらの方法に対抗するには、実際のデバイス上でマシンコードの個々の部分を実行するのが良い方法です。



3.実デバイスの機器のセンサーからエミュレーターへのデータ転送



記事[ 34、61 ]に記載されているように、加速度計、ジャイロスコープ、GPS、光センサー、重力などの機器センサーから受信したデータに基づいてエミュレーターを決定する方法があります。 これらのセンサーの出力値は環境から収集された情報に基づいているため、それらの現実的なエミュレーションは困難な作業です。 これらの種類のセンサーの存在は、スマートフォンとデスクトップコンピューターの主な違いです。 スマートフォンのセンサーの数が増えると、モバイルデバイスを識別する新しい機会が提供されます。



4. Javaコードとマシンコードのレベルでの共同分析



多くのAndroidアプリケーション分析システムの難点は、アプリケーションにDalvikバイトコードモジュールとマシンコードモジュールの両方が含まれていることです。 既存のソリューションのうち、すべてのモジュールの分析のサポートは、DroidScope [57]およびCopperDroid [ 58、59 ]でのみ実装されています。 理想的な分析システムでは、ユーザーおよびシステムコードのレベルでデータと制御フローを追跡できる必要があります。 カスタムコードの場合は、可能な限り、プレゼンテーションレベルをJavaコードに引き上げる必要があります。Javaコードは、高レベルの開発言語です。 また、マシンコードからJavaへ、またはその逆への移行中に、データと制御フローの「接着」を提供する必要があります。



5.コンポーネント間分析のサポート



CopperDroid [58]に関する記事は、Androidアプリケーション内と異なるアプリケーション間のコンポーネント間相互作用の分析のサポートの実装を示しています。 これは、すべての相互作用が通過するため、バインダーカーネルコンポーネントを通過するデータをインターセプトすることによって行われます。 CopperDroidに実装されたアプローチにより、Androidのソースコードを変更する必要がなくなり、Android OSの新しいバージョンと最小限の変更で新しいARTアプリケーション起動環境に移植することが可能になります。



6.静的検出ヒューリスティックに対する保護



[ [57] 、 61 ]の記事に示されているように、分析用のほとんどのサンドボックスは、デバイスのIMEI、IMSI、またはファームウェアビルド番号をチェックするだけで検出できます。 また、ルーティングテーブルで標準値を確認することで、エミュレータを検出できます。 既存のソリューションのうち、静的ヒューリスティックによる検出に対する保護は、ApkAnalyzerプロジェクト[65]でのみ実装されています。



7. Androidファームウェアの最小限の変更



また、多くの動的解析ソリューションは、Android OSのさまざまなコンポーネント、特にDalvik仮想マシンのコードのインストルメンテーションに基づいていることに注意してください。 これにより、継続的なサポートと、新しいARTアプリケーション起動環境への移行が複雑になります。 多くのサンドボックスはJavaコンポーネントのコード分析のみに制限されていますが、マシンコードでコンポーネントを使用するアプリケーションが増えています。



8.追跡制御フローを使用したタグ付きデータのフルシステム分析のサポート



動的分析ツールの多くが、TaintDroidツールを使用したタグ付きデータの分析を使用していることは注目に値します[56] 。 記事[60]は、このツールの分析をバイパスするための成功した方法を示しました。 これらの攻撃が成功する理由は、1）TaintDroidがデータストリームのみを監視し、制御フローを監視しない、2）TaintDroidがDalvik仮想マシンレベルでのみデータストリームを監視し、JNIインターフェイスを通過することです。 これらの欠点を解決する可能な方法は[60]で説明されており、さらなる研究の方向性を示しています。



9.静的コード分析から得られたデータを使用した、特定の値を使用したシンボリック実行および部分実行のサポート（コンコリック実行-混合実行）



記事[51]は、このアプローチを実装する分析環境について説明しています。 この環境は、プログラムの制御フローのグラフの静的分析、プログラムのシンボリック実行、および特定の値を持つプログラム実行の手法を組み合わせたものです。 シンボリック実行とプログラム実行の手法を特定の意味で組み合わせたアプローチは、記事[ 52、53、54、55 ]で説明されています。 このメソッドの目的は、「興味深い」コードを含むプログラムのセクションに至る実行パスを観察することです。 「興味深い」コードは、そのようなコードを意味すると理解され、その実行は、発生した外部イベントまたはシステム環境の設定に依存します。 たとえば、DexClassLoaderコンポーネントを使用して動的にロードされたAndroidのクラスコード、またはJNIインターフェースを介した「machine」メソッドの呼び出し。



おわりに



AndroidモバイルOSのセキュリティ問題は、プラットフォームのすべてのレベルに存在し、現在観察できる保護対策よりも包括的なアプローチが必要です。この記事で紹介した脆弱性分類を開発する際、主な問題の1つは重要な市場の断片化であり、iOSに実装されているように、すべてのデバイスにセキュリティ更新プログラムをタイムリーに配信できないことが指摘されました。



同時に、アンチウイルスやサンドボックスを含む既存の保護ツールには多くの欠点があり、ユーザーを完全に保護することはできません。この記事に記載されている要件のリストに沿ってガイドされている場合は、説明されている欠点なしでAndroid OSのフルシステム分析用のサンドボックスを作成できます。



このような悲観的な状況にもかかわらず、最近、Androidのセキュリティを改善するための多くの積極的な動きがありました。特に、Googleはセキュリティ更新プログラムをリリースするためのプログラムを開始しました。それらは毎月リリースされ、一部のベンダーは引き続きそれらをファームウェアバージョンに追加します（Googleがサポートするデバイスはこれらの更新プログラムを最初に受け取ります）。さらに、ユーザーは、これらのセキュリティ更新プログラムをサポートするAndroid OS CyanogenMod（現在のLineageOS）のバージョンをデバイスに個別にインストールできます。また、ユーザーは、公式のGoogle Playストアからのみ人気のあるアプリケーションのセットに制限されている場合、リスクを軽減できます。 RCE（リモートコード実行）などの脆弱性は一般的にならないため、マルウェアは多くの場合、フィッシングサイト経由で電話に配信されます。非公式アプリストアまたはソーシャルエンジニアリングを通じて。 Android OSの平均的なユーザーは、特定の安全上の注意事項に従って、自分のスマートフォンについて冷静になります。



: (@ melon )



:



  1. statista.com/statistics/281106/number-of-android-app-downloads-from-google-play
  2. Tan DJJ et al. Securing Android: A Survey, Taxonomy, and Challenges // ACM Computing Surveys (CSUR). 2015. Vol. 47. № 4. P. 58.
  3. file.gdatasoftware.com/web/en/documents/whitepaper/G_DATA_Mobile_Malware_Report_H1_2016_EN.pdf
  4. developer.android.com/ndk/guides/stable_apis.html
  5. Dalvik VM Internals // sites.google.com/site/io/dalvik-vm-internals
  6. securityweek.com/overwhelming-majority-android-devices-dont-have-latest-security-patches
  7. Google I/O 2014 — The ART runtime // youtube.com/watch?v=EBlTzQsUoOw
  8. media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Huber-Rasthofer-Smartphone-Antivirus-And-Security-Applications-Under-Fire.pdf
  9. developer.android.com/guide/components/services.html
  10. source.android.com/devices/tech/security/selinux
  11. developer.android.com/preview/features/runtime-permissions.html
  12. Enck W., Ongtang M., McDaniel P. Understanding android security // IEEE security & privacy. 2009. № 1. P. 50—57.
  13. Shabtai A., Mimran D., Elovici Y. Evaluation of Security Solutions for Android Systems // arXiv preprint arXiv:1502.04870. -2015年。
  14. Hei X., Du X., Lin S. Two vulnerabilities in Android OS kernel // Communications (ICC), 2013 IEEE International Conference on. IEEE, 2013. P. 6123—6127.
  15. forum.xda-developers.com/showthread.php?t=2048511
  16. Zhou X. et al. Identity, location, disease and more: Inferring your secrets from android public resources // Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. ACM, 2013. P. 1017—1028.
  17. Wu L. et al. The impact of vendor customizations on android security // Proceedings of the 2013 ACM SIGSAC conference on Computer & communications security. ACM, 2013. P. 623—634.
  18. en.wikipedia.org/wiki/Stagefright_(bug)
  19. Zhou X. et al. The peril of fragmentation: Security hazards in android device driver customizations // Security and Privacy (SP), 2014 IEEE Symposium on. IEEE, 2014. P. 409—423.
  20. Sun M., Tan G. NativeGuard: Protecting android applications from third-party native libraries // Proceedings of the 2014 ACM conference on Security and privacy in wireless & mobile networks. ACM, 2014. P. 165—176.
  21. Octeau D. et al. Effective inter-component communication mapping in android with epicc: An essential step towards holistic security analysis // USENIX Security 2013.
  22. Chin E. et al. Analyzing inter-application communication in Android // Proceedings of the 9th international conference on Mobile systems, applications, and services. ACM, 2011.
  23. Felt AP et al. Permission Re-Delegation: Attacks and Defenses // USENIX Security Symposium. 2011.
  24. Bugiel S. et al. Xmandroid: A new android evolution to mitigate privilege escalation attacks // Technische Universität Darmstadt, Technical Report TR-2011-04.
  25. Bugiel S. et al. Towards Taming Privilege-Escalation Attacks on Android // NDSS. 2012.
  26. cvedetails.com/cve/CVE-2011-1717
  27. Fahl S. et al. Why Eve and Mallory love Android: An analysis of Android SSL (in) security // Proceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012. P. 50—61.
  28. owasp.org/index.php/Projects/OWASP_Mobile_Security_Project_-_Top_Ten_Mobile_Risks
  29. Lu L. et al. Chex: statically vetting android apps for component hijacking vulnerabilities //Proceedings of the 2012 ACM conference on Computer and communications security. ACM, 2012. P. 229—240.
  30. kb.cert.org/vuls/id/924951
  31. CVE-2015-3842 // cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3842
  32. Zhou Y. et al. Hey, You, Get Off of My Market: Detecting Malicious Apps in Official and Alternative Android Markets // NDSS. 2012.
  33. Nolan G. Decompiling android. – Apress, 2012.
  34. Petsas T. et al. Rage against the virtual machine: hindering dynamic analysis of android malware // Proceedings of the Seventh European Workshop on System Security. ACM, 2014. P. 5.
  35. Android Security Underpinnings // youtube.com/watch?v=NS46492qyJ8
  36. coresecurity.com/advisories/android-wifi-direct-denial-service
  37. securityaffairs.co/wordpress/37667/hacking/nfc-attack-credit-card.html
  38. zerodayinitiative.com/advisories/ZDI-15-092/
  39. securityfocus.com/archive/1/535980/30/150/threaded
  40. Neuner S. et al. Enter sandbox: Android sandbox comparison // arXiv preprint arXiv:1410.7749. 2014年。
  41. Hoffmann J. From Mobile to Security: Towards Secure Smartphones: . – 2014.
  42. Faruki P. et al. Android Security: A Survey of Issues, Malware Penetration and Defenses.
  43. ibotpeaches.github.io/Apktool
  44. github.com/JesusFreke/smali
  45. dedexer.sourceforge.net
  46. radare.org/r
  47. github.com/androguard/androguard
  48. dexprotector.com
  49. guardsquare.com/dexguard
  50. PANDORA applies non-deterministic obfuscation randomly to Android, Schulz P. Code protection in android // Insititute of Computer Science, Rheinische Friedrich-Wilhelms-Universität Bonn, Germany. 2012.
  51. Schütte J., Fedler R., Titze D. Condroid: Targeted dynamic analysis of android applications // in review. 2014年。
  52. Sen K. DART: Directed Automated Random Testing // Haifa Verification Conference. 2009. Vol. 6405. P. 4.
  53. Sen K., Marinov D., Agha G. CUTE: a concolic unit testing engine for C. ACM, 2005. Vol. 30. № 5. P. 263—272.
  54. Godefroid P. Random testing for security: blackbox vs. whitebox fuzzing // Proceedings of the 2nd international workshop on Random testing: co-located with the 22nd IEEE/ACM International Conference on Automated Software Engineering (ASE 2007). ACM, 2007. P. 1.
  55. Jayaraman K. et al. jFuzz: A Concolic Whitebox Fuzzer for Java // NASA Formal Methods. 2009. P. 121—125.
  56. Enck W. et al. TaintDroid: an information-flow tracking system for realtime privacy monitoring in smartphones // ACM Transactions on Computer Systems (TOCS). 2014. Vol. 32. № 2. P. 5.
  57. Yan LK, Yin H. DroidScope: Seamlessly Reconstructing the OS and Dalvik Semantic Views for Dynamic Android Malware Analysis // USENIX Security Symposium. 2012. P. 569—584.
  58. Tam K. et al. CopperDroid: Automatic Reconstruction of Android Malware Behaviors // Proc. of the Symposium on Network and Distributed System Security (NDSS). 2015年。
  59. copperdroid.isg.rhul.ac.uk/copperdroid
  60. Sarwar G. et al. On the Effectiveness of Dynamic Taint Analysis for Protecting against Private Information Leaks on Android-based Devices // SECRYPT. 2013. P. 461—468.
  61. Jing Y. et al. Morpheus: automatically generating heuristics to detect Android emulators // Proceedings of the 30th Annual Computer Security Applications Conference. ACM, 2014. P. 216—225.
  62. googleprojectzero.blogspot.ru/2016/12/bitunmap-attacking-android-ashmem.html
  63. bbqand0days.com/Pork-Explosion-Unleashed
  64. powerofcommunity.net/poc2016/x82.pdf
  65. apk-analyzer.net
  66. www.phdays.ru/program/fast-track/45984


More articles:


All Articles