Ostorlab Mobile Shielding Scanのご紹介
Ostorlab Mobile Shielding Scanは、root検知、改ざん防止、証明書ピンニング、難読化など、AndroidとiOSの保護機能を実際のバイパス手法に対してテストします。
モバイルシールディングは簡単にバイパスできる。意志の固い攻撃者はいずれにせよ突破するのだから、テストしても何も変わらない。
この見方は、シールディングが本来約束していないことを求めています。
シールディングは、アプリケーションのリバースエンジニアリングを不可能にするためのものではありません。改ざん、計装、トラフィックの傍受、コード解析を大幅に困難にするためのものです。
本当の問題は、特にAIを活用したリバースエンジニアリングと計装の時代において、シールディングがどれだけの抵抗を生み出すかです。
root検知が存在していても、最新の隠蔽手法の前では機能しないことがあります。証明書ピンニングが一つのネットワーク経路を保護していても、別の経路は露出したままかもしれません。整合性チェックが改変を検知しても、アプリケーションの実行が継続されてしまうことがあります。
保護機能が存在することを知るのは有用です。しかし、チームに確信を与えるのは、誰かがそれを攻撃したときに何が起きるかを知ることです。また、多額の費用を支払っているシールディングソリューションにその価値があるかどうかを知ることでもあります。
これこそが、Ostorlabの新しいMobile Shielding Scanが示すために作られたものです。
スキャンは見つけたものを攻撃する
Mobile Shielding Scanは、AndroidおよびiOSアプリケーションが、リバースエンジニアリングや改ざんに対してどのように自らを防御しているかを評価します。
まずアプリケーションを解析し、root/ジェイルブレイク検知、改ざん防止と整合性の制御、アンチデバッグ、アンチ計装、証明書ピンニング、コードや文字列の難読化を特定します。
次に、実機上でアプリケーションを実行し、そのワークフローをたどって、これらの保護機能が作動するポイントに到達します。一部の制御は、認証後、決済中、あるいは機密性の高い機能を開いたときにしか実行されません。保護機能が実際の利用中に一度も作動しないのであれば、その基盤となるコードを見つけるだけでは不十分です。
制御に到達すると、スキャンはそれを無効化しようと試みます。
スキャンは、アプリケーションの再パッケージと再署名、Fridaなどのツールによる実行時の計装のアタッチ、root化された端末の痕跡の隠蔽、ネットワークトラフィックの傍受、アプリケーションやライブラリのコードへのパッチ適用、整合性チェックの操作を行うことができます。
調査を主導するのはAIエージェントです。AIエージェントはインターフェースを監視し、ログを読み、アプリケーションがどのように応答するかを解釈します。クラッシュ、警告ダイアログ、ブロックされたリクエスト、無言での終了、あるいは気づかないうちに機能しなくなるワークフローは、いずれも防御が反応したかどうかを示す手がかりになりえます。
エージェントはそのエビデンスを用いて次の手法を選び、再び試行します。このプロセスは、手動のリバースエンジニアリング評価と同じ基本的なループ、すなわち観察、攻撃、解釈、適応に従います。
スキャンは、アップロードされたビルドに対しても、ストアの掲載ページから直接でも実行できます。
3つの保護機能に端末上で直接パッチを適用
以下の例は、識別情報を削除したうえで、実際のスキャンに基づいています。
ある銀行アプリケーションは、ネイティブライブラリlibsecurity.soとDEXコードにわたって、3つのクライアント側の保護機能を実装していました。
JNI_OnLoadのチェックが、/proc/self/mapsをスキャンしてFridaの痕跡を探し、suバイナリやテストキーを検索していました。疑わしいものを見つけると_exit(1)を呼び出していました。- ネイティブの整合性チェックが、ライブラリ自身のバイトに対してCRC32チェックサムを計算し、マーカー文字列の横に保存された値と比較していました。
- Javaメソッド
HookDetector.isHooked()が、プロセスマップ、スレッド名、Fridaのデフォルトポートである27042と27043を検索していました。
書面上では、このアプリケーションはアンチ計装、root検知、整合性保護を備えていました。弱点は、すべての制御が完全に端末上に保存されたファイルと判定に依存していたことです。
アプリケーションはextractNativeLibs=falseを使用しており、そのためネイティブライブラリはインストールされたAPK内に非圧縮のまま残り、そこから直接読み込まれていました。DEXコードは端末のVDEXファイルから実行されていました。root化された端末では、どちらもその場で改変できました。
スキャンはJNI_OnLoad内の終了分岐にパッチを適用し、_exit(1)を呼び出す代わりに正常なリターン経路をたどるようにしました。ライブラリを改変するとチェックサムが変わるため、スキャンはCRC32の値を再計算し、新しい結果を保存先のフィールドに書き込みました。整合性チェックは引き続き実行されましたが、パッチを適用したライブラリを有効なものと見なすようになりました。
次に、VDEXファイル内のHookDetector.isHooked()を改変し、常にfalseを返すようにしました。変更後、スキャンはコードが正しく読み込まれるために必要なDEXのAdler-32チェックサムとSHA-1チェックサムを修復しました。
これらの変更はいずれも、アプリケーションの再ビルド、再パッケージ、再署名を必要としませんでした。
アプリケーションの署名チェックは攻撃を防げませんでした。Androidはインストール時に元の署名証明書をキャッシュしており、ディスク上で改変されたファイルを再検証しなかったためです。
3つのパッチをすべて適用し、Fridaの痕跡が/proc/self/mapsにまだ見える状態で、アプリケーションは1分以上にわたって認証済みセッションを維持し、複数の画面を移動し、バックグラウンドで繰り返し実行される整合性チェックを、何の反応もなく通過しました。
3つの保護機能は、元のビルドに存在し、有効になっていました。しかし、いずれもサーバー側での独立した確認を伴わないクライアント側のコードに依存していたため、3つとも、保護対象であるはずの端末上で改変できてしまいました。
チェックリストであれば、アンチ計装、root検知、整合性保護は「存在する」と報告されたでしょう。能動的なテストは、それぞれがどのようにしてパッチで無効化できるかを正確に示しました。
エビデンスに裏付けられた判定
各保護機能は、反応して持ちこたえた場合はSecure、存在しない、無効である、またはバイパスされた場合はHardeningと判定されます。アプリケーションが通常どおり動作し続けるのであれば、検知だけでは不十分です。
失敗した防御には、再現可能なバイパス手順が含まれます。成功した防御は、攻撃を受けた状態で確認されます。検出結果は報告前に検証され、新しい指示を与えて異議を唱えたり再実行したりすることができます。
リリースのたびに結果は変わりうる
ビルドの変更やSDKのアップグレードは、アプリケーションを壊したりデリバリーパイプラインを止めたりすることなく、シールディングを弱める可能性があります。
スキャンを繰り返すことで、いま出荷されているアプリケーションとビルドにおいて、何が持ちこたえているかがわかります。
シールディングが何に耐えられるかを把握する
Mobile Shielding Scanは、どの防御が持ちこたえ、どの防御が失敗したか、そしてその結果がどのように実証されたかを示します。
シールディングは、アプリケーションへの攻撃を不可能にする必要はありません。必要なのは抵抗を生み出し、それを実証することです。