AndroidアプリケーションをテストするためのOWASP Mobile TOP 10手法の適用

BetaNewsによると、インストール数が500,000を超える上位30のアプリケーションのうち、94％に少なくとも3つの中リスクの脆弱性が含まれ、77％に少なくとも2つの高リスクの脆弱性が含まれています。 30のアプリケーションのうち、17％がMITM攻撃に対して脆弱であり、すべてのデータを攻撃者による傍受にさらしています。

さらに、アプリケーションの44％にはパスワードやAPIキーなどの強力な暗号化要件を持つ機密データが含まれており、66％にはユーザーのプライバシーを侵害する可能性のある機能が使用されています。

そのため、モバイルデバイスは多くのセキュリティの議論の対象となっています。 これらすべてを考慮して、 Hackenでは、モバイルアプリケーションの脆弱性を分析するプロセスを示すために、OWASP Mobile TOP10方法論を検討することにしました。

OWASP Mobile TOP 10は、アプリケーションの脆弱性をテストするための主要な方法論の1つです。 表1は、アプリケーションのセキュリティレベルを特徴付けるために使用される10の脆弱性を説明しています。 [2,7,11]

表1：脆弱性とその説明

いや	脆弱性	説明
M1	アーキテクチャ上の制約のバイパス（不適切なプラットフォームの使用）	この脆弱性は、プラットフォーム機能の不正使用、制限の回避、またはプラットフォームセキュリティ管理制御システムの不使用を対象としています。 Androidプラットフォーム、iOS（Touch IDとキーチェーンの制限を回避する）、および他のモバイルOSの両方に典型的です。 モバイルオペレーティングシステムの一部であるセキュリティ制御に影響します。
M2	安全でないデータストレージ	この脆弱性は、M2 + M4 Mobile Top Ten 2014の組み合わせです。これには、安全でないストレージと意図しないデータ漏洩が含まれます。
M3	安全でない通信	通信ソースの信頼性の不十分な確認、誤ったSSLバージョン、不十分な調整検証、クリアデータ（クリアテキスト）での機密データの送信など。
M4	安全でない認証	この脆弱性は、エンドユーザー認証またはセッションの誤管理を指します。 次のアイテムが含まれます。 ユーザー識別のための検証要件の欠如。 セッション制御検証の欠如; セッション管理の欠点。
M5	弱い暗号化（不十分な暗号化）	暗号化アルゴリズムを使用して機密情報を送信します。 暗号化アルゴリズムの使用は、特別な場合には不十分な場合があります。 このカテゴリでは、暗号要素の不適切な使用、暗号強度の弱さまたは不十分さのオプションについて説明します。 TLSまたはSSLに関連するものはすべてM3カテゴリに属します。 必要に応じてアプリケーションが暗号化ツールを使用しない場合、これはカテゴリーM2に分類されます。
M6	安全でない認証	この脆弱性は、認可の短所（クライアント側での検証（検証）、強制表示など）について説明しています。 このようなイベントは、認証の問題（登録デバイス、ユーザー認証など）とは異なります。 必要に応じてアプリケーションがユーザーを認証しない場合（たとえば、認証がない場合に一部のリソースまたはサービスへの匿名アクセスを提供し、不正アクセスを禁止する場合）、これは認証エラーであり、認証エラーではありません。
M7	クライアントアプリケーションのコンテンツの監視（クライアントコード品質）	このカテゴリでは、入力制御が考慮されます。 サーバー側アプリケーションでのコードおよび実装の記述とは異なる、クライアント側アプリケーションでのコード技術の実装の問題。 これには、バッファオーバーフロー、フォーマット文字列の脆弱性、およびコードレベルでのその他のエラーが含まれます。ソリューションは、モバイルデバイスで実行されるコードを書き換えることです。
M8	データ変更（コード改ざん）	このカテゴリでは、実行可能ファイル、ローカルリソースの変更、サードパーティプロセスからの呼び出しのインターセプト、ランタイムメソッドの置換、メモリの動的な変更について説明します。 アプリケーションをインストールした後、そのコードはデバイスのメモリに常駐します。 これにより、悪意のあるアプリケーションがコード、メモリの内容を変更し、システムAPIメソッドを変更または置換し、アプリケーションのデータとリソースを変更できます。 これにより、攻撃者はサードパーティのアプリケーションを操作して、不正なアクションを実行したり、データを盗んだり、その他の金銭的利益を得たりすることができます。
M9	ソースコード分析（リバースエンジニアリング）	この脆弱性には、ソースコード、ライブラリ、アルゴリズムなどを決定するためのバイナリファイルの分析が含まれます。 IDA Pro、Hopper、otool、その他のリバースエンジニアリングツールなどのソフトウェアは、アプリケーションの内部操作のアイデアを提供します。 これは、アプリケーションの脆弱性の検索、バックエンドサーバー、暗号化キー、知的財産などの重要な情報の抽出に使用できます。
M10	隠された機能（外部機能）	多くの場合、開発者には、隠された機能、バックドア、または機能がアプリケーションコードでの一般的な使用を目的としたその他のメカニズムが含まれます。 あいまいさによるセキュリティのよく知られている定義は、このカテゴリに分類されます。 開発者は、ハイブリッドアプリケーションで誤ってパスワードをコメントとして残すことがあります。 または、テスト中に二要素認証を無効にしている可能性があります。

OWASP Mobile TOP 10に従って、アプリケーション「PasswordManager-1.3-release.apk」をテストするために、オンラインおよびファイル共有リソースを使用せず、表2に記載されているプログラムセットのみを使用しました。[6-10]

表2：使用されるプログラム

いや	役職	説明
1	Apktool	APKファイルを解凍するためのプログラム。 ソフトウェアのローカライズ、アプリケーションの構造の分析などに使用されます。
2	adb	これはAndroid SDKと共にインストールされるツールで、OS Androidを実行しているデバイスを管理できます。 クライアントサーバーの原理で動作します。 5037ポートを使用します。
3	dex2jar	これは、変更されたAPKファイルをjarファイルに変換するために使用されるツールです。
4	ドロザー	これは、モバイルデバイスとプログラムの脆弱性を検索するツールを含むフレームワークです。 アプリケーションとして機能し、Dalvik仮想マシン、他のアプリケーション、およびオペレーティングシステムと対話します。
5	VCGスキャナー	ソースコードの静的分析のためのツールであり、次のプログラミング言語を分析できます：C / C ++、Java、C＃、VB、およびPL / SQL。
6	JD-GUI	これは、dex2jarで使用されるツールです。 オープンされた逆コンパイルされたソースコードを提供します。
7	ジェニモーション	Android OSを実行するテスト仮想マシンを作成するように設計されたソフトウェア。
8	Pidcat	プログラムとオペレーティングシステムのログを表示するためのプログラム。

まず、Apktoolツールを使用してプログラム「PasswordManager-1.3-release.apk」を逆コンパイルします（図1を参照）。 Apktoolプログラムによる逆コンパイルでは、ソースコードを理解できる形式で取得することはできませんが、アーキテクチャ、プログラムが使用するライブラリなどについて話し合う他のプログラムリソースにアクセスできます。

図 1.逆コンパイル「PasswordManager-1.3-release.apk」。

図 2.「PasswordManager-1.3-release.apk」の構造。

図 2.プログラムのapkファイルの構造、つまり：

• AndroidManifest.xmlファイル-許可、コンポーネント、使用が推奨されるSDKバージョン、およびその他のアプリケーション設定について説明しています。
• apktool.ymlファイル-再コンパイルのためにApktoolが必要とするサービス情報が含まれています。
• libディレクトリ-開発者がソフトウェアアプリケーションに追加でロードするライブラリが保存されます。 この場合、拡張子が.soのライブラリが使用されます。
• 元のディレクトリ-ソフトウェアアプリケーションのサービスファイルが保存されます。
• ディレクトリres-ソフトウェアアプリケーションのファイル、グラフィック、およびその他のリソースが含まれています。
• smali-ソースコードファイルはバイトコードとして保存されます。

プログラムのソースコードを表示するには、dex2jarツールを使用します（図3を参照）。 これにより、プログラムのソースコードをVCG-scanner静的コードアナライザーで手動で分析することが可能になりました（図4を参照）。

図 3. dex2jarを使用してソースコード「PasswordManager-1.3-release.apk」を取得する

図 4. dex2jarを使用して表示されるパッケージとクラス「PasswordManager-1.3-release.apk」の構造

M1。 アーキテクチャ上の制約のバイパス（不適切なプラットフォームの使用）

図 5. AndroidManifest.xmlファイル

AndroidManifest.xmlファイルにアクセスすると、プログラムに関する次の情報が提供されます。

• Androidの最小許容バージョンは、uses-sdk minSdkVersion = "23"（Android 6.0）です。 この情報により、プログラムが動作（またはテスト）するデバイス（または仮想マシン）に必要な要件をすぐに理解し、ここからオープンソースを使用して、ターゲットオペレーティングシステムの脆弱性を見つけることができます。
• アクティビティのリスト：WelcomeActivity（一般）、ContentActivity、FormActivity。 この情報は、ユーザーとプログラムのバックエンドの間の対話を提供するソフトウェアアプリケーションのコンポーネントのアイデアを提供します。
• サービス：PasswordGeneratorService。 このサービスの存在により、暗号化機能で動作するクラスをすばやく見つけることができます。
• コンテンツプロバイダー：UsersProvider（エクスポーター）。 コンテンツプロバイダーの存在により、外部リソースおよびデータベースと対話するクラスを見つけることができます。

M2。 安全でないデータストレージ

プログラムでは、デバッグ情報の一部をシステムログに表示できます（図6および7を参照）。 この場合、READ_LOGS権限（たとえば、logcatまたはpidcat）を持つサードパーティのプログラムは、機密情報にアクセスできるため、機密性が侵害されます。

テスト中、pidcatプログラムが使用されました（図7を参照）。 この脆弱性はプログラムコードで発見されました（図8を参照）-開発者は、ソースコードのデバッグに使用されるLog.d（）関数を残しました。 [6-8]

図 6.パスワードは暗号化されています。	図 7.プログラムの操作中、保存されたパスワードがログに表示されます。

図 8.データ漏洩につながるプログラムコード内の場所。

脆弱性を閉じるための推奨事項 -ログ内のデバッグ情報を反映するソースコードの行を削除またはコメント化します。

Drozerフレームワークでプログラムを分析すると、エクスポートされたコンポーネント-ContentProvider（図9を参照）が見つかりました。これにより、プログラムのURIを表示し、プログラムが使用するローカルデータベースにアクセスできます[9]。

app.provider.queryモジュールを使用して、ソフトウェアアプリケーションのローカルデータベースにアクセスします。

図 9.エクスポートされたURI-ContentProviderおよび脆弱性の実装例。

ソースコードを分析すると、ローカルプログラムデータベースで挿入が見つかりました（図10を参照）。 見つかったデータにより、システムへの不正アクセスが可能になります。

図 10.データをオープンコードでソースコードに保存します。

見つかった脆弱性を修正するための推奨事項：

• このContentProviderのAndroidManifest.xmlのファイルは、次のフラグを設定します。android：export = false and android：protectionLevel = "signature";
• ContentProviderは、パラメーター化されたクエリ（query（）、update（）、delete（））を使用してアクセスする必要があります。

M3。 安全でない通信

プログラムで定義されているAndroid OSの最小バージョンでは、プロキシを使用できません。 オペレーティングシステムのこの機能を使用すると、証明書を置き換えることにより、プロキシのトラフィック復号化に対する保護を提供できます。

ただし、HTTPSプロトコルが暗号化をサポートしていない場合、プログラムはHTTPSプロトコルからHTTPへの自動切り替えを実装します。これにより、オープンな伝送チャネルによる情報の転送が可能になります。

M4。 安全でない認証

ソースコードには、次の項目をチェックするリモートサーバーで認証を提供する機能はありません。

• ユーザー識別の検証に関する要件の欠如;
• 制御セッションの検証の欠如;
• セッション管理の欠点。

M5。 弱い暗号化（不十分な暗号化）

アプリケーションソースコードの手動分析を使用して、FastCrypto.javaクラスを分析しました。これは、MD5アルゴリズムを使用してバイト配列をハッシュサムに変換します（図11を参照）。 MD5アルゴリズムは、テスト中にすでに信頼性が低いと見なされていました。 そのハッシュ量は、オンラインリソースとソフトウェアツールの両方を使用して選択できます。 [13]

プログラムのローカルデータベースのパスワードは、「塩なし」のハッシュ値に格納されます（図12を参照）。 Drozerを使用して、データベースへのアクセスが取得され、パスワードが見つかりました。 その後、MD5 Decrypterオンラインサービスを使用して、パスワードが選択されました（図13を参照）。

図 11.ライブラリを接続し、ハッシュアルゴリズムを定義します。

図 12.ハッシュ和がMD5アルゴリズムによって生成されるパスワード。

図 13.ハッシュ量の選択の結果。

ソースコードはVCGスキャナープログラムによってスキャンされ、プログラムがキーブロックの生成に使用される脆弱なライブラリ（図14および15を参照）に接続していることがわかりました。 執筆時点で、java.util.Randomライブラリを使用する場合、次のランダムな値を見つけることができます。java.security.SecureRandomライブラリを使用することをお勧めします。 [12]

図 14. VCGスキャナーをスキャンした後に見つかった脆弱性。

図 15.脆弱なライブラリjava.util.Random。

M6。 安全でない認証

プログラムには認証機能がありませんが、プログラムの目標に基づいて提供する必要があります。

M7。 クライアントアプリケーションのコンテンツの監視（クライアントコード品質）

VCGスキャナーを使用して、次の脆弱性が見つかりました（図16を参照）。 赤は、ファイル名の入力とtry / catchブロックの使用を制御する脆弱性を強調しています。 これにより、プログラムの操作、実行可能ファイルのロードおよび起動中にエラーが発生する可能性があります。 Intentオブジェクトの使用に関連する脆弱性は緑色で強調表示されます。 OWASPによると、チェックせずに別のコンポーネントからIntentオブジェクトを取得することは脆弱性と見なされます。

推奨事項：

• try / catch以外のコントロールユニットの使用。
• 受信パラメータとファイル名を制御します。
• 受信時にIntentオブジェクトを確認します。

図 16.スキャンの結果。

M8。 データ変更（コード改ざん）

Drozerフレームワークを使用すると、潜在的なSQLインジェクションの脆弱性が見つかりました（図17を参照）。 この脆弱性により、ローカルデータベースに保存されているデータを変更することができます。 検証のために、データベース内のデータを変更しようとしましたが（図18を参照）、情報変更要求に対する応答が受信されました-「まだ実装されていません」（図18を参照）。 これは、データ変更の要求がプログラムに実装されていないことを意味します（図19を参照）。したがって、Drozerフレームワークを使用して、テスト中にデータを変更することはできません。 [9]

図 17.データベースの脆弱性を確認します。

図 18.見つかった脆弱性の検証。

図 19.データ変更の脆弱性。

M9。 ソースコード分析（リバースエンジニアリング）

プログラムのソースコードは難読化されていないため、ソースコードを分析できます。 プログラムコードの分析には、apktoolおよびdex2jarプログラムが使用されました。 その後、アーキテクチャと機能が分析され、静的コードスキャンが実行され（図1-5、8、10-11、14-16、18を参照）、上記の潜在的な脆弱性が明らかになりました。

ソースコードを保護するには、難読化する必要があります。 暗号化だけでなく、コード偽造を検出する手段を追加することも必要です。

M10。 隠された機能（外部機能）

テスト中に非表示の機能が見つかりませんでした。

結論

モバイルアプリケーションの脆弱性をテストするためにOWASP Mobile TOP 10手法を使用する可能性を分析した結果、プログラムが受信、保存、処理する情報の機密性、整合性、可用性に違反する可能性のある潜在的な脆弱性の数を明確かつデジタル的に分析できると結論付けることができます。 しかし同時に、いくつかの欠点が指摘されました。つまり、いくつかの脆弱性を異なるカテゴリに同時に割り当てることができるため、見つかった脆弱性のリスクとそれを閉じる方法を評価するのが難しくなります。 したがって、OWASP Mobile TOP 10方法論の使用の明確なデモンストレーションが行われ、プログラムをリリースするべきではないと結論付けられました。 脆弱性の数を表3に示します。

表3：

いや	カテゴリー	脆弱性の数
M1	アーキテクチャ上の制約をバイパスする	1
M2	安全でないデータストレージ	2
M3	安全でないデータ転送	1
M4	安全でない認証	0
M5	弱い暗号強度	2
M6	安全でない認証	0
M7	クライアントアプリケーションコンテンツの監視	2
M8	データ修正	1
M9	ソースコード分析	1
M10	隠された機能	0