モバイル セキュリティに関しては、この分野の研究が近年盛んになってきたばかりなので、あまり馴染みがないかもしれません。では、モバイルセキュリティとは何でしょうか?まず第一に、モバイル セキュリティは、プラットフォーム システム自体の問題やアプリケーション レベルの問題など、iOS プラットフォームと Android プラットフォームの一部のセキュリティ問題にすぎないことを私たちは知っています。もちろん、クライアントとサーバーが対話する際には、主に http プロトコルと https プロトコル、そしてもちろん WebSocket などの他のプロトコルなど、いくつかの通信プロトコルを関与させる必要があります。これらのプロトコル自体の欠陥にはあまり注意を払いませんが、注意する必要があるのは、送信中に必要に応じてデータ パケットが暗号化されるかどうか、サーバーがユーザーの操作権限を制御するかどうか、およびサーバー上の一部のサービスです。 . 論理処理に不備がないかなど この点の考え方は基本的にWebの普及と同じですが、いくつかの違いがあります。
モバイル セキュリティといえば、もちろんウイルスやトロイの木馬攻撃が不可欠です。一般的なリモート コントロール トロイの木馬には、droidjack、SpyNote などが含まれます。 、ロック ソフトウェアなど、雨後のキノコのように湧き出てきます。
図 1Droidjack
図 2 ロック ソフトウェア
攻撃者は Droidjack タイプを使用可能ソフトウェアはトロイの木馬を生成馬プログラム: この種の悪意のあるトロイの木馬プログラムは、通常、一部の三流 APK マーケットに存在します。一般的に、攻撃者はこれらの apk に、誰々の美しいビデオの無料視聴、誰々のビデオ用の広告なしクライアント、誰々のクールな画像ブラウザなど、魅力的な情報を埋め込みます。攻撃者は、魅力的な情報を含むこれらの APK をインターネット上に公開すると、リモート サーバー上でサーバー プログラムを起動します。ユーザーがこの悪意のあるプログラムをインストールして実行すると、ハッカーはリモート サーバー上のユーザーの携帯電話を制御できるようになります。さまざまな行為を行い、ユーザーの個人情報を盗みます。
結局のところ、これらのトロイの木馬ウイルスレベルの攻撃は、主にユーザーのセキュリティ意識の甘さに起因するものであるため、議論の中心ではなく、主にAndroidアプリケーションレベルのセキュリティについて議論します。
では、アプリの脆弱性をマイニングするにはどうすればよいでしょうか?まず、Web セキュリティからモバイル脆弱性マイニングに切り替えたセキュリティ担当者にとって、当然のことながら、自分の分野と同様の脆弱性を掘りたいと考えています。アプリのサーバー側は、基本的にアプリのサーバー側と同じです。 Web セキュリティの分野では、Web プログラムである点が異なります。そのクライアントはブラウザに近いものですが、モバイル アプリケーションには通常、モバイル デバイスにインストールできるアプリ プログラムがあります。したがって、アプリサーバーの脆弱性のマイニングでは、過去の Web 経験を利用して、xss、ssrf、SQL インジェクション、任意のファイル読み取りなどの一部の脆弱性をマイニングできます。
Web アプリケーションの脆弱性を調査する場合、ブラウザでプロキシを設定してパケットをキャプチャし、Web アプリケーションを分析できます。では、モバイル アプリケーションでパケット分析を実行するにはどうすればよいでしょうか?
実際、Android アプリケーションのデータ パケット分析もプロキシに基づいていますが、プロキシの構成は比較的複雑です。 burptsuit または fiddler で対応するエージェントを設定した後、それらを使用してデータ パケットを傍受し、再生できます。具体的な手順についてはここでは詳しく説明しませんが、オンラインでチュートリアルが公開されているので、自分で確認してみてください。
ここでは、xss や SQL インジェクションなどの古典的な脆弱性については詳しく説明しません。特に言うことはありません。ここでは主にモバイル アプリケーションの不正な脆弱性について説明します。 Web セキュリティでは、不正アクセスの脆弱性は通常、サーバーがユーザーのリクエストに対する権限の検証を実行せず、ユーザー ID のみに基づいてユーザーのリクエストを実行することが原因であることがわかっています。では、正しい認証プロセスとは何でしょうか?テキストでの簡単な説明は次のとおりです: ユーザーが正常にログインして認証された後、サーバーはユーザーの権限を Cookie に書き込み、それをブラウザーに返します。ブラウザーはこの Cookie を保持し、ユーザーはこの Cookie を取り込みます。後続のリクエスト パケットに応じて、サーバーはデータ パケット内の Cookie を検証してユーザーのアクセス許可を識別し、対応するアクセス許可で操作を実行します。
簡単に言うと、Cookie はクライアント側に保存され、セッションはサーバー側に保存されます。セキュリティの観点から見ると、Cookie はクライアント側に保存され、攻撃者はクライアント側で Cookie を取得できるため、セッションは比較的安全ですが、ユーザーの ID を識別するために使用されるフィールドが暗号化されていない場合、セッションは比較的安全です。簡単に列挙できる場合、攻撃者は Cookie を偽造し、不正な操作を実行する可能性があります。また、セッション認証が有効になっている場合、クライアントはログインに成功した後にのみ対応するセッション ID を取得します。この ID は暗号化された文字列であるため、通過することはできません。
それでは、その認定プロセスはどのようなものなのでしょうか?まず第一に、セッション認証も Cookie に依存していることを知っておく必要があります。ユーザーが正常にログインすると、サーバーはユーザーの対応するセッションをサーバーのデータベースに書き込みます。セッションには、ユーザーの ID 情報が含まれており、次にサーバーこのセッションに対応する ID がクライアントに送信されるため、クライアントの Cookie の内容は通常、sessionid=xxxxxx の文字列のみになります。ユーザーは後続のリクエストでこのセッション ID を指定する必要があります。サーバーはセッション ID を識別し、データベースにクエリを実行して対応するユーザー権限情報を取得し、ユーザーが応答操作を実行する権限を持っているかどうかを判断します。
明らかに、セッション メカニズムは比較的安全ですが、セキュリティの反対側でも代償を支払う必要があり、Cookie と比較して、セッション メカニズムはより多くのサーバー パフォーマンスを消費します。
図 4 セッション認証プロセス
ただし、モバイル側では、ユーザー ID 認証は Cookie を使用せず、トークンの識別に基づいています。では、どのような認証方式なのでしょうか？簡単に説明すると、その認証プロセスは一般的に次のようになります。クライアントのログイン検証が成功すると、サーバーはトークン文字列を返します。この文字列はユーザーのセッション資格情報です。ユーザーはサーバーと対話します。ユーザーの身元を特定できるように、このトークンを持参する必要があります。
図 5 トークン認証プロセス
データ パケットを分析し、トークンのないリクエストがあることが判明した場合、このデータ パケットは非常に存在します。もちろん、ビジネス ロジックに影響を与えるかどうかを判断するには、特定のシナリオに基づいて分析する必要があります。これがモバイル端末上の不正な脆弱性を掘り出すための一般的な姿勢です。しかし、この姿勢は精神薄弱すぎるため、敷居はなく、基本的に誰でも掘ることができます。
不正アクセスの脆弱性を探る別の方法がありますが、これはかなり奇妙に思えますが、この不正アクセスの脆弱性の根本原因は、認証戦略自体のエラーです。昔、ライブ ブロードキャスト ソフトウェアのプロトコル分析を行ったところ、その認証ロジックが次のとおりであることがわかりました。ユーザーのログイン検証が成功すると、サーバーはユーザー ID を返し、ローカルでユーザー トークンを生成することを思い出しました。後続のリクエストでは、このトークンをユーザー ID の証明として使用します。ユーザー ID は横断可能であり、トークン生成アルゴリズムはローカルであるため、これは明らかにバグがあり、攻撃者は他のユーザーの ID を取得してローカル トークン生成アルゴリズムを抽出する限り、自分でトークンを計算できます。その後、偽のユーザーがログインしました。
もちろん、このような不正な脆弱性を発見することは依然として比較的困難であるため、脆弱性ディガーには比較的深い逆分析能力とコーディング能力が必要です。しかし、開発者としては、この困難を理由にアプリケーションのセキュリティ強化を緩めることはできず、特にユーザー認証という非常に重要な機能モジュールについては、十分なセキュリティ対策を講じる必要があります。
クライアントの脆弱性に関しては、主な方法は、逆コンパイル ツールを使用してアプリ クライアントを逆コンパイルして取得することです。ソース コードを作成し、ある程度の経験とセキュリティの知識に基づいて静的ソース コードの監査を実施します。一般的な逆コンパイル ツールには、apkide、jeb、apktools などが含まれます。理解していただくためにスクリーンショットを撮りましょう:
もちろん、私のお気に入りは Android のリバース アシスタントで、非常に実用的です。
Android アプリケーション プラットフォームは、主にネイティブ層と Java 層に分かれています。 Java 層の場合は上記のツールを使用して分析できますが、ネイティブ層の場合は ida を使用して分析する必要があります。 Ida は非常に使いやすい逆アセンブル ツールで、ida を通じて apk の so ファイルを逆アセンブルし、その f5 関数を使用して arm アセンブリ コードを C 疑似コードに変換し、論理アルゴリズムを解析できます。また、動的デバッグもサポートしており、apk アプリケーションをリモートでデバッグできます。ida 動的デバッグを使用して、二次パッケージング検証などの so レイヤーの一部の検証をバイパスしたり、動的デバッグとシェルを実行したりできます。
アプリケーション シェルリングについて言えば、これは APK 分析プロセス中に非常に必要です。開梱について話す前に、まず梱包とは何かを理解しましょう。パッキングとは、アプリケーションを実行する前にまずプログラムの制御を取得し、次にプログラムの制御を元のプログラムに移すことを意味します。 Android プラットフォームでのパッキング実装では、元の dex ファイルを暗号化して非表示にし、シェル プログラムを通じて元の dex ファイルを取得して復元します。もう 1 つの方法は、関数命令を抽出し、実行時にフックを使用して応答することです。クラスロード関数は命令を埋め戻します。
パックされたアプリケーションの場合、元のプログラムのロジックは基本的に認識できず、パックされたプログラムを通じてセキュリティ解析を行うことはできません。したがって、アプリケーションを解凍する必要があります。一般的な自動解凍ツールには、drizzledump や dexhunter などがあります。 Dexhunter は使いやすいですが、フラッシュする必要があり、多くの暗号化ベンダーがチェックしているため、直接使用すると機能せず、いくつかの変更を加えて検出を回避する必要があります。詳しい使い方についてはネット上にチュートリアルがあるのでここでは割愛します。ツールが機能しない場合は、最終的には ida にアクセスする必要があります。
ソース コード レベルでのセキュリティ検出に関して注意を払う必要がある問題を詳しく見てみましょう。
コンポーネントのセキュリティ
1 つ目は、コンポーネントのセキュリティの問題です。Android アプリケーションには、アクティビティ、サービス、コンテンツ プロバイダー、ブロードキャストという 4 つの主要なコンポーネントがあることがわかっています。受信機。これらのコンポーネントがあまり必要でない場合は、そのエクスポート属性、exported を false、つまりエクスポートを禁止するように設定する必要があります。 true に設定すると、外部アプリケーションによって呼び出されるため、情報漏洩、権限バイパス、その他の脆弱性が発生する可能性があります。さらに、Intent.getXXXExtra() を使用してデータを取得または処理する場合、例外処理に try...catch が使用されていない場合、サービス拒否の脆弱性が発生する可能性があります。これらの例外には、ヌル ポインター例外、型変換例外、配列範囲外アクセス例外、未定義クラス例外、シリアル化および逆シリアル化例外。
上記のコンポーネントのセキュリティと同様に、通常は Android の androidManifest.xml ファイルを分析することで判断します。 AndroidManifest.xml は Android アプリケーションのエントリ ファイルで、パッケージ内で公開されるコンポーネント (アクティビティ、サービスなど)、それぞれの実装クラス、処理できるさまざまなデータ、起動場所が記述されます。プログラム内でアクティビティ、コンテンツプロバイダー、サービス、およびインテントレシーバーを宣言することに加えて、アクセス許可とインストルメンテーション (セキュリティ制御とテスト) も指定できます。このmanifest.xmlファイルを分析することで、アプリケーションデータのバックアップやアプリケーションの調整などの脆弱性を発見することもできます。もちろん、これらの脆弱性は一般に比較的リスクが低い脆弱性であり、プログラムのビジネス ロジックに大きな影響を与えることはありません。さらに、アプリケーションのデバッグ可能性の脆弱性により、攻撃者によるアプリケーションのデバッグを禁止するようにデバッグ可能が設定されていても、開発者はアプリケーション自体のデバッグを制御することしかできず、ユーザーのシステムを制御できないため、攻撃者によるアプリケーションのデバッグは防止されません。 。攻撃者は、アプリケーションがデバッグ対象に設定されているかどうかに関係なく、メモリ内のプロパティを設定することにより、システム内のすべてのアプリケーションをデバッグできます。ただし、すべてのリバース アナリストがこの設定をバイパスできることを知っているわけではないため、ここでデバッグを無効にするためにこの設定を行う必要があります。
webview のセキュリティ問題
Android クライアント アプリケーションのより深刻な脆弱性について話したい場合、それは Webview の脆弱性でなければなりません。現在、以下に示すように、多くの電子商取引プラットフォーム、淘宝網、JD.com、Juhuasuan など、多くのアプリには Web ページが組み込まれています。 webview 表示
実際、これらは Android のコンポーネントである webview によって実装されます。 WebView は、Web ページを表示する Webkit エンジンに基づくコントロールです。その機能は、Web ページの表示とレンダリングです。レイアウトには HTML ファイルを直接使用し、JavaScript を対話的に呼び出します。 Webview は、単独で使用することも、他のサブクラスと組み合わせて使用することもできます。 Webview の最も一般的に使用されるサブクラスは、WebSettings クラス、WebViewClient クラス、および WebChromeClient クラスです。ここではあまり紹介しませんが、Android プログラミングに興味がある場合は、Baidu で詳細を見つけることができます。 
Webview コンポーネントは両刃の剣として説明できます。一方で、その外観により、クライアント開発の負担が軽減され、プログラムのメイン ロジックを実装のためにサーバー上に置くことができます。ローカルでは、次のことだけが必要です。 Webview を使用して、対応する Web ページをロードしますが、設定が不適切な場合、リモート コマンド実行の脆弱性が存在する可能性があります。関連する CVE には、CVE-2012-6636、CVE-2014-1939、および CVE-2014-7224 が含まれます。
cve-2012-6636 この脆弱性は、プログラムが WebView.addJavascriptInterface メソッドの使用を正しく制限していないことが原因で発生します。リモートの攻撃者がこの脆弱性を悪用し、Java Reflection API を使用して任意の Java オブジェクト メソッドを実行する可能性があります。
cve-2014-1939 この脆弱性は、java/android/webkit/BrowserFrame.java が addJavascriptInterface API を使用し、SearchBoxImpl クラスのオブジェクトを作成することが原因で発生します。攻撃者はこの脆弱性を悪用して、次の方法で任意の Java コードを実行する可能性があります。 searchBoxJavaBridge_ インターフェイスにアクセスします。
cve-2014-7224 攻撃者は主に、accessibility と accessibilityTraversal の 2 つの Java Bridge を使用して、リモート攻撃コードを実行します。
Webview リモート コマンド実行の生成も、Java のリフレクション メカニズムに依存します。 Webview の addJavascriptInterface メソッドは Java オブジェクトを WebView に挿入でき、この Java オブジェクトのメソッドには Javascript からアクセスできます。 addJavascriptInterface が用意されているのは、WebView 内の Javascript がローカル App と通信できるようにするためです。これは確かに非常に強力な機能で、ローカル アプリのロジックが変更されていない場合、アプリをアップグレードすることなくプログラムを更新でき、対応する Web ページを変更できるという利点があります。ただし、Android の初期バージョンでは、アクセスできるメソッドに制限がなく、Java のリフレクション機構を使用することで、任意のオブジェクトの任意のメソッドを呼び出すことができ、これが WebView 脆弱性の根本的な原因です。
apk 更新パッケージ攻撃 (中間者攻撃)
上記の脆弱性は、Android アプリケーションでは比較的一般的な脆弱性であり、影響は比較的大きいです。いくつかの脆弱性もあります。相対的な影響は比較的軽いですが、適切に使用された場合、その害は依然として比較的深刻です。たとえば、中間者攻撃では、攻撃者と被害者が同じ LAN 上に存在する必要があり、被害者のトラフィックは攻撃者によって制御されます。中間者攻撃では何ができるのでしょうか? xssをプレイしますか？ユーザーのクッキーを取得しますか?もちろん、ここでユーザー Cookie を取得しても明らかに役に立ちません。トークン情報である必要があります。モバイル攻撃では、中間者攻撃を適切に悪用すると、リモートでコマンドが実行される可能性もあります。例えば、アプリケーションの更新時にダウンロードされる更新パッケージが制御され、悪意のある攻撃データパケットに置き換えられ、アプリケーションは更新パッケージに対して必要な署名検証を行わずに、攻撃者が改変した返送パッケージ内の更新プログラムを実行するというものです。悪意のあるプログラムが実行される原因となります。
現在、クライアント側の脆弱性検出に適したスキャン エンジンはありません。以前、某デジタル企業、某Bang、某暗号化APKセキュリティスキャンツールを調査したことがありますが、結果は平均的で基本的に似たような結果で、いずれも逆コンパイルされたソースコードに基づく単純な脆弱性検証に基づいていました。では、自動検出ツールを自分で作成することもできるのでしょうか?以前、apk 自動欠落スキャン ツールも作成しました。
私の実装アイデアについてお話します。まず、主な分析オブジェクトは AndroidManifest.xml と dex ファイルであることがわかっていますが、これら 2 つはコンパイルされたバイナリ ファイルです。これらを逆にする必要があります。コンパイルします。 AndroidManifest.xml を逆コンパイルするために必要なツールは AXMLPrinter.jar で、dex ファイルを逆コンパイルするために必要なファイルは baksmali.jar です。実際、これら 2 つの jar パッケージは、一部のリバース エンジニアリング ツールでも一般的に使用されています。 Android リバース アシスタント逆コンパイル ツールのプログラム ディレクトリを見てみましょう:
図 10 Android リバース アシスタント プログラム ディレクトリ
これは、Android リバース アシスタントと呼ばれます。リバース エンジニアリング ツールは、主にこれら 2 つのツールを使用して AndroidManifest ファイルと dex ファイルを逆コンパイルします。
自動リーク スキャン ツールに対応するロジックを記述し、これら 2 つのツールを呼び出して AndroidManifest ファイルと dex ファイルを逆コンパイルする限り、いくつかの脆弱性の特徴を照合することで脆弱性を検出できます。
以下はプロジェクト ディレクトリ構造の簡単な説明です:
図 11 APK 脆弱性スキャン プロジェクト ディレクトリと概要
最初にアプリケーションのパッケージ名が必要で、次にバックアップが許可されているかどうか、調整可能かどうかなど、アプリケーションのいくつかの設定を検出し、次に 4 つのコンポーネントの構成情報を取得します。 、コンテンツ プロバイダー、ブロードキャスト レシーバー、エクスポートできるかどうかを判断し、アプリケーションによって適用される権限を取得して機密性が高すぎるかどうかを判断し、アプリケーション自体によって作成された権限を取得して権限制限があるかどうかを判断します。
次に、逆コンパイルされた smali ファイルに対して脆弱性機能の検出を実行します。これは主に、事前に収集した脆弱性の特性に依存します。ここでは、脆弱性の特性を XML ファイルに書き込み、脆弱性スキャンの開始時に、プログラムが呼び出すためにそのファイルをメモリにロードします。これらの脆弱性の特性をカスタマイズして、プログラムがより多くの脆弱性をスキャンできるようにすることができます。現在、脆弱性特性の定義では文字列と通常の形式がサポートされています。このプロジェクトはまだメンテナンス中ですが、基本的な機能は実装されており、日々のスキャンと検出に対応できるため、スキャン結果のトラブルシューティングを行うだけです。
1. スキャンが必要な apk ファイルを workspace/apk ディレクトリに配置します2. AndroidCodeCheck.exe またはPython AndroidCodeCheck.py を実行して脆弱性スキャンを実行します1. 任意のファイルの読み取りおよび書き込みの脆弱性
2. 主要なハードコーディングの脆弱性
3. 強制型変換のローカルサービス拒否の脆弱性
4. システムコンポーネントのローカルサービス拒否の脆弱性
5. インテントスキーマ URL の脆弱性
6. コンテンツプロバイダーコンポーネントローカル SQL インジェクションの脆弱性
7. コードの動的読み込みセキュリティ検出
8. 証明書の弱い検証
9. ホスト名の弱い検証
10. HTTPS に敏感データハイジャックの脆弱性
11、ハッシュアルゴリズムは安全ではありません
12、AESの弱い暗号化
13、Locatによる個人情報の漏洩
14、ログ漏洩のリスク
15. PendingIntent の悪用のリスク
16. Intent の暗黙的な呼び出し
17. データベース ファイルの任意の読み取りおよび書き込み
18. WebView システムの非表示インターフェイスの脆弱性の検出
19. WebView コンポーネントのリモート コード実行の脆弱性の検出
#20. WebView は SSL 証明書エラー検出を無視##21. WebView のプレーン テキスト ストレージのパスワード
22. SharedPreferences は自由に読み取れる 書き込み
23. 任意のファイルの読み書き
24. 乱数を使うのは安全ではない
25. コンポーネントの権限チェック
26. アプリケーションが調整可能かどうかを確認する
27. アプリケーションの権限を確認する
##28. アプリケーションのカスタム権限を確認する##30. アプリケーションのバックアップの脆弱性を確認する
3. 使用方法
4. レポート出力1) txt 形式##レポート出力パスはレポートの下にあります
プログラムの実行ログとして捉えることができ、スキャン結果の参考としても利用できます。
2) HTML 形式
html 形式のレポートにはディレクトリがあり、ディレクトリ内の脆弱性名をクリックすると、該当する脆弱性の種類の説明にジャンプします。タイプの説明で [ディレクトリに戻る] をクリックすると、脆弱性ディレクトリ リストに戻り、脆弱性の確認が容易になります。
最後に、脆弱性スキャン レポートのスクリーンショットを示しますが、これは少し粗いので、後で徐々に改善する予定です。
## APK静的ソースコードリークスキャンスキャンツールプロジェクトアドレス：
https://github.com/zsdlove/ApkVulCheck
以上がAPK のセキュリティを分析し、監査を自動化する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
