iOS Pentesting

Trickestを使用して、世界で最も先進的なコミュニティツールによって強化されたワークフローを簡単に構築および自動化します。今すぐアクセスを取得:

Automate OffSec, EASM, and Custom Security Processes | Trickest

**htARTE（HackTricks AWS Red Team Expert）**で**ゼロからヒーローまでのAWSハッキング**を学びましょう！

HackTricksをサポートする他の方法:HackTricksで企業を宣伝したい場合やHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！公式PEASS＆HackTricksスワッグを入手The PEASS Familyを発見し、独占的なNFTコレクションをご覧ください💬 Discordグループに参加するか、telegramグループに参加するか、Twitterで@carlospolopmをフォローしてください 🐦 @carlospolopm.ハッキングトリックを共有するために、HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出してください。

iOSの基礎

pageiOS Basics

テスト環境

このページでは、iOSシミュレータ、エミュレータ、およびジェイルブレイクに関する情報を見つけることができます:

pageiOS Testing Environment

初期分析

基本的なiOSテスト操作

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

pageiOS Basic Testing Operations

以下の手順では、アプリがデバイスにインストールされている必要があり、アプリのIPAファイルをすでに取得している必要があります。これを行う方法については、基本的なiOSテスト操作ページを参照してください。

基本的な静的解析

ツールMobSFを使用して、IPAファイルに対して自動的な静的解析を実行することをお勧めします。

バイナリに存在する保護の識別:

PIE（Position Independent Executable）: 有効になっている場合、アプリケーションは起動するたびにランダムなメモリアドレスにロードされ、初期メモリアドレスを予測するのが難しくなります。

otool -hv <app-binary> | grep PIE   # PIEフラグを含める必要があります

スタックキャナリー: スタックの整合性を検証するために、関数を呼び出す前にスタックに「キャナリー」値が配置され、関数が終了すると再度検証されます。

otool -I -v <app-binary> | grep stack_chk   # stack_chk_guardおよびstack_chk_failのシンボルを含める必要があります

ARC（Automatic Reference Counting）: 一般的なメモリ破損の欠陥を防ぐため

otool -I -v <app-binary> | grep objc_release   # _objc_releaseシンボルを含める必要があります

暗号化されたバイナリ: バイナリは暗号化されている必要があります

otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # cryptidは1である必要があります

機密性の高い/安全でない関数の識別

弱いハッシュアルゴリズム

# iOSデバイス上で
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"

# Linux上で
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"

安全でないランダム関数

# iOSデバイス上で
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# Linux上で
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"

安全でない「Malloc」関数

# iOSデバイス上で
otool -Iv <app> | grep -w "_malloc"

# Linux上で
grep -iER "_malloc"

安全で脆弱な関数

# iOSデバイス上で
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"

# 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"

基本的な動的解析

MobSFが実行する動的解析をチェックしてください。異なるビューをナビゲートし、それらと対話する必要がありますが、いくつかのクラスをフックし、他のことを行い、完了したらレポートを準備します。

インストールされたアプリのリスト表示

コマンド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

基本列挙とフック

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

pageiOS Hooking With Objection

IPAの構造

IPAファイルの構造は基本的に圧縮されたパッケージです。拡張子を.zipに変更することで、その内容を明らかにするために展開することができます。この構造の中で、Bundleはインストールの準備が整った完全なパッケージ化されたアプリケーションを表します。内部には、アプリケーションのリソースをカプセル化する<NAME>.appというディレクトリが含まれています。

Info.plist: このファイルにはアプリケーションの特定の構成詳細が格納されています。
_CodeSignature/: このディレクトリには、バンドル内のすべてのファイルの整合性を確保する署名を含む plist ファイルが含まれています。
Assets.car: アイコンなどのアセットファイルを格納する圧縮アーカイブです。
Frameworks/: このフォルダには、.dylibまたは.framework形式のアプリケーションのネイティブライブラリが含まれています。
PlugIns/: これには、.appexファイルとして知られるアプリケーションの拡張機能が含まれる場合がありますが、常に存在するわけではありません。
Core Data: これは、アプリケーションの永続データをオフラインで保存し、一時データをキャッシュし、単一デバイスでアプリに元に戻す機能を追加するために使用されます。単一の iCloud アカウント内の複数のデバイス間でデータを同期するために、Core Data はスキーマを自動的に CloudKit コンテナにミラーリングします。
PkgInfo: PkgInfoファイルは、アプリケーションまたはバンドルのタイプと作成者コードを指定する別の方法です。
en.lproj, fr.proj, Base.lproj: これらは、特定の言語のリソースを含む言語パックであり、言語がサポートされていない場合のデフォルトリソースを含みます。
セキュリティ: _CodeSignature/ディレクトリは、デジタル署名を介してバンドルされたすべてのファイルの整合性を検証することで、アプリのセキュリティに重要な役割を果たします。
アセット管理: Assets.carファイルは、グラフィカルアセットを効率的に管理するために圧縮を使用し、アプリケーションのパフォーマンスを最適化し、全体のサイズを削減するために重要です。
フレームワークとプラグイン: これらのディレクトリは、iOSアプリケーションのモジュラリティを強調し、再利用可能なコードライブラリ(Frameworks/)を含めたり、アプリの機能を拡張したり(PlugIns/)することを可能にします。
ローカライゼーション: この構造は、複数の言語をサポートし、特定の言語パックのリソースを含むことで、グローバルなアプリケーションの到達範囲を広げることを容易にします。

Info.plist

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

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

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）などがあります。これらのエントリは、ファイルを検査するか、単純なgrepコマンドを使用して簡単に見つけることができます。

$ grep -i <keyword> Info.plist

データパス

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

iOSのアプリケーションはサンドボックス化される必要があるため、各アプリには**$HOME/Library/Containers内にアプリのCFBundleIdentifier**をフォルダ名とするフォルダもあります。

ただし、両方のフォルダ（データフォルダとコンテナフォルダ）には、キーMCMetadataIdentifierで両方のファイルをリンクする**.com.apple.mobile_container_manager.metadata.plist**ファイルが含まれています。

ユーザーがインストールしたアプリのインストールディレクトリを発見するために、objectionツールは便利な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

バンドルディレクトリ:

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

データディレクトリ:

Documents/
すべてのユーザー生成データが含まれています。アプリケーションエンドユーザーがこのデータの作成を開始します。
ユーザーに見え、ユーザーは書き込むことができます。
このディレクトリ内のコンテンツはバックアップされます。
アプリはNSURLIsExcludedFromBackupKeyを設定してパスを無効にできます。
Library/
ユーザー固有でないファイル、キャッシュ、設定、クッキー、およびプロパティリスト（plist）構成ファイルなどが含まれています。
iOSアプリは通常、Application SupportおよびCachesサブディレクトリを使用しますが、アプリはカスタムサブディレクトリを作成できます。
Library/Caches/
半永続的なキャッシュファイルが含まれています。
ユーザーには見えず、ユーザーは書き込むことはできません。
このディレクトリ内のコンテンツはバックアップされません。
アプリが実行されていないときやストレージ容量が不足しているとき、OSはこのディレクトリのファイルを自動的に削除する場合があります。
Library/Application Support/
アプリの実行に必要な永続的なファイルが含まれています。
ユーザーには見えず、ユーザーは書き込むことはできません。
このディレクトリ内のコンテンツはバックアップされます。
アプリはNSURLIsExcludedFromBackupKeyを設定してパスを無効にできます。
Library/Preferences/
アプリケーションが再起動されても永続化されるプロパティを保存するために使用されます。
情報は、アプリケーションサンドボックス内の[BUNDLE_ID].plistというplistファイルに暗号化されていない形で保存されます。
NSUserDefaultsを使用して保存されたすべてのキー/値ペアはこのファイルに見つけることができます。
tmp/
アプリの起動間に永続化する必要のない一時ファイルを書き込むためにこのディレクトリを使用します。
非永続的なキャッシュファイルが含まれています。
ユーザーには見えません。
このディレクトリ内のコンテンツはバックアップされません。
OSは、アプリが実行されていないときやストレージ容量が不足しているとき、このディレクトリのファイルを自動的に削除する場合があります。

iGoat-Swiftのアプリケーションバンドル（.app）ディレクトリをバンドルディレクトリ内（/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

バイナリリバース

<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

バイナリの逆アセンブル

テキストセクションを逆アセンブルします：

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セグメントを印刷するには、次のようにします：

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 です。

Trickest を使用して、世界で最も高度なコミュニティツールによって強化された ワークフローを簡単に構築 および 自動化 してください。今すぐアクセス:

Automate OffSec, EASM, and Custom Security Processes | Trickest

データの保存

iOS がデバイス内にデータを保存する方法について学ぶには、このページを参照してください:

pageiOS Basics

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

Plist

plist ファイルは、キーと値のペアを含む 構造化された XML ファイルです。永続データを保存する方法であり、したがって、これらのファイルに 機密情報が含まれることがあります。アプリをインストールした後や頻繁に使用した後にこれらのファイルをチェックすることをお勧めします。

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

NSUserDefaults クラスは、デフォルトシステムとのやり取りのためのプログラムインターフェースを提供します。デフォルトシステムにより、アプリケーションは ユーザーの設定に応じて動作をカスタマイズ できます。NSUserDefaults によって保存されたデータは、アプリケーションバンドル内で表示できます。このクラスは、少量のデータ と一緒に使用することを意図しています。

このデータは、信頼されたコンピュータを介して直接アクセスできませんが、バックアップ を実行することでアクセスできます。

NSUserDefaults を使用して保存された情報を dump するには、objection の ios nsuserdefaults get を使用できます。

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

find ./ -name "*.plist"

以下は、**XMLまたはバイナリ（bplist）**形式のファイルをXML形式に変換するための、オペレーティングシステムに応じたさまざまな方法です：

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

Objectionセッション内： モバイルアプリケーションを分析する際、特定のコマンドを使用してplistファイルを直接変換できます：

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

Core Data

Core Dataは、アプリケーション内のオブジェクトのモデル層を管理するためのフレームワークです。Core Dataは永続ストアとしてSQLiteを使用することができますが、フレームワーク自体はデータベースではありません。 CoreDataはデフォルトではデータを暗号化しません。ただし、CoreDataに追加の暗号化レイヤーを追加することができます。詳細については、GitHubリポジトリを参照してください。

アプリケーションのSQLite Core Data情報は、パス/private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Supportにあります。

SQLiteを開いて機密情報にアクセスできる場合、設定ミスを見つけたことになります。

iGoatからのコード

-(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データベースなので、前のセクションで提案されたコマンドを使用して見つけることができます。

その他のSQLiteデータベース

アプリケーションが独自のsqliteデータベースを作成することは一般的です。それらには機密データが格納されており、暗号化されていない可能性があります。そのため、アプリケーションディレクトリ内のすべてのデータベースをチェックすることは常に興味深いです。したがって、データが保存されているアプリケーションディレクトリに移動します (/private/var/mobile/Containers/Data/Application/{APPID})

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

Firebase Real-Time Databases

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

ミス構成されたFirebaseデータベースをチェックする方法はこちらで見つけることができます。

Realm databases

Realm Objective-CおよびRealm Swiftは、Appleによって提供されていないデータ保存の強力な代替手段を提供します。デフォルトでは、データは暗号化されず、特定の構成を介して暗号化が可能です。

データベースは次の場所にあります：/private/var/mobile/Containers/Data/Application/{APPID}。これらのファイルを調査するために、次のようなコマンドを利用することができます：

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ファイルがバックアップでアクセスできるため、それらをキーチェーン**に保存することを選択することがあります。

クッキーファイルを調査するには、このPythonスクリプトを使用するか、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"
}
]

キャッシュ

デフォルトでは、NSURLSessionはHTTPリクエストとレスポンスをCache.dbデータベースに保存します。このデータベースには、トークン、ユーザー名、またはその他の機密情報がキャッシュされている場合があります。キャッシュされた情報を見つけるには、アプリのデータディレクトリ (/var/mobile/Containers/Data/Application/<UUID>) を開き、/Library/Caches/<Bundle Identifier> に移動します。WebKitキャッシュもCache.dbファイルに保存されています。Objectionは、sqlite connect Cache.db コマンドでこのデータベースを開いて操作することができます。これは通常のSQLiteデータベースです。

このデータのキャッシュを無効にすることが推奨されています。なぜなら、リクエストやレスポンスに機密情報が含まれている可能性があるからです。以下のリストには、これを実現するさまざまな方法が示されています:

ログアウト後にキャッシュされたレスポンスを削除することが推奨されています。Appleが提供するremoveAllCachedResponses メソッドを使用してこれを行うことができます。以下のようにこのメソッドを呼び出すことができます:

URLCache.shared.removeAllCachedResponses()

このメソッドは、Cache.dbファイルからすべてのキャッシュされたリクエストとレスポンスを削除します。 2. クッキーの利点を使用する必要がない場合は、URLSessionの .ephemeral 構成プロパティを使用することをお勧めします。これにより、クッキーとキャッシュの保存が無効になります。

Apple documentation:

ephemeralセッション構成オブジェクトは、デフォルトのセッション構成（defaultを参照）と似ていますが、対応するセッションオブジェクトは、キャッシュ、資格情報ストア、またはディスクにセッション関連データを保存しません。代わりに、セッション関連データはRAMに保存されます。ephemeralセッションがデータをディスクに書き込む唯一の場合は、URLの内容をファイルに書き込むように指示した場合です。 3. キャッシュポリシーを .notAllowed に設定することで、キャッシュをメモリやディスクに保存しないようにすることもできます。

スナップショット

ホームボタンを押すたびに、iOSは現在の画面のスナップショットを取得して、アプリケーションへの遷移をよりスムーズに行うことができます。ただし、現在の画面に機密データがある場合、それは画像に保存されます（これは再起動を超えて永続化されます）。これらは、アプリ間を切り替えるためにホーム画面をダブルタップすることでアクセスできるスナップショットです。

iPhoneがジェイルブレイクされていない限り、攻撃者はこれらのスクリーンショットを見るためにはデバイスのロックを解除する必要があります。デフォルトでは、最後のスナップショットはアプリのサンドボックス内の Library/Caches/Snapshots/ または Library/SplashBoard/Snapshots フォルダに保存されます（信頼されたコンピュータはiOS 7.0からファイルシステムにアクセスできません）。

この悪い振る舞いを防ぐ方法の1つは、ApplicationDidEnterBackground() 関数を使用して、スナップショットを取る前に空白の画面を表示するか、機密データを削除することです。

以下は、デフォルトのスクリーンショットを設定するサンプルの緩和方法です。

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()
}

<h2>Objective-C:</h2>

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];
}

Keychain

iOSキーチェーンへのアクセスと管理には、Keychain-Dumperなどのツールが利用可能で、ジェイルブレイクされたデバイスに適しています。さらに、Objectionは同様の目的のためにios keychain dumpコマンドを提供しています。

資格情報の保存

NSURLCredentialクラスは、NSUserDefautsや他のラッパーをバイパスして、キーチェーンに直接機密情報を保存するために理想的です。ログイン後に資格情報を保存するには、次のSwiftコードが使用されます：

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

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

iOS 8.0以降、ユーザーはSettings > General > Keyboard > Keyboardsの下で管理可能なカスタムキーボード拡張機能をインストールできます。これらのキーボードは拡張機能を提供しますが、キーストロークの記録や外部サーバーへのデータ送信のリスクを伴います。ただし、ユーザーにはネットワークアクセスが必要なキーボードについて通知されます。アプリは、カスタムキーボードの使用を機密情報の入力に制限すべきです。

セキュリティ推奨事項:

セキュリティを強化するために、サードパーティのキーボードを無効にすることが推奨されています。
デフォルトのiOSキーボードの自動修正およびオートサジェスト機能に注意することが重要です。これらは、Library/Keyboard/{locale}-dynamic-text.datまたは/private/var/mobile/Library/Keyboard/dynamic-text.datにあるキャッシュファイルに機密情報を保存する可能性があります。これらのキャッシュファイルは定期的に機密データをチェックする必要があります。キーボード辞書をリセットするには、Settings > General > Reset > Reset Keyboard Dictionaryを経由してキーボード辞書をリセットすることが推奨されます。
ネットワークトラフィックを傍受することで、カスタムキーボードがリモートでキーストロークを送信しているかどうかがわかります。

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

UITextInputTraitsプロトコルは、自動修正やセキュアなテキスト入力を管理するプロパティを提供し、機密情報のキャッシュを防止するために重要です。たとえば、自動修正を無効にし、セキュアなテキスト入力を有効にすることは、次のように実現できます:

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

また、開発者は、特にパスワードやPINなどの機密情報を入力するためのテキストフィールドについて、autocorrectionTypeをUITextAutocorrectionTypeNoに設定し、secureTextEntryをYESに設定することでキャッシュを無効にするようにする必要があります。

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

ログ

デバッグコードの解析には、ログの使用 がよく含まれます。ログには機密情報が含まれる可能性 があるため、リスクが伴います。以前は、iOS 6 およびそれ以前のバージョンでは、ログはすべてのアプリからアクセス可能であり、機密データの漏洩のリスクがありました。現在、アプリケーションは自分自身のログにのみアクセスできるように制限されています。

これらの制限にもかかわらず、ロック解除されたデバイスに物理的アクセス がある攻撃者は、コンピュータにデバイスを接続してログを読むことでこれを悪用することができます。ログはアプリのアンインストール後もディスク上に残っていることに注意することが重要です。

リスクを軽減するためには、アプリと徹底的にやり取りし、機密情報が誤ってログに記録されていないかを確認するために、すべての機能と入力を調査することが推奨されています。

潜在的な漏洩を確認するためにアプリのソースコードを確認する際には、NSLog、NSAssert、NSCAssert、fprintf のような組み込み関数のキーワードを使用した事前定義およびカスタムログステートメント、およびカスタム実装の場合の Logging または Logfile の言及を探します。

システムログの監視

アプリはさまざまな情報をログに記録することがあり、これらは機密情報になる可能性があります。これらのログを監視するために、次のようなツールやコマンドが使用されます：

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

ログアクティビティを観察するためのコマンドに続いて、問題の診断や潜在的なデータ漏洩の特定に非常に役立ちます。

***

<figure><img src="../../.gitbook/assets/image (48).png" alt=""><figcaption></figcaption></figure>

\
[**Trickest**](https://trickest.com/?utm_source=hacktricks&utm_medium=text&utm_campaign=ppc&utm_term=trickest&utm_content=ios-pentesting)を使用して、世界で最も先進的なコミュニティツールによって強化された**ワークフローを簡単に構築**および**自動化**します。\
今すぐアクセスしてください：

<div data-gb-custom-block data-tag="embed" data-url='https://trickest.com/?utm_source=hacktricks&utm_medium=banner&utm_campaign=ppc&utm_content=ios-pentesting'></div>

## バックアップ

iOSには**自動バックアップ機能**が統合されており、iTunes（macOS Catalinaまで）、Finder（macOS Catalina以降）、またはiCloudを介してデバイスデータのコピーを簡単に作成できます。これらのバックアップには、Apple Payの詳細やTouch IDの構成などの高度に機密性の高い要素を除く、ほぼすべてのデバイスデータが含まれています。

### セキュリティリスク

バックアップに**インストールされたアプリとそのデータ**が含まれることで、**データ漏洩**の問題が生じ、**バックアップの変更がアプリの機能を変更**するリスクがあります。これらのリスクを軽減するために、**アプリのディレクトリやサブディレクトリに機密情報を平文で保存しない**ことが推奨されています。

### バックアップからファイルを除外

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

### 脆弱性のテスト

アプリのバックアップセキュリティを評価するためには、Finderを使用して**バックアップを作成**し、次に[Appleの公式ドキュメント](https://support.apple.com/en-us/HT204215)のガイダンスに従ってそれを特定します。バックアップを機密データや構成で分析し、アプリの動作に影響を与える可能性のあるものを確認します。

機密情報は、コマンドラインツールや[iMazing](https://imazing.com)などのアプリケーションを使用して検索できます。暗号化されたバックアップの場合、暗号化の存在は、バックアップのルートにある"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>

暗号化されたバックアップの取り扱い

DinoSecのGitHubリポジトリで利用可能なPythonスクリプト、例えばbackup_tool.pyやbackup_passwd.pyは、最新のiTunes/Finderバージョンとの互換性を確保するために調整が必要かもしれませんが、役立つかもしれません。iOSbackupツールは、パスワードで保護されたバックアップ内のファイルにアクセスする別のオプションです。

アプリの動作の変更

バックアップの変更を通じてアプリの動作を変更する例として、Bither bitcoin walletアプリがあります。ここでは、UIロックPINがpin_codeキーの下にnet.bither.plistに保存されています。このキーをplistから削除し、バックアップを復元すると、PINの要件が削除され、制限なしにアクセスできます。

機密データのメモリテストに関する要約

アプリケーションのメモリに保存されている機密情報を取り扱う際には、このデータの露出時間を制限することが重要です。メモリ内容を調査するための主なアプローチには、メモリダンプの作成とリアルタイムでのメモリの分析があります。両方の方法には、ダンププロセスや分析中に重要なデータを見逃す可能性など、さまざまな課題があります。

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

脱獄済みおよび非脱獄済みデバイスの両方で、objectionやFridumpなどのツールを使用して、アプリのプロセスメモリをダンプすることができます。ダンプした後、このデータを分析するには、検索している情報の性質に応じてさまざまなツールが必要です。

メモリダンプから文字列を抽出するには、stringsやrabin2 -zzなどのコマンドを使用できます。

# 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は、メモリダンプを必要とせずにリアルタイムでアプリケーションのメモリを検査する強力な代替手段を提供します。このツールを使用すると、実行中のアプリケーションのメモリに直接検索コマンドを実行できます。

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

破れた暗号

鍵管理プロセスの不備

一部の開発者は、機密データをローカルストレージに保存し、コード内でハードコード化/予測可能なキーで暗号化しています。これは行ってはいけません。逆向きの操作により、攻撃者が機密情報を抽出する可能性があります。

安全でないおよび/または非推奨のアルゴリズムの使用

開発者は、非推奨のアルゴリズムを使用して認証チェック、データの保存または送信を行うべきではありません。これらのアルゴリズムの一部には、RC4、MD4、MD5、SHA1などがあります。たとえばパスワードを保存するためにハッシュが使用されている場合、ソルトを使用したハッシュが耐久性を持つべきです。

チェック

コード内にハードコードされたパスワード/シークレットが見つかるか、それらが予測可能であるか、コードがある種の弱い暗号アルゴリズムを使用しているかを確認するために行う主なチェックです。

興味深いことに、objectionを使用していくつかの暗号 ライブラリを自動的に監視できます。

ios monitor crypt

iOS暗号化APIおよびライブラリに関する詳細は、こちらを参照してください。

ローカル認証

ローカル認証は、特に暗号化手法を介してリモートエンドポイントへのアクセスを保護する場合に重要な役割を果たします。適切な実装がないと、ローカル認証メカニズムは回避される可能性があります。

Appleのローカル認証フレームワークとキーチェーンは、ユーザー認証ダイアログを容易にし、秘密データを安全に処理するための堅牢なAPIを提供しています。セキュアエンクレーブはTouch IDの指紋IDを保護し、Face IDは生体認証データを漏洩せずに顔認識に依存しています。

Touch ID/Face IDを統合するために、開発者は2つのAPI選択肢があります：

LocalAuthentication.framework：生体認証データにアクセスせずに高レベルのユーザー認証を行います。
Security.framework：生体認証を使用して秘密データを保護する、キーチェーンサービスへの低レベルアクセス。さまざまなオープンソースのラッパーがキーチェーンアクセスを簡素化します。

ただし、LocalAuthentication.frameworkとSecurity.frameworkの両方には脆弱性があり、認証プロセスのデータを送信せずに主にブール値を返すため、バイパスされやすくなっています（Don't touch me that way, by David Lindner et alを参照）。

ローカル認証の実装

ユーザーに認証を求めるには、開発者は**LAContextクラス内のevaluatePolicy**メソッドを使用し、次のいずれかを選択する必要があります：

deviceOwnerAuthentication：Touch IDまたはデバイスのパスコードを求め、どちらも有効になっていない場合は失敗します。
deviceOwnerAuthenticationWithBiometrics：Touch IDのみを求めます。

**evaluatePolicy**からのブール値の返り値により、認証が成功したかどうかが示され、潜在的なセキュリティ上の欠陥が強調されます。

キーチェーンを使用したローカル認証

iOSアプリでローカル認証を実装するには、キーチェーンAPIを使用して認証トークンなどの秘密データを安全に保存する必要があります。このプロセスにより、データはユーザーによってのみアクセスでき、デバイスのパスコードやTouch IDなどの生体認証を使用してアクセスできるようになります。

キーチェーンは、SecAccessControl属性を持つアイテムを設定する機能を提供し、ユーザーがTouch IDまたはデバイスのパスコードを使用して正常に認証するまでアイテムへのアクセスを制限します。この機能はセキュリティを向上させるために重要です。

以下は、SwiftとObjective-Cでのコード例で、キーチェーンに文字列を保存および取得する方法を示しています。これらのセキュリティ機能を活用し、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
}

iOSアプリケーションのペネトレーションテストでは、Objective-Cコードの解析が重要です。Objective-Cコードを理解することで、アプリケーションの脆弱性やセキュリティリスクを特定しやすくなります。

// 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
}

これで、キーチェーンから保存されたアイテムをリクエストできます。キーチェーンサービスは、適切な指紋が提供されたかどうかに応じて、ユーザーに認証ダイアログを表示し、データまたは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
}

iOSアプリケーションのペネトレーションテストでは、Objective-Cコードの解析が重要です。Objective-CはiOSアプリケーションの開発で広く使用されているプログラミング言語です。アプリケーションのセキュリティを評価する際には、Objective-Cコード内の脆弱性やセキュリティホールを特定することが重要です。

// 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バイオメトリクスバイパスを介して、このGitHubページにある、LocalAuthenticationメカニズムを克服するためのテクニックが利用可能です。このアプローチの中心には、evaluatePolicy関数を操作するためにFridaを活用し、実際の認証成功に関係なく常に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

evaluatePolicy の使用例は、DVIA-v2アプリケーションからの例です。

+(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"];
});
}
}

ローカル認証のバイパスを達成するために、Fridaスクリプトが書かれます。このスクリプトはevaluatePolicyのチェックを対象とし、そのコールバックを傍受してsuccess=1を返すようにします。コールバックの挙動を変更することで、認証チェックが効果的にバイパスされます。

以下のスクリプトは、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のようなプロキシを使用できます:

pageiOS Burp Suite Configuration

ホスト名の確認

TLS証明書を検証する一般的な問題の1つは、証明書が信頼されるCAによって署名されたことを確認することですが、証明書のホスト名がアクセスされているホスト名と一致しているかどうかを確認しないことです。この問題をBurpを使用してチェックするためには、iPhoneでBurp CAを信頼した後、Burpで異なるホスト名のために新しい証明書を作成して使用できます。アプリケーションがまだ動作する場合、何かが脆弱です。

証明書ピニング

アプリケーションが正しくSSL Pinningを使用している場合、アプリケーションは予想される証明書でのみ動作します。アプリケーションをテストする際には、これは問題になる可能性があります。Burpは独自の証明書を提供します。 この保護をバイパスするために、ジェイルブレイクされたデバイス内でアプリケーションSSL Kill Switchをインストールするか、Burp Mobile Assistantをインストールできます。

objectionのios sslpinning disableも使用できます。

その他

**/System/Library**には、システムアプリケーションで使用される電話にインストールされたフレームワークがあります。
ユーザーがApp Storeからインストールしたアプリケーションは**/User/Applications**内にあります。
**/User/Library**には、ユーザーレベルのアプリケーションによって保存されたデータが含まれています。
**/User/Library/Notes/notes.sqlite**にアクセスして、アプリケーション内に保存されたノートを読むことができます。
インストールされたアプリケーションのフォルダー内(/User/Applications/<APP ID>/)には、いくつかの興味深いファイルがあります:
- iTunesArtwork: アプリで使用されるアイコン
- iTunesMetadata.plist: App Storeで使用されるアプリの情報
- /Library/*: 設定とキャッシュが含まれています。**/Library/Cache/Snapshots/***には、アプリをバックグラウンドに送信する前に実行されたスナップショットが見つかります。

ホットパッチング/強制更新

開発者は、アプリケーションを再提出して承認されるまで待つ必要なく、すべてのインストールされたアプリケーションをリモートで即座にパッチすることができます。この目的のためには通常、JSPatchなどが使用されます。 ただし、Sirenやreact-native-appstore-version-checkerなどの他のオプションもあります。これは悪意のある第三者SDKによって悪用される可能性がある危険なメカニズムであるため、自動更新にどのような方法が使用されているかを確認し、テストすることが推奨されます。この目的のためにアプリの以前のバージョンをダウンロードしてみることができます。

サードパーティ

第三者SDKに関する重要な課題の1つは、その機能に対する細かい制御の欠如です。開発者は、SDKを統合し、潜在的なセキュリティの脆弱性やプライバシー上の懸念を含むすべての機能を受け入れるか、その利点を完全に放棄するかの選択を迫られます。これらのSDK内の脆弱性をパッチすることができないこともよくあります。さらに、SDKがコミュニティ内で信頼を得るにつれて、一部はマルウェアを含むようになることがあります。

第三者SDKが提供するサービスには、ユーザーの行動追跡、広告表示、ユーザーエクスペリエンスの向上などが含まれる場合があります。ただし、これにはリスクが伴います。開発者はこれらのライブラリによって実行されるコードについて完全に認識していない可能性があるため、潜在的なプライバシーおよびセキュリティリスクが発生する可能性があります。第三者サービスと共有される情報を必要最小限に抑え、機密データが公開されないようにすることが重要です。

第三者サービスの実装は通常、スタンドアロンライブラリまたは完全なSDKの2つの形式で提供されます。これらのサービスと共有されるすべてのデータは、個人を特定できる情報（PII）の開示を防ぐために匿名化されるべきです。

アプリケーションが使用するライブラリを特定するには、**otool**コマンドを使用できます。このツールは、アプリケーションとそれが使用する各共有ライブラリに対して実行され、追加のライブラリを発見するのに役立ちます。

otool -L <application_path>

参考文献とその他のリソース

Trickestを使用して、世界で最も高度なコミュニティツールによって強化されたワークフローを簡単に構築し自動化します。今すぐアクセスしてください：

Automate OffSec, EASM, and Custom Security Processes | Trickest

ゼロからヒーローまでのAWSハッキングを学ぶ htARTE（HackTricks AWS Red Team Expert）！

HackTricksをサポートする他の方法：

HackTricksで企業を宣伝したいまたはHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！
公式PEASS＆HackTricksのグッズを入手してください
独占的なNFTsコレクションであるThe PEASS Familyを発見
💬 Discordグループまたはtelegramグループに参加するか、Twitter 🐦 @carlospolopmをフォローしてください。
HackTricksとHackTricks CloudのgithubリポジトリにPRを提出して、あなたのハッキングトリックを共有してください。

PreviousiOS Pentesting Checklist NextiOS App Extensions

Last updated 3 days ago

iOSの基礎

テスト環境

初期分析

基本的なiOSテスト操作

基本的な静的解析

基本的な動的解析

インストールされたアプリのリスト表示

基本列挙とフック

IPAの構造

バイナリリバース

データの保存

Plist

Core Data

YapDatabase

その他のSQLiteデータベース

Firebase Real-Time Databases

Realm databases

Couchbase Lite データベース

Cookies

キャッシュ

スナップショット

Keychain

資格情報の保存

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

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

ログ

システムログの監視

暗号化されたバックアップの取り扱い

アプリの動作の変更

機密データのメモリテストに関する要約

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

ランタイムメモリ解析

破れた暗号

鍵管理プロセスの不備

安全でないおよび/または非推奨のアルゴリズムの使用

チェック

ローカル認証

ローカル認証の実装

キーチェーンを使用したローカル認証

検知

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

Objection

Frida

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

カスタムURIハンドラー / ディープリンク / カスタムスキーム

ユニバーサルリンク

UIActivity共有

UIPasteboard

アプリケーション拡張機能

WebViews

シリアル化とエンコーディング

ネットワーク通信

ホスト名の確認

証明書ピニング

その他

ホットパッチング/強制更新

サードパーティ

参考文献とその他のリソース