hacktricks/mobile-pentesting/ios-pentesting
2024-04-18 03:40:36 +00:00
..
basic-ios-testing-operations.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 01:39:37 +00:00
burp-configuration-for-ios.md Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat 2024-03-29 21:29:39 +00:00
extracting-entitlements-from-compiled-application.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 01:39:37 +00:00
frida-configuration-in-ios.md Translated ['crypto-and-stego/hash-length-extension-attack.md', 'forensi 2024-04-18 03:40:36 +00:00
ios-app-extensions.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 01:39:37 +00:00
ios-basics.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 01:39:37 +00:00
ios-custom-uri-handlers-deeplinks-custom-schemes.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 01:39:37 +00:00
ios-hooking-with-objection.md Translated ['forensics/basic-forensic-methodology/README.md', 'forensics 2024-02-09 01:39:37 +00:00
ios-protocol-handlers.md Translated ['mobile-pentesting/ios-pentesting/ios-protocol-handlers.md', 2024-02-09 08:23:12 +00:00
ios-serialisation-and-encoding.md Translated ['mobile-pentesting/ios-pentesting/README.md', 'mobile-pentes 2024-02-09 12:54:39 +00:00
ios-testing-environment.md Translated ['mobile-pentesting/ios-pentesting/README.md', 'mobile-pentes 2024-02-09 12:54:39 +00:00
ios-uiactivity-sharing.md Translated ['mobile-pentesting/ios-pentesting/README.md', 'mobile-pentes 2024-02-09 12:54:39 +00:00
ios-uipasteboard.md Translated ['binary-exploitation/rop-return-oriented-programing/ret2lib/ 2024-04-07 23:02:38 +00:00
ios-universal-links.md Translated ['mobile-pentesting/ios-pentesting/README.md', 'mobile-pentes 2024-02-09 12:54:39 +00:00
ios-webviews.md Translated ['forensics/basic-forensic-methodology/specific-software-file 2024-02-09 17:59:38 +00:00
README.md Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat 2024-03-29 21:29:39 +00:00

iOS Pentesting


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

htARTEHackTricks AWS Red Team Expertで**ゼロからヒーローまでのAWSハッキング**を学びましょう!

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

iOSの基礎

{% content-ref url="ios-basics.md" %} ios-basics.md {% endcontent-ref %}

テスト環境

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

{% content-ref url="ios-testing-environment.md" %} ios-testing-environment.md {% endcontent-ref %}

初期分析

基本的なiOSテスト操作

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

{% content-ref url="basic-ios-testing-operations.md" %} basic-ios-testing-operations.md {% endcontent-ref %}

{% hint style="info" %} 以下の手順には、アプリがデバイスにインストールされている必要があり、アプリケーションのIPAファイルをすでに取得している必要があります
これを行う方法については、基本的なiOSテスト操作ページを読んでください。 {% endhint %}

基本的な静的解析

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

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

  • PIEPosition Independent Executable:有効になっている場合、アプリケーションは起動するたびにランダムなメモリアドレスにロードされ、初期メモリアドレスを予測するのが難しくなります。
otool -hv <app-binary> | grep PIE   # PIEフラグを含める必要があります
  • スタックキャナリー:スタックの整合性を検証するために、関数を呼び出す前にスタックに「キャナリー」値が配置され、関数が終了すると再度検証されます。
otool -I -v <app-binary> | grep stack_chk   # stack_chk_guardおよびstack_chk_failのシンボルを含める必要があります
  • ARCAutomatic 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 を使用して学びます:

{% content-ref url="ios-hooking-with-objection.md" %} ios-hooking-with-objection.md {% endcontent-ref %}

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ディレクトリにあり、ユーザーがインストールしたアプリケーションは/private/var/containers/以下に配置されます。これらのアプリケーションには128ビットUUIDとして知られる一意の識別子が割り当てられており、ディレクトリ名のランダム性によりアプリのフォルダを手動で見つける作業が困難です。

ユーザーがインストールしたアプリのインストールディレクトリを見つけるために、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*"

次のようなコマンド、pslsofは、アプリのプロセスを特定したり、開いているファイルの一覧を表示したりするためにも利用できます。これにより、アプリケーションのアクティブなディレクトリパスに関する洞察が得られます。

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)ディレクトリをBundleディレクトリ内で詳しく見てみましょう(/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

iOSのペネトレーションテストでは、よりコンパクトな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;
};

しかし、バイナリを逆アセンブルするための最良のオプションは、HopperIDA です。


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

データの保存

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

{% content-ref url="ios-basics.md" %} ios-basics.md {% endcontent-ref %}

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

Plist

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

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

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

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

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

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

find ./ -name "*.plist"

macOSユーザー向け: plutilコマンドを利用します。これはmacOS10.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を開いて機密情報にアクセスできる場合、設定ミスを見つけたことになります。

{% code title="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");
}
}

{% endcode %}

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アプローチに従っています。iOSmacOS向けにネイティブに設計されており、データをシームレスに同期する機能を提供しています。

デバイス上で潜在的なCouchbaseデータベースを特定するには、次のディレクトリを調査する必要があります

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

Cookies

iOSアプリのクッキーは、各アプリのフォルダ内の**Library/Cookies/cookies.binarycookiesに保存されます。ただし、開発者は時々、クッキーファイルがバックアップでアクセス可能であるため、それらをキーチェーン**に保存することを選択することがあります。

クッキーファイルを検査するには、この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データベースです。

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

  1. ログアウト後にキャッシュされたレスポンスを削除することをお勧めします。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()
}

Objective-C:

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に設定します。アプリケーションがバックグラウンドになるたびに、現在のビューを常に上書きするため、機密データの漏洩を防ぎます。

Keychain

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

資格情報の保存

NSURLCredentialクラスは、機密情報を直接キーチェーンに保存するのに最適であり、NSUserDefaultsや他のラッパーをバイパスします。ログイン後に資格情報を保存するには、次の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;

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

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

ログ

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

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

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

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

システムログの監視

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

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

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

  1. Xcode を開きます。
  2. iOS デバイスを接続します。
  3. Window -> Devices and Simulators に移動します。
  4. デバイスを選択します。
  5. 調査中の問題をトリガーします。
  6. Open Console ボタンを使用して、新しいウィンドウでログを表示します。

より高度なログ記録のために、デバイスシェルに接続して socat を使用することでリアルタイムのログモニタリングが可能です:

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

ログアクティビティの観察コマンドに続いて、問題の診断やログ内の潜在的なデータ漏洩の特定に役立つかもしれないコマンドがあります。



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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

バックアップ

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

セキュリティリスク

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

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

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

脆弱性のテスト

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

機密情報は、コマンドラインツールや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>

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

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

アプリの動作の変更

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

機密データのメモリテストに関するまとめ

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

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

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

メモリダンプから文字列を抽出するには、stringsrabin2 -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およびライブラリに関する詳細は、https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptographyにアクセスしてください。

ローカル認証

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

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

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

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

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

ローカル認証の実装

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

  • deviceOwnerAuthenticationTouch IDまたはデバイスのパスコードを求め、どちらも有効でない場合は失敗します。
  • deviceOwnerAuthenticationWithBiometricsTouch 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
}

{% endtab %}

{% tab title="Objective-C" %}

iOSアプリケーションのペネトレーションテストを行う際に、Objective-Cの知識が必要となる場合があります。Objective-CはiOSアプリケーションの開発で広く使用されているプログラミング言語です。ペネトレーションテスターはObjective-Cの基本的な構文やiOSアプリケーションでの使用方法を理解する必要があります。{% endtab %}

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

{% endtab %}

{% tab title="Objective-C" %}

iOSアプリケーションのペネトレーションテストを行う際に、Objective-Cの知識が必要となる場合があります。Objective-Cは、iOSアプリケーションの開発に広く使用されているプログラミング言語です。ペネトレーションテスターは、Objective-Cの基本構文やiOSアプリケーションでの使用方法を理解する必要があります。アプリケーションの脆弱性を特定し、セキュリティを向上させるために、Objective-Cのコードを分析することが重要です。{% endtab %}

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

DVIA-v2アプリケーション から 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"];
});
}
}

ローカル認証のバイパスを達成するために、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を介した機密機能の露出

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

{% content-ref url="ios-custom-uri-handlers-deeplinks-custom-schemes.md" %} ios-custom-uri-handlers-deeplinks-custom-schemes.md {% endcontent-ref %}

ユニバーサルリンク

{% content-ref url="ios-universal-links.md" %} ios-universal-links.md {% endcontent-ref %}

UIActivity共有

{% content-ref url="ios-uiactivity-sharing.md" %} ios-uiactivity-sharing.md {% endcontent-ref %}

UIPasteboard

{% content-ref url="ios-uipasteboard.md" %} ios-uipasteboard.md {% endcontent-ref %}

アプリ拡張機能

{% content-ref url="ios-app-extensions.md" %} ios-app-extensions.md {% endcontent-ref %}

WebViews

{% content-ref url="ios-webviews.md" %} ios-webviews.md {% endcontent-ref %}

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

{% content-ref url="ios-serialisation-and-encoding.md" %} ios-serialisation-and-encoding.md {% endcontent-ref %}

ネットワーク通信

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

{% content-ref url="burp-configuration-for-ios.md" %} burp-configuration-for-ios.md {% endcontent-ref %}

ホスト名の確認

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

証明書ピニング

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

また、objectionios 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などが使用されます。 ただし、Sirenreact-native-appstore-version-checkerなどの他のオプションもあります。
これは悪意のある第三者SDKによって悪用される可能性がある危険なメカニズムであるため、自動更新にどの方法が使用されているかあればを確認し、テストすることが推奨されます。 この目的のために以前のバージョンのアプリをダウンロードしてみることができます。

サードパーティ

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

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

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

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

otool -L <application_path>

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


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

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

ゼロからヒーローまでのAWSハッキングを学ぶ htARTEHackTricks AWS Red Team Expert

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