Hello there, ('ω')ノ
✅ 実際にあったライブラリ由来の脆弱性
📌 ケース1：画像処理ライブラリに含まれていた脆弱なコード（CVEあり）
ある人気の画像加工ライブラリが、内部で古いバージョンの「Apache Commons Imaging」を利用しており、特定の画像ファイルを処理すると任意コードが実行可能という脆弱性が存在。
- アプリは画像の読み込みしかしていないつもりでも…
- ユーザーがアップロードした画像ファイルに仕込まれた攻撃コードがライブラリを通じて実行される
👉 「コードを書いてない部分」でも攻撃対象になりうるという重要な教訓です。
📌 ケース2：広告SDKからの情報漏洩
ある広告配信用の外部SDKが、ユーザーの位置情報・インストールアプリ・デバイス情報などを勝手に収集して送信していたことが問題に。
※利用規約では明示されていたが、アプリ開発者は気づいていなかった
- アプリ本体では個人情報を扱っていないのに、SDKが外部送信していた
- 結果として「情報漏洩アプリ」のレッテルを貼られ、ユーザー離脱やストア削除の事態に
✅ 診断の観点：どこに注意すべきか？
| チェックポイント | 内容 |
|---|---|
| 使用しているライブラリの一覧 | build.gradle / libs/ フォルダの確認 |
| SDKが使う通信先の確認 | Burp Suiteでアプリ起動時のバックグラウンド通信を監視 |
| 古いバージョンか？CVE対象か？ | ライブラリ名で脆弱性データベースを検索（NVD、GitHub Advisories など） |
| SDKの内部動作（Java / Native） | MobSF や jadx を使ってバイナリを解析 |
🛠 演習：Burp SuiteでSDKの不審な通信を検出する
- Burpでアプリ起動直後の通信をキャプチャ
*.sdk-network.comや*.tracking-service.netなど、ユーザー操作と無関係な通信先を特定- 通信内容に次のような情報が含まれていたら要注意：
{ "device_id": "abc123", "location": "35.658034,139.701636", "installed_apps": ["com.social.app", "com.bank.app"], ... }
👉 端末の中身が丸見えで送信されている！
✅ どう対策すべきか？
| 対応策 | 解説 |
|---|---|
| 使用ライブラリの棚卸し | ./gradlew app:dependencies で依存ツリーを出力し、使っている全ライブラリを洗い出す |
| OSS脆弱性DBの活用 | https://nvd.nist.gov や https://osv.dev でCVE検索 |
| アップデートの継続 | dependabot や renovate を使ったCIでの自動更新提案 |
| 必要最小限の導入 | 使っていない機能を含む大型SDKは避ける。代替手段を検討 |
| サードパーティSDKの通信確認 | Burp / Mitmproxy などで必ず通信内容をチェックしてから導入判断 |
✅ 開発者に伝えるときのポイント
- 「SDKのせいだから自分たちに関係ない」と思われないようにする
- アプリ開発者は、“アプリが最終的にユーザーに渡すもの”の全責任を持つという認識が必要
- 依存ライブラリによる脆弱性も、自分たちのコードと同じレベルで管理対象
✅ まとめ
- オープンソースライブラリやSDKの利用は便利だが、セキュリティ管理が甘いと逆にリスクに
- 診断では「アプリが使っている他人のコード」も調査対象に含めること
- 通信解析やバイナリ解析で、想定外の動作・通信・データ収集がないかチェックする
Best regards, (^^ゞ
