title: “MobSF による静的解析” part: “Part 5” chapter: “5-2”
MobSF による静的解析
MobSF(Mobile Security Framework)は、Android / iOS アプリケーションの静的・動的解析を支援するフレームワークであり、初期評価や自動化されたチェックに適している。本章では、主に静的解析を中心に扱う。
本章のゴール
- 前提:評価対象の APK / IPA を用意し、
exercises/mobsf/で MobSF を起動できる検証環境が用意されている。 - 到達目標:MobSF のレポートから重点確認項目(マニフェスト、パーミッション、ハードコード、ストレージ利用)を抽出し、後続の手動解析・動的解析の優先度付けに利用できる。
- 対応演習:
exercises/mobsf/で MobSF を起動し、評価対象アプリを投入して、重要度の高い指摘(例:debuggable、クリアテキスト通信許可、ハードコード情報)を中心に確認結果を記録する(起動手順は 付録「演習環境クイックスタート」 を参照。記録は 学習ログテンプレート(Burp Academy / 演習) を参照)。
MobSF の位置づけ
MobSF の主な機能は次のとおりである。
- APK / IPA ファイルの解析(パーミッション、マニフェスト、メタデータ)
- 既知の危険な設定や API 使用の検出
- 平文での鍵・トークン・URL などのハードコード検出
- 逆コンパイル結果(Smali / Java / Swift 等)の閲覧
Pentest の観点では、「モバイルアプリの初期リスク評価」として MobSF の静的解析を行い、後続の手動解析や動的解析の優先度付けに利用するのが現実的である。
基本的な利用フロー
MobSF の典型的な利用フローは次のとおりである。
- MobSF サーバを起動し、Web UI にアクセスする。
- 対象の APK/IPA ファイルをアップロードする。
- 自動解析が完了した後、レポート画面で各タブ(マニフェスト、コード、セキュリティ解析結果など)を確認する。
図5-2 は、MobSF を「初期リスク評価(自動検出)→重点項目の選別→後続の深掘り」に接続するイメージである。レポートの指摘一覧は候補であり、成立条件と影響は後続の手動解析・動的解析で確定する。
図5-2: MobSF 静的解析の利用フロー(概要)
flowchart TB
Input[APK / IPA] --> MobSF[MobSF]
MobSF --> Auto[自動解析(静的)]
Auto --> Report[レポート(指摘一覧)]
Report --> Triage[重点項目を選別\n(初期リスク評価)]
Triage --> Manual[手動解析/動的解析で\n成立条件・影響を確定]
レポートには、多数の項目が列挙されるため、すべてを均等に見るのではなく、実務上重要度の高い項目から確認する。
重点的に確認すべき項目
Android を例に、特に注目すべきポイントは次のとおりである。
- マニフェスト設定
android:exported属性の不適切な設定(外部からのインテント呼び出し)debuggable="true"の有無- クリアテキスト通信許可(
usesCleartextTraffic="true"等)
- パーミッション
- 過剰なパーミッション要求(位置情報、連絡先、ストレージ等)
- 実際に利用していないパーミッションの存在
- ハードコード情報
- API キー、秘密鍵、内部 URL、認証情報などが平文で埋め込まれていないか
- デバッグ用エンドポイントやテスト用サーバの URL
- セキュアストレージの利用有無
- 機密情報を平文ファイルやプレーンな SharedPreferences に保存していないか
これらの結果は、後続の動的解析でどの機能・領域に注目すべきかを決める材料となる。
MobSF の限界
MobSF は有用だが、次の限界も理解しておく必要がある。
- 難読化されたコードやカスタム暗号化ロジックの解析には限界がある
- 「危険な API の使用」=「必ずしも脆弱性」とは限らない(コンテキスト依存)
- iOS アプリについては、解析結果の網羅性が Android に比べて制約される場合がある
そのため、MobSF のレポートは「リスク候補の抽出」として利用し、実際の影響や exploitability については手動解析や動的解析で確認する必要がある。
次に読む章
本章のポイント
- MobSF はモバイルアプリの初期リスク評価として有用であり、マニフェスト設定、パーミッション、ハードコード情報、セキュアストレージ利用状況を重点的に確認する。
- レポートは後続の手動解析・動的解析の優先度付けに利用し、「検出=脆弱性」と短絡せずにコンテキストで評価する。
- 難読化やカスタム実装、iOS の制約などの限界があるため、最終的な影響範囲は追加検証で確定する。