M7: 不十分なバイナリ保護 (Insufficient Binary Protections)
脅威エージェント
アプリケーション依存
アプリバイナリを狙う攻撃者の動機はさまざまです。
バイナリには商用 API 鍵やハードコードされた暗号シークレットなど、攻撃者が悪用できる貴重なシークレットが含まれる可能性があります。さらに、バイナリ内のコードには重要なビジネスロジックや事前訓練された AI モデルが含まれているなど、それ自体に価値がある可能性があります。また、攻撃者の中にはアプリ自体を狙うのではなく、アプリを使用して対応するバックエンドの潜在的な弱点を探り、攻撃に備えているかもしれません。
攻撃者は情報収集だけでなく、アプリバイナリを操作して有料機能に無料でアクセスしたり、他のセキュリティチェックを回避する可能性もあります。最悪の場合、人気のあるアプリが悪意のあるコードを含むように改変されて、サードパーティのアプリストア経由で配布されたり、新しい名前で配布されて、疑いを持たないユーザーを搾取します。よくある攻撃例としては、アプリ内の決済識別子を再構成し、再パッケージ化し、アプリストア経由で配布するものがあります。それから、ユーザーがこの不正コピーをアプリストアからダウンロードすると、元のプロバイダではなく攻撃者が支払いを受け取ります。
攻撃手法
悪用難易度 容易
通常、アプリバイナリはアプリストアからダウンロードしたり、モバイルデバイスからコピーできるため、バイナリ攻撃を仕組むのは簡単です。
アプリバイナリは以下の二種類の攻撃を受ける可能性があります。
リバースエンジニアリング: アプリバイナリを逆コンパイルし、秘密鍵、アルゴリズム、脆弱性などの貴重な情報をスキャンします。
コード改竄: アプリバイナリを操作して、ライセンスチェックを削除したり、ペイウォールを回避したり、ユーザーとして他の利益を得るなどします。あるいは、アプリを操作して、悪意のあるコードを含めることもできます。
セキュリティ上の弱点
普及度 普通
検出難易度 容易
すべてのアプリはバイナリ攻撃に対して脆弱であり、多くはいつかは何らかの形で攻撃の対象になるでしょう。機密データやアルゴリズムがバイナリにハードコードされているアプリは、バイナリ攻撃に対して特に脆弱です。このようなアプリには、保護を突破することに成功した場合のコストのほうがその成功による利益よりも高くつくように、攻撃者が諦めるのに十分長い時間、潜在的な攻撃者を防御するための対策を採用する必要があります。多くの場合、たとえばコピープロテストの場合など、アプリ販売による目標収益に達するまでクラッキングプロセスを長引かせるだけで十分です。
一般的に、iOS アプリのような完全にコンパイルされたアプリは Android アプリにみられる高レベルのバイトコードよりもリバースエンジニアリングやコード改竄の影響を受けにくくなります (これは PWA や Flutter などのクロスプラットフォームテクノロジで開発されたアプリには当てはまらないかもしれないことに注意してください) 。
特に人気のあるアプリは操作され、アプリストアを通じて再配布されやすくなります。このような操作されたコピーの検出と削除は専門会社によって提供されていますが、アプリ自体内での特定の検出および報告メカニズムでも可能です。
バイナリ攻撃を防ぐ完全に信頼できるメカニズムは存在しないことに注意してください。それらに対する防御は、対策に投資する開発者と、このような対策を破る攻撃者との激しい競争になります。そのため、それぞれのアプリで答えるべき質問が次のようになります。バイナリ攻撃対策にどの程度の労力を注ぐべきですか？
技術的影響
影響度 中
前述したように、バイナリ攻撃はリバースエンジニアリングでアプリバイナリから情報を漏洩するか、コード改竄でアプリの動作を改変するかのいずれかで発生する可能性があります。
シークレットが漏洩した場合は、システム全体で迅速に置き換える必要がありますが、アプリにシークレットがハードコードされている場合は困難です。バイナリからの情報漏洩によってバックエンドのセキュリティ脆弱性が明らかになる可能性もあります。
しかし、操作はシステムの技術的な健全性にさらに影響をあたえます。攻撃者はバイナリを操作することで、たとえば、悪意のあるリクエストに対して十分に堅牢化されていない場合、自分たちの利益を得たりバックエンドを妨害するなど、アプリの動作を任意に変更できます。
ビジネスへの影響
影響度 中
商用 API などの API キーの漏洩は、大規模に悪用されると多大なコストが発生する可能性があります。改竄されてライセンスチェックを削除されたり競合アプリで機能を公開されたアプリも同様です。いずれの場合も、個人使用のために個人がアプリをクラックしたり API キーを盗んでもおそらく気付かれないでしょう。しかし規模が大きくなると、たとえば API キーや機能が他のアプリで組織的に使用される場合、悪意のある競合のほうがコストが大幅に低いために大きな優位性を得る可能性があります。
多大な労力を払って開発されたアルゴリズムや AI モデルなどの知的財産が公になったり悪意のある競合に盗まれると、アプリ開発者のビジネスモデルはさらに脅かされるかもしれません。
特に人気のあるアプリが悪意のあるコードとともに再配布されると、大きな風評被害が生じる可能性があります。アプリプロバイダが改竄されたアプリのコピーの再配布を防ぐことはほとんどできませんが、ネガティブな評判はおそらくオリジナルのプロバイダに向けられるでしょう。したがって、不正コピーの再配布は攻撃者にとって可能な限り困難にして、このリスクの可能性を減らすべきです。
「不十分なバイナリ保護」の脆弱性があるか？
すべてのアプリはバイナリ攻撃に対して脆弱です。アプリがそのバイナリに機密データやアルゴリズムをハードコードしている場合やアプリが非常に人気がある場合、バイナリ攻撃は特に害を及ぼす可能性があります。難読化や、ネイティブコードでのシークレットのエンコード (Android の場合) など、追加の保護手段があれば、攻撃の成功はより困難になりますが、決して不可能ではありません。
アプリが十分に安全かどうかはさまざまなバイナリ攻撃が与える可能性があるビジネスへの影響によって異なります。攻撃者の動機付けが大きくなり、影響が大きくなるほど、保護に一層の労力を注ぐべきです。したがって、バイナリ攻撃への「脆弱性」は特定のアプリに非常に固有なものとなります。
簡単なチェックとして、開発者は攻撃者が使用するのと同じツールを使用して自分のアプリバイナリを検査できます。MobSF, otool, apktool, Ghidra などの無料または手頃な価格のツールは多数あり、非常に使いやすく、ドキュメントも充実しています。
「不十分なバイナリ保護」を防ぐには？
アプリごとに、バイナリに重要なコンテンツが含まれているかどうかや、その人気によりバイナリ保護を義務付けられているかどうかを評価すべきです。もしそうであれば、脅威モデリング分析は最も高いリスクと、そのリスクが発生した場合に予想される経済的影響を特定するのに役立ちます。最も関連性の高いリスクについては、対策を講じるべきです。
アプリは常に信頼できない環境で動作し、情報は常に漏洩や操作されるリスクにさらされるため、動作に必要となる最小限の情報のみを取得すべきです。しかし、特定のシークレット、アルゴリズム、セキュリティチェックなどがアプリのバイナリ内になければならないとすると、さまざまな攻撃をさまざまな手段で回避できます。
リバースエンジニアリング: リバースエンジニアリングを防ぐには、アプリバイナリを理解できないようにすべきです。これは多くの無料および商用の難読化ツールでサポートされています。多くの逆コンパイルツールは一つの言語とバイナリ形式しかサポートしていないため、アプリの一部をネイティブ (iOS および Android) でコンパイルしたり、インタプリタやネストされた仮想マシンを使用すると、リバースエンジニアリングはさらに難しくなります。コード内の特定の文字列やシンボルに依存する多くのライブラリは完全な難読化では動作しないため、この種の難読化はコードの複雑さとリバースエンジニアリングに対する堅牢性の間のトレードオフになります。開発者は前のセクションのツールを使用して難読化の品質をチェックできます。
セキュリティメカニズムの破壊: 攻撃者はセキュリティチェックなどをスキップするために制御フローを理解しなければならないため、難読化は操作に対抗する助けにもなります。さらに、ローカルセキュリティチェックもバックエンドで実施されるべきです。たとえば、保護された機能に必要なリソースはローカルとバックエンドでチェックが成功した場合にのみダウンロードされるべきです。最後に、完全性チェックはコード改竄を検出して、一部のリソースを削除するなどによって、アプリのインストールを使用不能にできます。しかし、このような完全性チェックも他のローカルセキュリティチェックと同様に発見され無効にされる可能性があります。
再配布 (悪意のあるコードを含む): 起動時などの完全性チェックによってアプリバイナリの再配布や改変を検出することもできます。このような違反は自動的に報告され、アプリの不正コピーが広まる前に発見され、アプリストアから削除されます。このユースケースをサポートする専門会社もあります。
攻撃シナリオの例
シナリオ #1 ハードコードされた API キー: あるアプリは商用 API を使用し、呼び出しごとに少額の料金を支払わなければならないと想定します。このような呼び出しはユーザーがそのアプリに支払うサブスクリプション料金で簡単に支払われます。しかし、アクセスと請求に使用される API キーはアプリの保護されていないバイナリコードにハードコードされています。アクセスを望む攻撃者は無料ツールでアプリをリバースエンジニアして、シークレット文字列にアクセスできます。API アクセスは API キーでのみ保護され、他のユーザー認証はないため、攻撃者は API を自由に操作したり、API キーを販売することすらできます。最悪の場合、API キーが大量に悪用され、アプリのプロバイダに多大な経済的損害を与えたり、API アクセスがレート制限されている場合には少なくともアプリの正規ユーザーをブロックする可能性があります。
シナリオ #2 支払いとライセンスチェックの無効化: モバイルゲームではそのアプリと最初のレベルを無料で公開するかもしれません。ユーザーがそのゲームを気に入れば、フルアクセスのために料金を支払います。以降のレベルのリソースはすべてアプリに同梱されています。これらはライセンスチェックでのみ保護され、ユーザーが支払う際にライセンスをダウンロードします。攻撃者はアプリをリバースエンジニアし、支払いの検証がどのように行われるかを理解しようとする可能性があります。アプリバイナリが十分に保護されていない場合、ライセンスチェックを見つけて静的な成功ステートメントに置き換えることは簡単です。攻撃者はアプリを再コンパイルして無料でプレイしたり、別の名前でアプリストアで販売することすらできます。
シナリオ #3 ハードコードされた API モデル: AI を搭載する医療アプリがあり、音声やフリーテキストで入力した要望に答えると想定します。このアプリにはソースコードに特殊で品質保証された AI モデルを含み、オフラインアクセスを可能にして、独自のダウンロードサーバーのホスティングを避けています。この AI モデルはこのアプリの最も貴重な資産であり、開発に多くの人員を何年も費やしました。攻撃者はソースコードからこのモデルを抽出し、競合他社に販売しようとするかもしれません。アプリバイナリが十分に保護されていない場合、攻撃者は AI モデルにアクセスするだけでなく、どのように使用されているかを学習し、この情報を AI トレーニングパラメータとともに販売する可能性があります。
参考資料
OWASP
その他
Last updated