iOS Pentesting

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！

**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。

HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

Testing Environment

このページでは、iOS simulator、emulators、および jailbreaking に関する情報を確認できます:

iOS Testing Environment

Initial Analysis

Basic iOS Testing Operations

テスト中に いくつかの操作が推奨されます（デバイスに接続、ファイルの読み書き/アップロード/ダウンロード、ツールの使用など）。そのため、これらの操作の実行方法がわからない場合は、まず以下のページを読み始めてください:

iOS Basic Testing Operations

Tip

次のステップのために、アプリはデバイスにインストールされていること、そしてアプリの IPA ファイル を既に取得していることが必要です。
これを行う方法については Basic iOS Testing Operations ページを参照してください。

Basic Static Analysis

興味深い iOS 向け IPA ファイルのデコンパイラの例:

IPA ファイルに対して自動的な静的解析を行うには、ツール MobSF の使用を推奨します。

バイナリに存在する保護の特定:

PIE (Position Independent Executable): 有効な場合、アプリケーションは起動ごとにランダムなメモリアドレスにロードされ、初期メモリアドレスの予測を困難にします。

otool -hv <app-binary> | grep PIE   # It should include the PIE flag

Stack Canaries: スタックの整合性を検証するため、関数呼び出し前に「canary」値がスタックに配置され、関数終了時に再度検証されます。

otool -I -v <app-binary> | grep stack_chk   # It should include the symbols: stack_chk_guard and stack_chk_fail

ARC (Automatic Reference Counting): 一般的なメモリ破壊の脆弱性を防ぐ仕組み

otool -I -v <app-binary> | grep objc_release   # It should include the _objc_release symbol

Encrypted Binary: バイナリは暗号化されているべきです

otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # The cryptid should be 1

機密/不安全な関数の特定

Weak Hashing Algorithms

# On the iOS device
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"

# On linux
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"

Insecure Random Functions

# On the iOS device
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# On linux
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"

Insecure ‘Malloc’ Function

# On the iOS device
otool -Iv <app> | grep -w "_malloc"

# On linux
grep -iER "_malloc"

Insecure and Vulnerable Functions

# On the iOS device
otool -Iv <app> | grep -w "_gets"
otool -Iv <app> | grep -w "_memcpy"
otool -Iv <app> | grep -w "_strncpy"
otool -Iv <app> | grep -w "_strlen"
otool -Iv <app> | grep -w "_vsnprintf"
otool -Iv <app> | grep -w "_sscanf"
otool -Iv <app> | grep -w "_strtok"
otool -Iv <app> | grep -w "_alloca"
otool -Iv <app> | grep -w "_sprintf"
otool -Iv <app> | grep -w "_printf"
otool -Iv <app> | grep -w "_vsprintf"

# On linux
grep -R "_gets"
grep -iER "_memcpy"
grep -iER "_strncpy"
grep -iER "_strlen"
grep -iER "_vsnprintf"
grep -iER "_sscanf"
grep -iER "_strtok"
grep -iER "_alloca"
grep -iER "_sprintf"
grep -iER "_printf"
grep -iER "_vsprintf"

Common Jailbreak detection methods

File System Checks: /Applications/Cydia.app や /Library/MobileSubstrate/MobileSubstrate.dylib のような一般的な jailbreak ファイルやディレクトリの存在を確認します。
Sandbox Violations: 非 jailbreak デバイスではブロックされるはずのファイルシステムの制限領域へアクセスを試みます。
API Checks: fork() のような禁止された呼び出しを使用できるか、system() で /bin/sh の存在を確認できるかをチェックします。
Process Checks: Cydia、Substrate、ssh のような既知の jailbreak 関連プロセスの存在を監視します。
Kernel Exploits: jailbreak で一般的に使用されるカーネルエクスプロイトの存在をチェックします。
Environment Variables: DYLD_INSERT_LIBRARIES のような jailbreak の兆候を示す環境変数を調査します。
Libraries Check: アプリプロセスにロードされているライブラリを確認します。
Check schemes: 例えば canOpenURL(URL(string: "cydia://")) のようなチェック。

Common Anti-Debugging detection methods

Check for Debugger Presence: sysctl やその他の方法でデバッガがアタッチされているか確認します。
Anti-Debugging APIs: ptrace や SIGSTOP、例: ptrace(PT_DENY_ATTACH, 0, 0, 0) のようなアンチデバッグ用APIの呼び出しを探します。
Timing Checks: 特定の操作にかかる時間を計測し、デバッグを示唆する不整合を探します。
Memory Checks: 既知のデバッガによるアーティファクトや改変がないかメモリを検査します。
Environment Variables: デバッグセッションを示す可能性のある環境変数を確認します。
Mach Ports: デバッガが mach exception ports を使用しているか検出します。

Basic Dynamic Analysis

MobSF が実行する動的解析を確認してください。異なるビューを移動してインタラクトする必要がありますが、いくつかのクラスにフックしながら他の操作も行い、完了後にレポートを準備します。

Listing Installed Apps

インストールされているアプリの バンドル識別子 を確認するには、frida-ps -Uai コマンドを使用します:

$ frida-ps -Uai
PID  Name                 Identifier
----  -------------------  -----------------------------------------
6847  Calendar             com.apple.mobilecal
6815  Mail                 com.apple.mobilemail
-  App Store            com.apple.AppStore
-  Apple Store          com.apple.store.Jolly
-  Calculator           com.apple.calculator
-  Camera               com.apple.camera
-  iGoat-Swift          OWASP.iGoat-Swift

基本的な Enumeration & Hooking

アプリケーションのコンポーネントをenumerateする方法と、objection を使ってメソッドやクラスを簡単にhookする方法を学びます:

iOS Hooking With Objection

IPAファイルの構造は本質的にzipped packageの構造と同じです。拡張子を.zipに変更することで、中身をdecompressして内容を確認できます。この構造の中で、Bundleはインストール可能な完全にパッケージ化されたアプリケーションを表します。内部には <NAME>.app というディレクトリがあり、アプリケーションのリソースが格納されています。

Info.plist: アプリケーションの特定の設定情報を保持するファイルです。
_CodeSignature/: バンドル内のすべてのファイルの整合性を保証する署名を含むplistファイルが格納されています。
Assets.car: アイコンのようなアセットファイルを格納する圧縮アーカイブです。
Frameworks/: .dylib や .framework として存在する可能性のあるアプリのネイティブライブラリが格納されています。
PlugIns/: .appex ファイルとして知られるアプリの拡張を含む場合があります（常に存在するわけではありません）。 * Core Data: オフラインでアプリの永続データを保存したり、一時データをキャッシュしたり、単一デバイス上での undo 機能を追加するために使用されます。複数デバイス間で同じ iCloud アカウント内のデータを同期するには、Core Data は自動的にスキーマを CloudKit コンテナにミラーリングします。
PkgInfo: PkgInfo ファイルは、アプリケーションやバンドルの type と creator コードを指定する別の方法です。
en.lproj, fr.proj, Base.lproj: それぞれの言語用のリソースを含む言語パックで、サポートされていない言語に対するデフォルトリソースも含まれます。
Security: _CodeSignature/ ディレクトリは、デジタル署名を通じてバンドル内のすべてのファイルの整合性を検証することでアプリのセキュリティに重要な役割を果たします。
Asset Management: Assets.car ファイルは圧縮を利用してグラフィックアセットを効率的に管理し、アプリケーションのパフォーマンス最適化と全体サイズの削減に寄与します。
Frameworks and PlugIns: これらのディレクトリは iOS アプリのモジュール性を示しており、再利用可能なコードライブラリ（Frameworks/）の追加やアプリ機能の拡張（PlugIns/）を可能にします。
Localization: 構造は複数言語をサポートしており、特定言語向けのリソースを含めることでグローバルなアプリ展開を容易にします。

Info.plist

Info.plist は iOS アプリケーションの基盤となるファイルで、key-value ペアの形で重要な設定データをカプセル化します。このファイルはアプリケーションだけでなく、バンドル内に含まれるアプリ拡張やフレームワークにも必須です。XML 形式またはバイナリ形式で構成され、アプリの権限からセキュリティ構成までの重要な情報を保持します。利用可能なキーの詳細については、Apple Developer Documentation を参照してください。

このファイルをより扱いやすい形式で扱いたい場合、macOS 上の plutil（10.2 以降のバージョンでネイティブに利用可能）や Linux 上の plistutil を使用して簡単に XML に変換できます。変換コマンドは次の通りです:

For macOS:

$ plutil -convert xml1 Info.plist

Linux向け:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Info.plistファイルが明らかにする無数の情報の中で、注目すべきエントリにはアプリの権限文字列（UsageDescription）、カスタムURLスキーム（CFBundleURLTypes）、およびApp Transport Securityの設定（NSAppTransportSecurity）があります。これらのエントリは、UTExportedTypeDeclarations / UTImportedTypeDeclarations のようなエクスポート/インポートされたカスタムドキュメントタイプとともに、ファイルを調べるか単純な grep コマンドを使うことで容易に見つけることができます:

$ grep -i <keyword> Info.plist

データパス

iOS 環境では、ディレクトリは システムアプリケーション と ユーザーがインストールしたアプリケーション 用に明確に区分されています。システムアプリは /Applications ディレクトリに存在し、ユーザーがインストールしたアプリは /var/mobile/containers/Data/Application/ 以下に配置されます。これらのアプリには 128-bit UUID として知られる一意の識別子が割り当てられており、ディレクトリ名がランダムであるため手動でアプリのフォルダを見つけるのは困難です。

Warning

As applications in iOS must be sandboxed, each app will have also a folder inside $HOME/Library/Containers with app’s CFBundleIdentifier as the folder name.

However, both folders (data & container folders) have the file .com.apple.mobile_container_manager.metadata.plist that links both files in the key MCMetadataIdentifier).

ユーザーがインストールしたアプリのインストールディレクトリの特定を容易にするために、objection tool は便利なコマンド、env を提供します。このコマンドは対象アプリの詳細なディレクトリ情報を表示します。以下はこのコマンドの使用例です：

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env

Name               Path
-----------------  -------------------------------------------------------------------------------------------
BundlePath         /var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
CachesDirectory    /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library/Caches
DocumentDirectory  /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Documents
LibraryDirectory   /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library

または、findコマンドを使用して/private/var/containers内でアプリ名を検索できます:

find /private/var/containers -name "Progname*"

psやlsofなどのコマンドは、それぞれアプリのプロセス特定と開いているファイルの一覧表示に利用でき、アプリケーションのアクティブなディレクトリパスに関する洞察を提供します：

ps -ef | grep -i <app-name>
lsof -p <pid> | grep -i "/containers" | head -n 1

Bundle directory:

AppName.app
これは以前IPAで見たアプリケーションバンドルで、アプリの必須データ、静的コンテンツ、およびアプリのコンパイル済みバイナリを含みます。
このディレクトリはユーザーから見えますが、ユーザーは書き込みできません。
このディレクトリ内の内容はバックアップされません。
このフォルダの内容はコード署名の検証に使用されます。

Data directory:

Documents/
すべてのユーザー生成データを格納します。アプリのエンドユーザーがこのデータの作成を開始します。
ユーザーから見え、ユーザーは書き込みできます。
このディレクトリ内の内容はバックアップされます。
アプリはNSURLIsExcludedFromBackupKeyを設定することでパスをバックアップ対象外にできます。
Library/
ユーザー固有でないファイル（caches、preferences、cookies、および property list (plist) 設定ファイルなど）を含みます。
iOSアプリは通常Application SupportとCachesのサブディレクトリを使用しますが、アプリはカスタムのサブディレクトリを作成できます。
Library/Caches/
半永続的なキャッシュファイルを含みます。
ユーザーからは見えず、ユーザーは書き込みできません。
このディレクトリ内の内容はバックアップされません。
アプリが実行されておらず、ストレージが不足している場合、OSはこのディレクトリ内のファイルを自動的に削除することがあります。
Library/Application Support/
アプリの実行に必要な永続的なファイルを含みます。
不可視 で ユーザー、ユーザーは書き込みできません。
このディレクトリ内の内容はバック アップされます。
アプリはNSURLIsExcludedFromBackupKeyを設定することでパスをバックアップ対象外にできます。
Library/Preferences/
アプリの再起動後も保持されるプロパティを保存するために使われます。
情報は暗号化されず、アプリケーションサンドボックス内の [BUNDLE_ID].plist というplistファイルに保存されます。
NSUserDefaultsを使って保存されたすべてのキー/バリューのペアはこのファイルで確認できます。
tmp/
このディレクトリはアプリ起動間で持続する必要のない一時ファイルを書くために使用します。
非永続的なキャッシュファイルを含みます。
不可視 ユーザーからは見えません。
このディレクトリ内の内容はバックアップされません。
アプリが実行されておらず、ストレージが不足している場合、OSはこのディレクトリ内のファイルを自動的に削除することがあります。

Let’s take a closer look at iGoat-Swift’s Application Bundle (.app) directory inside the Bundle directory (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app):

OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType      Perms  NSFileProtection    ...  Name
------------  -------  ------------------  ...  --------------------------------------
Regular           420  None                ...  rutger.html
Regular           420  None                ...  mansi.html
Regular           420  None                ...  splash.html
Regular           420  None                ...  about.html

Regular           420  None                ...  LICENSE.txt
Regular           420  None                ...  Sentinel.txt
Regular           420  None                ...  README.txt

Binary Reversing

<application-name>.app フォルダの中には <application-name> というバイナリファイルがあります。これは実行されるファイルです。バイナリの基本的な解析はツール otool で行えます:

otool -Vh DVIA-v2 #Check some compilation attributes
magic  cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
MH_MAGIC_64    ARM64        ALL  0x00     EXECUTE    65       7112   NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE

otool -L DVIA-v2 #Get third party libraries
DVIA-v2:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.1)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 274.6.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
@rpath/Bolts.framework/Bolts (compatibility version 1.0.0, current version 1.0.0)
[...]

アプリが暗号化されているか確認する

以下の出力があるか確認する:

otool -l <app-binary> | grep -A 4 LC_ENCRYPTION_INFO

バイナリの逆アセンブル

text セクションを逆アセンブルする:

otool -tV DVIA-v2
DVIA-v2:
(__TEXT,__text) section
+[DDLog initialize]:
0000000100004ab8    sub    sp, sp, #0x60
0000000100004abc    stp    x29, x30, [sp, #0x50]   ; Latency: 6
0000000100004ac0    add    x29, sp, #0x50
0000000100004ac4    sub    x8, x29, #0x10
0000000100004ac8    mov    x9, #0x0
0000000100004acc    adrp    x10, 1098 ; 0x10044e000
0000000100004ad0    add    x10, x10, #0x268

サンプルアプリケーションのObjective-C segmentを出力するには、次を使用できます:

otool -oV DVIA-v2
DVIA-v2:
Contents of (__DATA,__objc_classlist) section
00000001003dd5b8 0x1004423d0 _OBJC_CLASS_$_DDLog
isa        0x1004423a8 _OBJC_METACLASS_$_DDLog
superclass 0x0 _OBJC_CLASS_$_NSObject
cache      0x0 __objc_empty_cache
vtable     0x0
data       0x1003de748
flags          0x80
instanceStart  8

よりコンパクトな Objective-C コードを取得するには class-dump を使用できます：

class-dump some-app
//
//     Generated by class-dump 3.5 (64 bit).
//
//     class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2013 by Steve Nygard.
//

#pragma mark Named Structures

struct CGPoint {
double _field1;
double _field2;
};

struct CGRect {
struct CGPoint _field1;
struct CGSize _field2;
};

struct CGSize {
double _field1;
double _field2;
};

しかし、バイナリを逆アセンブルする最良の選択肢は: Hopper と IDA です。

データの保存

iOS がデバイスにデータをどのように保存するかを学ぶには、次のページを読んでください：

iOS Basics

Warning

以下の場所に保存された情報は、アプリケーションをインストールした直後、アプリの全機能を確認した後、そして あるユーザーでログアウトして別のユーザーでログインした後 に確認する必要があります。
目的は、アプリケーション（パスワード、トークン）、現在のユーザー、および以前にログインしたユーザーの保護されていない機密情報を見つけることです。

Plist

plist files は構造化された XML ファイルで、キーと値のペアを含みます。永続的なデータを保存する方法の一つであり、これらのファイルに機密情報が含まれていることがあるため、アプリをインストールした後や集中的に使用した後に確認することを推奨します。

plist ファイルにデータを永続化する最も一般的な方法は NSUserDefaults の使用です。この plist ファイルはアプリのサンドボックス内の Library/Preferences/<appBundleID>.plist に保存されます。

The NSUserDefaults クラスはデフォルトシステムと対話するためのプログラム的インターフェースを提供します。デフォルトシステムはアプリケーションが ユーザー設定 に応じて動作をカスタマイズできるようにします。NSUserDefaults によって保存されたデータはアプリケーションバンドル内で閲覧できます。このクラスは データ を plist ファイル に保存しますが、小量のデータを扱うことを想定しています。

このデータはもはや信頼済みのコンピュータから直接アクセスできませんが、バックアップ を行うことでアクセスできます。

objection の ios nsuserdefaults get を使って、dump することができます。

アプリケーションが使用するすべての plist を見つけるには、/private/var/mobile/Containers/Data/Application/{APPID} にアクセスして次を実行します：

find ./ -name "*.plist"

ファイルを**XML or binary (bplist)**形式からXMLに変換するには、OSによっていくつかの方法があります：

macOSユーザー向け: plutilコマンドを使用します。これはmacOS (10.2+)に標準で搭載されているツールで、この目的のために設計されています：

$ plutil -convert xml1 Info.plist

Linuxユーザー向け: まず libplist-utils をインストールし、plistutil を使用してファイルを変換します:

$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Within an Objection Session: モバイルアプリケーションを解析するため、特定のコマンドでplistファイルを直接変換できます:

ios plist cat /private/var/mobile/Containers/Data/Application/<Application-UUID>/Library/Preferences/com.some.package.app.plist

Core Data

Core Data is a framework for managing the model layer of objects in your application. Core Data can use SQLite as its persistent store, but the framework itself is not a database.
CoreDataはデフォルトでデータを暗号化しません。ただし、追加の暗号化レイヤーをCoreDataに追加することができます。詳細はGitHub Repoを参照してください。

You can find the SQLite Core Data information of an application in the path /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support

If you can open the SQLite and access sensitive information, then you found a miss-configuration.

-(void)storeDetails {
AppDelegate * appDelegate = (AppDelegate *)(UIApplication.sharedApplication.delegate);

NSManagedObjectContext *context =[appDelegate managedObjectContext];

User *user = [self fetchUser];
if (user) {
return;
}
user = [NSEntityDescription insertNewObjectForEntityForName:@"User"
inManagedObjectContext:context];
user.email = CoreDataEmail;
user.password = CoreDataPassword;
NSError *error;
if (![context save:&error]) {
NSLog(@"Error in saving data: %@", [error localizedDescription]);

}else{
NSLog(@"data stored in core data");
}
}

YapDatabase

YapDatabase は SQLite の上に構築されたキー/バリューストアです。
Yap データベースは SQLite データベースであるため、前のセクションで示したコマンドを使って見つけることができます。

Other SQLite Databases

アプリケーションが独自の SQLite データベースを作成することは一般的です。これらに 機密データを保存している 場合があり、暗号化されずに放置されていることがあります。したがって、アプリケーションのディレクトリ内のすべてのデータベースを確認する価値があります。データが保存されているアプリケーションのディレクトリに移動してください（/private/var/mobile/Containers/Data/Application/{APPID}）。

find ./ -name "*.sqlite" -or -name "*.db"

Firebase Real-Time Databases

開発者は Firebase Real-Time Databases を介して、データを保存および同期できるNoSQL クラウドホスト型データベースを利用できます。JSON 形式で保存されたデータは、接続されたすべてのクライアントにリアルタイムで同期されます。

You can find how to check for misconfigured Firebase databases here:

Firebase Database

Realm databases

Realm Objective-C and Realm Swift は、Apple が提供しないデータ保存の強力な代替手段を提供します。デフォルトでは、データを暗号化せずに保存し、暗号化は特定の設定で有効にできます。

The databases are located at: /private/var/mobile/Containers/Data/Application/{APPID}. To explore these files, one can utilize commands like:

iPhone:/private/var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents root# ls
default.realm  default.realm.lock  default.realm.management/  default.realm.note|

$ find ./ -name "*.realm*"

これらのデータベースファイルを表示するには、Realm Studio ツールを推奨します。

Realm データベース内で暗号化を実装するには、以下のコードスニペットを使用できます：

// Open the encrypted Realm file where getKey() is a method to obtain a key from the Keychain or a server
let config = Realm.Configuration(encryptionKey: getKey())
do {
let realm = try Realm(configuration: config)
// Use the Realm as normal
} catch let error as NSError {
// If the encryption key is wrong, `error` will say that it's an invalid database
fatalError("Error opening realm: \(error)")
}

Couchbase Lite データベース

Couchbase Lite は、軽量かつ組み込みのデータベースエンジンで、ドキュメント指向（NoSQL）アプローチに従います。iOSおよびmacOSにネイティブに対応するよう設計されており、データをシームレスに同期する機能を提供します。

デバイス上で潜在的な Couchbase データベースを特定するには、次のディレクトリを調査してください:

ls /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/

Cookies

iOSは各アプリのフォルダ内の**Library/Cookies/cookies.binarycookiesにアプリのCookieを保存します。ただし、前述のcookie file can be accessed in backupsため、開発者がkeychain**に保存することがあります。

cookiesファイルを調査するにはthis python scriptを使用するか、objectionの**ios cookies get.**
また、objectionを使ってこれらのファイルをJSON形式に変換し、データを確認することもできます。

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
[
{
"domain": "highaltitudehacks.com",
"expiresDate": "2051-09-15 07:46:43 +0000",
"isHTTPOnly": "false",
"isSecure": "false",
"name": "username",
"path": "/",
"value": "admin123",
"version": "0"
}
]

Cache

By default NSURLSession stores data, such as HTTP requests and responses in the Cache.db database. This database can contain 機密データ, if tokens, usernames or any other sensitive information has been cached. To find the cached information open the data directory of the app (/var/mobile/Containers/Data/Application/<UUID>) and go to /Library/Caches/<Bundle Identifier>. The WebKit cache is also being stored in the Cache.db file. Objection can open and interact with the database with the command sqlite connect Cache.db, as it is a normal SQLite database.

It is 推奨される to disable Caching this data, as it may contain sensitive information in the request or response. The following list below shows different ways of achieving this:

It is recommended to remove Cached responses after logout. This can be done with the provided method by Apple called removeAllCachedResponses You can call this method as follows:

URLCache.shared.removeAllCachedResponses()

This method will remove all cached requests and responses from Cache.db file.

If you don’t need to use the advantage of cookies it would be recommended to just use the .ephemeral configuration property of URLSession, which will disable saving cookies and Caches.

Apple documentation:

An ephemeral session configuration object is similar to a default session configuration (see default), except that the corresponding session object doesn’t store caches, credential stores, or any session-related data to disk. Instead, session-related data is stored in RAM. The only time an ephemeral session writes data to disk is when you tell it to write the contents of a URL to a file.

Cache can be also disabled by setting the Cache Policy to .notAllowed. It will disable storing Cache in any fashion, either in memory or on disk.

Snapshots

Whenever you press the home button, iOS takes a snapshot of the current screen to be able to do the transition to the application on a much smoother way. However, if 機密な データ is present in the current screen, it will be 保存 in the image (which 再起動後も持続します). These are the snapshots that you can also access double tapping the home screen to switch between apps.

Unless the iPhone is jailbroken, the 攻撃者 needs to have アクセス to the device unblocked to see these screenshots. By default the last snapshot is stored in the application’s sandbox in Library/Caches/Snapshots/ or Library/SplashBoard/Snapshots folder (the trusted computers can’ t access the filesystem from iOX 7.0).

One way to prevent this bad behaviour is to put a blank screen or remove the sensitive data before taking the snapshot using the ApplicationDidEnterBackground() function.

The following is a sample remediation method that will set a default screenshot.

Swift:

private var backgroundImage: UIImageView?

func applicationDidEnterBackground(_ application: UIApplication) {
let myBanner = UIImageView(image: #imageLiteral(resourceName: "overlayImage"))
myBanner.frame = UIScreen.main.bounds
backgroundImage = myBanner
window?.addSubview(myBanner)
}

func applicationWillEnterForeground(_ application: UIApplication) {
backgroundImage?.removeFromSuperview()
}

Objective-C:

@property (UIImageView *)backgroundImage;

- (void)applicationDidEnterBackground:(UIApplication *)application {
UIImageView *myBanner = [[UIImageView alloc] initWithImage:@"overlayImage.png"];
self.backgroundImage = myBanner;
self.backgroundImage.bounds = UIScreen.mainScreen.bounds;
[self.window addSubview:myBanner];
}

- (void)applicationWillEnterForeground:(UIApplication *)application {
[self.backgroundImage removeFromSuperview];
}

アプリケーションがバックグラウンド化されるたびに overlayImage.png を背景画像として設定します。overlayImage.png が常に現在のビューを上書きするため、機密データのleaksを防ぎます。

Keychain

iOS keychain にアクセスして管理するには、Keychain-Dumper のようなツールがあり、jailbroken デバイスで使用できます。さらに、Objection は同様の用途で ios keychain dump コマンドを提供します。

資格情報の保存

NSURLCredential クラスは、NSUserDefaults やその他のラッパーを経由することなく、機密情報を直接 keychain に保存するのに最適です。ログイン後に資格情報を保存するには、次の Swift コードを使用します:

NSURLCredential *credential;
credential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistencePermanent];
[[NSURLCredentialStorage sharedCredentialStorage] setCredential:credential forProtectionSpace:self.loginProtectionSpace];

これらの保存された認証情報を抽出するために、Objection のコマンド ios nsurlcredentialstorage dump が使用されます。

カスタムキーボードとキーボードキャッシュ

iOS 8.0 以降、ユーザーはカスタムキーボード拡張をインストールでき、Settings > General > Keyboard > Keyboards から管理できます。これらのキーボードは機能を拡張しますが、キー入力のログ取得や外部サーバへのデータ送信のリスクがあり、ネットワークアクセスを必要とするキーボードについてはユーザーに通知されます。アプリは機密情報の入力時にカスタムキーボードの使用を制限することができ、そうすべきです。

セキュリティの推奨事項：

セキュリティ向上のため、サードパーティ製キーボードを無効にすることが推奨されます。
デフォルトの iOS キーボードの autocorrect および auto-suggestions 機能は、Library/Keyboard/{locale}-dynamic-text.dat または /private/var/mobile/Library/Keyboard/dynamic-text.dat にあるキャッシュファイルに機密情報を保存する可能性があることに注意してください。これらのキャッシュファイルは定期的に機密データがないか確認するべきです。キャッシュされたデータを消去するには Settings > General > Reset > Reset Keyboard Dictionary からキーボード辞書をリセットすることが推奨されます。
ネットワークトラフィックを傍受することで、カスタムキーボードがキーストロークをリモートに送信しているかどうかを確認できます。

テキストフィールドのキャッシュ防止

The UITextInputTraits protocol は autocorrection と secure text entry を管理するプロパティを提供しており、機密情報のキャッシュ防止に不可欠です。例えば、autocorrection を無効にし、secure text entry を有効にするには、次のようにします：

textObject.autocorrectionType = UITextAutocorrectionTypeNo;
textObject.secureTextEntry = YES;

さらに、開発者はテキストフィールド、特にpasswordsやPINsなどの機密情報を入力するフィールドが、autocorrectionType を UITextAutocorrectionTypeNo に、secureTextEntry を YES に設定してキャッシュを無効にしていることを確認するべきです。

UITextField *textField = [[UITextField alloc] initWithFrame:frame];
textField.autocorrectionType = UITextAutocorrectionTypeNo;

Logs

デバッグではしばしばloggingが使われます。リスクとして、logsには機密情報が含まれている可能性があります。以前は iOS 6 およびそれ以前のバージョンでは、logs はすべてのアプリからアクセス可能であり、機密データの漏洩リスクがありました。現在は、アプリは自分の logs のみアクセス可能に制限されています。

これらの制限があっても、ロック解除されたデバイスに対して物理的にアクセスできるattacker with physical accessは、デバイスをコンピュータに接続してlogs を読むなどしてこれを悪用できます。アプリをアンインストールした後も logs はディスク上に残る点に注意してください。

リスクを軽減するためには、アプリを徹底的に操作すること（すべての機能や入力を試す）を推奨します。これにより、意図せず機密情報が logs に記録されていないか確認できます。

アプリのソースコードを潜在的な漏洩についてレビューする際は、組み込み関数では NSLog、NSAssert、NSCAssert、fprintf といったキーワードや、カスタム実装では Logging や Logfile の記述をチェックし、既定の と カスタムの logging ステートメント の両方を探してください。

Monitoring System Logs

アプリは機密になり得る様々な情報を logs に記録します。これらの logs を監視するには、次のようなツールやコマンドがあります:

idevice_id --list   # To find the device ID
idevicesyslog -u <id> (| grep <app>)   # To capture the device logs

役に立ちます。さらに、Xcode はコンソールログを収集する方法を提供します：

Xcode を開きます。
iOS デバイスを接続します。
メニューの Window -> Devices and Simulators に移動します。
デバイスを選択します。
調査中の問題を再現します。
Open Console ボタンを使って、新しいウィンドウでログを表示します。

より高度なログ取得の場合、デバイスのシェルに接続して socat を使用すると、リアルタイムでログを監視できます：

iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock

ログ活動を監視するためのコマンドが続きます。これは問題の診断やログ内の潜在的な data leak の特定に非常に有用です。

バックアップ

自動バックアップ機能は iOS に統合されており、iTunes（macOS Catalina 以前）、Finder（macOS Catalina 以降）、または iCloud を通じてデバイスのデータコピーを作成できます。これらのバックアップは、Apple Pay の詳細や Touch ID の設定などの非常に機微な要素を除き、ほとんどのデバイスデータを含みます。

セキュリティリスク

バックアップにインストールされたアプリとそのデータが含まれることで、潜在的なdata leakやバックアップの変更がアプリの動作を変える可能性があるといったリスクが生じます。これらのリスクを軽減するため、どのアプリのディレクトリやサブディレクトリにも機密情報をプレーンテキストで保存しないことが推奨されます。

バックアップからファイルを除外する方法

Documents/ と Library/Application Support/ のファイルはデフォルトでバックアップされます。開発者は NSURL setResourceValue:forKey:error: を NSURLIsExcludedFromBackupKey と組み合わせて使用することで、特定のファイルやディレクトリをバックアップから除外できます。この処置は機密データがバックアップに含まれるのを防ぐために重要です。

脆弱性のテスト

アプリのバックアップセキュリティを評価するには、まず Finder を使ってバックアップを作成し、続いて Apple’s official documentation の案内に従ってバックアップの場所を特定します。バックアップを解析して、アプリの動作に影響を与えるような機密データや設定が含まれていないか確認します。

機密情報はコマンドラインツールや iMazing のようなアプリを使って探索できます。暗号化されたバックアップについては、バックアップのルートにある “Manifest.plist” ファイルの “IsEncrypted” キーを確認することで暗号化の有無を確認できます。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
...
<key>Date</key>
<date>2021-03-12T17:43:33Z</date>
<key>IsEncrypted</key>
<true/>
...
</plist>

For dealing with encrypted backups, Python scripts available in DinoSec’s GitHub repo, like backup_tool.py and backup_passwd.py, may be useful, albeit potentially requiring adjustments for compatibility with the latest iTunes/Finder versions. The iOSbackup tool is another option for accessing files within password-protected backups.

アプリの動作変更

An example of altering app behavior through backup modifications is demonstrated in the Bither bitcoin wallet app, where the UI lock PIN is stored within net.bither.plist under the pin_code key. Removing this key from the plist and restoring the backup removes the PIN requirement, providing unrestricted access.

機密データのメモリテストのまとめ

アプリケーションのメモリに保存された機密情報を扱う際は、その露出時間を最小限にすることが重要です。メモリ内容を調査する主なアプローチは 2 つあり、creating a memory dump と analyzing the memory in real time です。いずれの方法も、ダンプや解析の過程で重要なデータを見逃す可能性などの課題があります。

メモリダンプの取得と解析

For both jailbroken and non-jailbroken devices, tools like objection and Fridump allow for the dumping of an app’s process memory. Once dumped, analyzing this data requires various tools, depending on the nature of the information you’re searching for.

To extract strings from a memory dump, commands such as strings or rabin2 -zz can be used:

# Extracting strings using strings command
$ strings memory > strings.txt

# Extracting strings using rabin2
$ rabin2 -ZZ memory > strings.txt

より詳細な解析、特に特定のデータ型やパターンの検索を含めて、radare2 は豊富な検索機能を提供します:

$ r2 <name_of_your_dump_file>
[0x00000000]> /?
...

ランタイムメモリ解析

r2frida は、memory dump を必要とせずにアプリのメモリをリアルタイムで検査する強力な代替手段を提供します。このツールにより、実行中のアプリケーションのメモリ上で直接検索コマンドを実行できます:

$ r2 frida://usb//<name_of_your_app>
[0x00000000]> /\ <search_command>

脆弱な暗号化

不適切なキー管理プロセス

一部の開発者は機密データをローカルストレージに保存し、コード内に hardcoded/predictable なキーで暗号化します。これは避けるべきで、reversing によって攻撃者が機密情報を抽出できる可能性があるためです。

Use of Insecure and/or Deprecated Algorithms

開発者はデータの認可 checks、store、send を行うために deprecated algorithms を使用すべきではありません。これらのアルゴリズムには: RC4, MD4, MD5, SHA1… などがあります。例えばパスワードを保存するために hashes を使用する場合は、salt を用いた brute-force resistant な hashes を使用するべきです。

Check

主なチェック項目は、コード内に hardcoded なパスワード/シークレットがないか、あるいはそれらが predictable でないか、またコードが何らかの weak cryptography アルゴリズムを使用していないかを確認することです。

興味深いことに、次のように objection を使っていくつかの crypto libraries を自動的に monitor することができます:

ios monitor crypt

iOS の暗号 API とライブラリに関する詳細は https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography を参照してください。

Local Authentication

ローカル認証は非常に重要であり、特に暗号化手段を用いてリモートエンドポイントへのアクセスを保護する場合に重要です。ここでの要点は、適切に実装されていないとローカル認証の仕組みは回避され得るということです。

Apple の Local Authentication framework と keychain は、それぞれユーザー認証ダイアログの提供と機密データの安全な取り扱いのための強力な API を開発者に提供します。Secure Enclave は Touch ID の指紋 ID を保護し、Face ID は顔認識を用いて生体データを漏えいさせることなく認証を行います。

Touch ID/Face ID を統合するには、開発者は次の2つの API を選べます:

LocalAuthentication.framework: 生体データへアクセスせず高レベルのユーザー認証を行うため。
Security.framework: より低レベルの keychain サービスへアクセスし、生体認証で秘密データを保護するため。さまざまな open-source wrappers により keychain へのアクセスが簡素化されています。

Caution

しかし、LocalAuthentication.framework と Security.framework はどちらも脆弱性を孕んでいます。これらは主に認証処理のためのデータを送受信せずに boolean 値を返すため、バイパスされやすくなります（詳細は Don’t touch me that way, by David Lindner et al を参照）。

Implementing Local Authentication

ユーザーに認証を促すには、開発者は LAContext クラスの evaluatePolicy メソッドを利用すべきで、以下から選択します:

deviceOwnerAuthentication: Touch ID またはデバイスのパスコードを要求し、どちらも有効でない場合は失敗する。
deviceOwnerAuthenticationWithBiometrics: Touch ID のみを要求する。

認証が成功したかどうかは evaluatePolicy の boolean 戻り値で示され、これは潜在的なセキュリティ上の欠陥を示しています。

Local Authentication using Keychain

iOS アプリでローカル認証を実装する際は、認証トークンなどの機密データを安全に保存するために keychain APIs を使用します。これにより、データはユーザーがデバイスのパスコードや Touch ID のような生体認証で認証した場合にのみアクセス可能になります。

keychain は SecAccessControl 属性を設定でき、ユーザーが Touch ID やデバイスのパスコードで正常に認証するまでアイテムへのアクセスを制限できます。この機能はセキュリティ強化に重要です。

以下は Swift と Objective-C のコード例で、これらのセキュリティ機能を利用して文字列を keychain に保存・取得する方法を示しています。例では特に、Touch ID 認証を要求するようにアクセス制御を設定し、デバイスのパスコードが設定されている場合にのみ、そのデータが生成されたデバイス上でアクセス可能になるようにする方法を示しています。

// From https://github.com/mufambisi/owasp-mstg/blob/master/Document/0x06f-Testing-Local-Authentication.md

// 1. create AccessControl object that will represent authentication settings

var error: Unmanaged<CFError>?

guard let accessControl = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
SecAccessControlCreateFlags.biometryCurrentSet,
&error) else {
// failed to create AccessControl object

return
}

// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute

var query: [String: Any] = [:]

query[kSecClass as String] = kSecClassGenericPassword
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecAttrAccount as String] = "OWASP Account" as CFString
query[kSecValueData as String] = "test_strong_password".data(using: .utf8)! as CFData
query[kSecAttrAccessControl as String] = accessControl

// 3. save item

let status = SecItemAdd(query as CFDictionary, nil)

if status == noErr {
// successfully saved
} else {
// error while saving
}

// 1. create AccessControl object that will represent authentication settings
CFErrorRef *err = nil;

SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
kSecAccessControlUserPresence,
err);

// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute
NSDictionary* query = @{
(_ _bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecAttrAccount: @"OWASP Account",
(__bridge id)kSecValueData: [@"test_strong_password" dataUsingEncoding:NSUTF8StringEncoding],
(__bridge id)kSecAttrAccessControl: (__bridge_transfer id)sacRef
};

// 3. save item
OSStatus status = SecItemAdd((__bridge CFDictionaryRef)query, nil);

if (status == noErr) {
// successfully saved
} else {
// error while saving
}

これで keychain から保存されたアイテムを要求できます。Keychain services はユーザーに認証ダイアログを表示し、適切な fingerprint が提供されたかどうかに応じて data または nil を返します。

// 1. define query
var query = [String: Any]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecReturnData as String] = kCFBooleanTrue
query[kSecAttrAccount as String] = "My Name" as CFString
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecUseOperationPrompt as String] = "Please, pass authorisation to enter this area" as CFString

// 2. get item
var queryResult: AnyObject?
let status = withUnsafeMutablePointer(to: &queryResult) {
SecItemCopyMatching(query as CFDictionary, UnsafeMutablePointer($0))
}

if status == noErr {
let password = String(data: queryResult as! Data, encoding: .utf8)!
// successfully received password
} else {
// authorization not passed
}

// 1. define query
NSDictionary *query = @{(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecReturnData: @YES,
(__bridge id)kSecAttrAccount: @"My Name1",
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecUseOperationPrompt: @"Please, pass authorisation to enter this area" };

// 2. get item
CFTypeRef queryResult = NULL;
OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, &queryResult);

if (status == noErr){
NSData* resultData = ( __bridge_transfer NSData* )queryResult;
NSString* password = [[NSString alloc] initWithData:resultData encoding:NSUTF8StringEncoding];
NSLog(@"%@", password);
} else {
NSLog(@"Something went wrong");
}

検出

アプリ内でフレームワークが使用されているかは、アプリバイナリの共有動的ライブラリの一覧を解析することで検出できます。これは otool を使って行えます:

$ otool -L <AppName>.app/<AppName>

アプリで LocalAuthentication.framework が使用されている場合、出力には次の2つの行の両方が含まれます（LocalAuthentication.framework が内部で Security.framework を使用していることを覚えておいてください）：

/System/Library/Frameworks/LocalAuthentication.framework/LocalAuthentication
/System/Library/Frameworks/Security.framework/Security

Security.framework が使用されている場合、2番目のみが表示されます。

ローカル認証フレームワークのバイパス

Objection

Objection Biometrics Bypass, located at this GitHub page, を通じて、LocalAuthentication メカニズムを回避する手法が利用可能です。
この手法の核は Frida を利用して evaluatePolicy 関数を操作し、実際の認証の成否に関わらず常に True を返すようにすることです。これは、欠陥のある生体認証処理を回避するのに特に有用です。

このバイパスを有効化するには、次のコマンドを実行します:

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios ui biometrics_bypass
(agent) Registering job 3mhtws9x47q. Type: ios-biometrics-disable
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # (agent) [3mhtws9x47q] Localized Reason for auth requirement: Please authenticate yourself
(agent) [3mhtws9x47q] OS authentication response: false
(agent) [3mhtws9x47q] Marking OS response as True instead
(agent) [3mhtws9x47q] Biometrics bypass hook complete

このコマンドは、Objection がタスクを登録して evaluatePolicy チェックの結果を実質的に True に変更する一連の処理を開始します。

Frida

以下は DVIA-v2 application からの evaluatePolicy の使用例です：

+(void)authenticateWithTouchID {
LAContext *myContext = [[LAContext alloc] init];
NSError *authError = nil;
NSString *myLocalizedReasonString = @"Please authenticate yourself";

if ([myContext canEvaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics error:&authError]) {
[myContext evaluatePolicy:LAPolicyDeviceOwnerAuthenticationWithBiometrics
localizedReason:myLocalizedReasonString
reply:^(BOOL success, NSError *error) {
if (success) {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Successful" withTitle:@"Success"];
});
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Authentication Failed !" withTitle:@"Error"];
});
}
}];
} else {
dispatch_async(dispatch_get_main_queue(), ^{
[TouchIDAuthentication showAlert:@"Your device doesn't support Touch ID or you haven't configured Touch ID authentication on your device" withTitle:@"Error"];
});
}
}

Local Authenticationのbypassを達成するために、Fridaスクリプトが作成されます。このスクリプトはevaluatePolicyチェックをターゲットにし、そのコールバックを傍受してsuccess=1を返すようにします。コールバックの挙動を変更することで、認証チェックは実質的に bypass されます。

下のスクリプトはevaluatePolicyメソッドの結果を変更するために注入されます。コールバックの結果を常に成功を示すように変更します。

// from https://securitycafe.ro/2022/09/05/mobile-pentesting-101-bypassing-biometric-authentication/
if(ObjC.available) {
console.log("Injecting...");
var hook = ObjC.classes.LAContext["- evaluatePolicy:localizedReason:reply:"];
Interceptor.attach(hook.implementation, {
onEnter: function(args) {
var block = new ObjC.Block(args[4]);
const callback = block.implementation;
block.implementation = function (error, value)  {

console.log("Changing the result value to true")
const result = callback(1, null);
return result;
};
},
});
} else {
console.log("Objective-C Runtime is not available!");
}

Frida スクリプトを注入して生体認証をバイパスするには、次のコマンドを使用します:

frida -U -f com.highaltitudehacks.DVIAswiftv2 --no-pause -l fingerprint-bypass-ios.js

IPCを介した機密機能の露出

ネットワーク通信

通信が暗号化されていない状態で行われていないこと、またアプリケーションがサーバのTLS証明書を正しく検証していることを確認することが重要です。
これらの問題を確認するために、Burp のようなプロキシを使用できます:

iOS Burp Suite Configuration

Hostname check

TLS証明書を検証する際の一般的な問題は、証明書が信頼された CAによって署名されているかを確認するが、証明書のホスト名がアクセスしているホスト名と一致しているかを確認しない点です。
Burpを使ってこの問題を確認するには、iPhone上でBurp CAを信頼した後、Burpで別のホスト名用の新しい証明書を作成してそれを使います。もしアプリが依然として動作するなら、脆弱である可能性があります。

Certificate Pinning

アプリが正しく SSL Pinning を使用している場合、アプリは期待される証明書である場合にのみ動作します。テスト時には Burpが独自の証明書を返すため問題になることがあります。
jailbroken デバイス内でこの保護をバイパスするには、アプリ SSL Kill Switch をインストールするか、Burp Mobile Assistant をインストールします。

また objection の ios sslpinning disable を使うこともできます。

その他

In /System/Library you can find the frameworks installed in the phone used by system applications
The applications installed by the user from the App Store are located inside /User/Applications
And the /User/Library contains data saved by the user level applications
You can access /User/Library/Notes/notes.sqlite to read the notes saved inside the application.
Inside the folder of an installed application (/User/Applications/<APP ID>/) you can find some interesting files:
iTunesArtwork: The icon used by the app
iTunesMetadata.plist: Info of the app used in the App Store
/Library/*: Contains the preferences and cache. In /Library/Cache/Snapshots/* you can find the snapshot performed to the application before sending it to the background.

Hot Patching/Enforced Updateing

開発者はアプリを App Store に再提出して承認を待つことなく、全インストール版をリモートで即座にパッチ適用できます。
この目的には通常 JSPatch が使われます。その他にも Siren や react-native-appstore-version-checker のような選択肢があります。
これは悪意あるサードパーティSDKによって悪用されうる危険な仕組みであるため、どの方法で自動更新が行われているか（もしあれば）を確認し、テストすることが推奨されます。この目的のためにアプリの過去バージョンをダウンロードしてみることができます。

Third Parties

サードパーティSDKにおける大きな課題は、その機能に対する細かな制御が効かない点です。開発者はSDKを統合してその全機能（潜在的なセキュリティ脆弱性やプライバシーの懸念を含む）を受け入れるか、あるいはその利点を完全に放棄するかの選択を迫られます。多くの場合、開発者自身でこれらのSDK内の脆弱性を修正することはできません。さらに、SDKがコミュニティ内で信頼を得ると、悪意あるコードを含むようになることもあります。

サードパーティSDKによるサービスは、ユーザ行動のトラッキング、広告表示、ユーザ体験の向上などを含む場合があります。しかし、これにより開発者がこれらライブラリで実行されるコードを十分に把握していない可能性が生じ、プライバシーやセキュリティのリスクを招きます。サードパーティサービスに共有する情報は必要最小限にし、機微なデータが露出しないようにすることが重要です。

サードパーティサービスの実装は、スタンドアロンのライブラリかフルSDKの形で提供されることが一般的です。ユーザのプライバシーを守るために、これらサービスに共有されるデータは個人を識別できる情報（PII）が漏れないよう匿名化するべきです。

アプリが使用しているライブラリを特定するには、otool コマンドを使用します。このツールはアプリケーション本体や、アプリが使用する各共有ライブラリに対して実行し、追加のライブラリを検出します。

otool -L <application_path>

興味深い脆弱性 & ケーススタディ

Air Keyboard Remote Input Injection

Itunesstored Bookassetd Sandbox Escape

参考資料 & 追加リソース

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！

**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。

HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。