Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-27 07:01:09 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/mobile-pentesting/ios-pentesting
History
Translator 36c970e3b9 Translated ['binary-exploitation/rop-return-oriented-programing/ret2lib/
2024-04-07 22:58:49 +00:00
..
basic-ios-testing-operations.md Translated to German 2024-02-10 15:36:32 +00:00
burp-configuration-for-ios.md Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat 2024-03-29 21:05:19 +00:00
extracting-entitlements-from-compiled-application.md Translated to German 2024-02-10 15:36:32 +00:00
frida-configuration-in-ios.md Translated to German 2024-02-10 15:36:32 +00:00
ios-app-extensions.md Translated to German 2024-02-10 15:36:32 +00:00
ios-basics.md Translated to German 2024-02-10 15:36:32 +00:00
ios-custom-uri-handlers-deeplinks-custom-schemes.md Translated to German 2024-02-10 15:36:32 +00:00
ios-hooking-with-objection.md Translated to German 2024-02-10 15:36:32 +00:00
ios-protocol-handlers.md Translated to German 2024-02-10 15:36:32 +00:00
ios-serialisation-and-encoding.md Translated to German 2024-02-10 15:36:32 +00:00
ios-testing-environment.md Translated to German 2024-02-10 15:36:32 +00:00
ios-uiactivity-sharing.md Translated to German 2024-02-10 15:36:32 +00:00
ios-uipasteboard.md Translated ['binary-exploitation/rop-return-oriented-programing/ret2lib/ 2024-04-07 22:58:49 +00:00
ios-universal-links.md Translated to German 2024-02-10 15:36:32 +00:00
ios-webviews.md Translated to German 2024-02-10 15:36:32 +00:00
README.md Translated ['README.md', 'backdoors/salseo.md', 'cryptography/certificat 2024-03-29 21:05:19 +00:00

README.md

iOS Pentesting


Verwenden Sie Trickest, um mühelos Workflows zu erstellen und zu automatisieren, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden.
Heute noch Zugriff erhalten:

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

Erlernen Sie AWS-Hacking von Null zum Profi mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

iOS-Grundlagen

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

Testumgebung

Auf dieser Seite finden Sie Informationen zum iOS-Simulator, Emulatoren und Jailbreaking:

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

Erstanalyse

Grundlegende iOS-Testoperationen

Während des Tests werden mehrere Operationen vorgeschlagen (Verbindung zum Gerät herstellen, Dateien lesen/schreiben/hochladen/herunterladen, einige Tools verwenden...). Wenn Sie also nicht wissen, wie Sie eine dieser Aktionen ausführen sollen, beginnen Sie mit dem Lesen der Seite:

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

{% hint style="info" %} Für die folgenden Schritte sollte die App im Gerät installiert sein und die IPA-Datei der Anwendung bereits erhalten worden sein.
Lesen Sie die Seite Grundlegende iOS-Testoperationen, um zu erfahren, wie dies gemacht wird. {% endhint %}

Grundlegende statische Analyse

Es wird empfohlen, das Tool MobSF zu verwenden, um eine automatische statische Analyse der IPA-Datei durchzuführen.

Identifizierung der Schutzmaßnahmen, die im Binärcode vorhanden sind:

  • PIE (Position Independent Executable): Wenn aktiviert, lädt die Anwendung bei jedem Start in eine zufällige Speicheradresse, was es schwieriger macht, ihre anfängliche Speicheradresse vorherzusagen.
otool -hv <app-binary> | grep PIE   # Es sollte die PIE-Flagge enthalten
  • Stack Canaries: Zur Validierung der Integrität des Stacks wird vor dem Aufruf einer Funktion ein "Canary"-Wert auf den Stack gelegt und wird erneut validiert, sobald die Funktion endet.
otool -I -v <app-binary> | grep stack_chk   # Es sollte die Symbole: stack_chk_guard und stack_chk_fail enthalten
  • ARC (Automatic Reference Counting): Zur Verhinderung gängiger Speicherkorruptionsfehler
otool -I -v <app-binary> | grep objc_release   # Es sollte das Symbol _objc_release enthalten
  • Verschlüsseltes Binär: Das Binär sollte verschlüsselt sein
otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # Der cryptid sollte 1 sein

Identifizierung von sensiblen/unsicheren Funktionen

  • Schwache Hashing-Algorithmen
# Auf dem iOS-Gerät
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"

# Auf Linux
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"
  • Unsichere Zufallsfunktionen
# Auf dem iOS-Gerät
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# Auf Linux
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"
  • Unsichere 'Malloc'-Funktion
# Auf dem iOS-Gerät
otool -Iv <app> | grep -w "_malloc"

# Auf Linux
grep -iER "_malloc"
  • Unsichere und verwundbare Funktionen
# Auf dem iOS-Gerät
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"

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

Grundlegende dynamische Analyse

Schauen Sie sich die dynamische Analyse an, die von MobSF durchgeführt wird. Sie müssen durch die verschiedenen Ansichten navigieren und mit ihnen interagieren, aber es wird mehrere Klassen anhängen und andere Dinge tun und einen Bericht erstellen, sobald Sie fertig sind.

Auflistung installierter Apps

Verwenden Sie den Befehl frida-ps -Uai, um den Bundle-Identifier der installierten Apps zu bestimmen:

$ 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

Grundlegende Enumeration & Hooking

Erfahren Sie, wie Sie die Komponenten der Anwendung aufzählen und wie Sie ganz einfach Methoden und Klassen hooken können mit Objection:

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

IPA-Struktur

Die Struktur einer IPA-Datei entspricht im Wesentlichen der einer gezippten Paketdatei. Durch Umbenennen der Dateierweiterung in .zip kann sie dekomprimiert werden, um ihren Inhalt preiszugeben. Innerhalb dieser Struktur repräsentiert ein Bundle eine vollständig verpackte Anwendung, die zur Installation bereit ist. Darin finden Sie ein Verzeichnis mit dem Namen <NAME>.app, das die Ressourcen der Anwendung umschließt.

  • Info.plist: Diese Datei enthält spezifische Konfigurationsdetails der Anwendung.
  • _CodeSignature/: Dieses Verzeichnis enthält eine plist-Datei, die eine Signatur enthält, die die Integrität aller Dateien im Bundle gewährleistet.
  • Assets.car: Ein komprimiertes Archiv, das Asset-Dateien wie Icons speichert.
  • Frameworks/: Dieser Ordner enthält die nativen Bibliotheken der Anwendung, die in Form von .dylib- oder .framework-Dateien vorliegen können.
  • PlugIns/: Dies kann Erweiterungen der Anwendung enthalten, die als .appex-Dateien bekannt sind, obwohl sie nicht immer vorhanden sind.
  • Core Data: Wird verwendet, um die dauerhaften Daten Ihrer Anwendung für die Offline-Nutzung zu speichern, temporäre Daten zu zwischenspeichern und Ihrer App auf einem Gerät die Möglichkeit zum Rückgängigmachen hinzuzufügen. Um Daten über mehrere Geräte in einem iCloud-Konto zu synchronisieren, spiegelt Core Data automatisch Ihr Schema in einen CloudKit-Container.
  • PkgInfo: Die PkgInfo-Datei ist eine alternative Möglichkeit, den Typ und die Ersteller-Codes Ihrer Anwendung oder Ihres Bundles anzugeben.
  • en.lproj, fr.proj, Base.lproj: Sind die Sprachpakete, die Ressourcen für diese spezifischen Sprachen enthalten, sowie eine Standardressource für den Fall, dass eine Sprache nicht unterstützt wird.
  • Sicherheit: Das Verzeichnis _CodeSignature/ spielt eine entscheidende Rolle in der Sicherheit der App, indem es die Integrität aller gebündelten Dateien durch digitale Signaturen überprüft.
  • Asset-Management: Die Datei Assets.car verwendet Kompression, um grafische Assets effizient zu verwalten, was entscheidend ist, um die Leistung der Anwendung zu optimieren und ihre Gesamtgröße zu reduzieren.
  • Frameworks und PlugIns: Diese Verzeichnisse unterstreichen die Modularität von iOS-Anwendungen, indem sie Entwicklern ermöglichen, wiederverwendbare Codebibliotheken (Frameworks/) einzuschließen und die Funktionalität der App zu erweitern (PlugIns/).
  • Lokalisierung: Die Struktur unterstützt mehrere Sprachen, erleichtert die globale Anwendungsbereich durch Bereitstellung von Ressourcen für spezifische Sprachpakete.

Info.plist

Das Info.plist dient als Grundpfeiler für iOS-Anwendungen und umschließt wichtige Konfigurationsdaten in Form von Schlüssel-Wert-Paaren. Diese Datei ist nicht nur für Anwendungen, sondern auch für App-Erweiterungen und in Bundles gebündelte Frameworks erforderlich. Sie ist strukturiert entweder in XML oder einem binären Format und enthält wichtige Informationen von App-Berechtigungen bis hin zu Sicherheitskonfigurationen. Für eine detaillierte Erkundung der verfügbaren Schlüssel kann man sich an die Apple Developer-Dokumentation wenden.

Für diejenigen, die mit dieser Datei in einem zugänglicheren Format arbeiten möchten, kann die XML-Konvertierung mühelos durch die Verwendung von plutil auf macOS (standardmäßig verfügbar ab Version 10.2) oder plistutil auf Linux erreicht werden. Die Befehle zur Konvertierung lauten wie folgt:

  • Für macOS:
$ plutil -convert xml1 Info.plist
  • Für Linux:
$ apt install libplist-utils
$ plistutil -i Info.plist -o Info_xml.plist

Unter den zahlreichen Informationen, die die Info.plist-Datei preisgeben kann, sind bemerkenswerte Einträge die Berechtigungszeichenfolgen der App (UsageDescription), benutzerdefinierte URL-Schemas (CFBundleURLTypes) und Konfigurationen für die App Transport Security (NSAppTransportSecurity). Diese Einträge sowie andere wie exportierte/importierte benutzerdefinierte Dokumenttypen (UTExportedTypeDeclarations / UTImportedTypeDeclarations) können mühelos durch Inspektion der Datei oder durch Verwendung eines einfachen grep-Befehls gefunden werden:

$ grep -i <keyword> Info.plist

Datenpfade

In der iOS-Umgebung sind Verzeichnisse speziell für Systemanwendungen und benutzerinstallierte Anwendungen vorgesehen. Systemanwendungen befinden sich im Verzeichnis /Applications, während benutzerinstallierte Apps unter /private/var/containers/ platziert werden. Diese Anwendungen erhalten einen eindeutigen Bezeichner, der als 128-Bit-UUID bekannt ist, was die manuelle Lokalisierung des App-Ordners aufgrund der Zufälligkeit der Verzeichnisnamen erschwert.

Um die Entdeckung des Installationsverzeichnisses einer benutzerinstallierten App zu erleichtern, bietet das objection tool einen nützlichen Befehl namens env. Dieser Befehl zeigt detaillierte Verzeichnisinformationen für die betreffende App an. Nachfolgend ein Beispiel zur Verwendung dieses Befehls:

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

Alternativ kann der App-Name mithilfe des find-Befehls im Verzeichnis /private/var/containers gesucht werden:

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

Befehle wie ps und lsof können ebenfalls verwendet werden, um den Prozess der App zu identifizieren und geöffnete Dateien aufzulisten, was Einblicke in die aktiven Verzeichnispfade der Anwendung liefert:

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

Bundle-Verzeichnis:

  • AppName.app
  • Dies ist das Anwendungs-Bundle, wie es zuvor in der IPA gesehen wurde. Es enthält wesentliche Anwendungsdaten, statische Inhalte sowie das kompilierte Binär der Anwendung.
  • Dieses Verzeichnis ist für Benutzer sichtbar, aber Benutzer können nicht darauf schreiben.
  • Der Inhalt dieses Verzeichnisses wird nicht gesichert.
  • Der Inhalt dieses Ordners wird verwendet, um die Code-Signatur zu validieren.

Datenverzeichnis:

  • Dokumente/
  • Enthält alle vom Benutzer generierten Daten. Der Endbenutzer der Anwendung initiiert die Erstellung dieser Daten.
  • Sichtbar für Benutzer und Benutzer können darauf schreiben.
  • Der Inhalt dieses Verzeichnisses wird gesichert.
  • Die App kann Pfade deaktivieren, indem NSURLIsExcludedFromBackupKey festgelegt wird.
  • Bibliothek/
  • Enthält alle Dateien, die nicht benutzerspezifisch sind, wie Caches, Einstellungen, Cookies und Property-List (plist) Konfigurationsdateien.
  • iOS-Apps verwenden normalerweise die Unterverzeichnisse Application Support und Caches, aber die App kann benutzerdefinierte Unterverzeichnisse erstellen.
  • Bibliothek/Caches/
  • Enthält halbpermanente zwischengespeicherte Dateien.
  • Für Benutzer unsichtbar und Benutzer können nicht darauf schreiben.
  • Der Inhalt dieses Verzeichnisses wird nicht gesichert.
  • Das Betriebssystem kann die Dateien dieses Verzeichnisses automatisch löschen, wenn die App nicht läuft und der Speicherplatz knapp wird.
  • Bibliothek/Application Support/
  • Enthält persistente Dateien, die für das Ausführen der App erforderlich sind.
  • Unsichtbar für Benutzer und Benutzer können nicht darauf schreiben.
  • Der Inhalt dieses Verzeichnisses wird gesichert.
  • Die App kann Pfade deaktivieren, indem NSURLIsExcludedFromBackupKey festgelegt wird.
  • Bibliothek/Einstellungen/
  • Wird zum Speichern von Eigenschaften verwendet, die auch nach einem Neustart der Anwendung bestehen bleiben können.
  • Informationen werden unverschlüsselt innerhalb des Anwendungssandkastens in einer plist-Datei namens [BUNDLE_ID].plist gespeichert.
  • Alle mit NSUserDefaults gespeicherten Schlüssel/Wert-Paare sind in dieser Datei zu finden.
  • tmp/
  • Verwenden Sie dieses Verzeichnis, um temporäre Dateien zu schreiben, die zwischen App-Starts nicht bestehen müssen.
  • Enthält nicht persistente zwischengespeicherte Dateien.
  • Für Benutzer unsichtbar.
  • Der Inhalt dieses Verzeichnisses wird nicht gesichert.
  • Das Betriebssystem kann die Dateien dieses Verzeichnisses automatisch löschen, wenn die App nicht läuft und der Speicherplatz knapp wird.

Lassen Sie uns einen genaueren Blick auf das Anwendungs-Bundle (.app) Verzeichnis von iGoat-Swift im Bundle-Verzeichnis (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app) werfen:

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

Binäre Umkehrung

Im Ordner <application-name>.app finden Sie eine Binärdatei namens <application-name>. Dies ist die Datei, die ausgeführt wird. Sie können eine grundlegende Inspektion der Binärdatei mit dem Tool otool durchführen:

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)
[...]

Überprüfen Sie, ob die App verschlüsselt ist

Überprüfen Sie, ob es einen Output für:

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

Das Auseinandernehmen des Binärdatei

Disassemblieren Sie den Textabschnitt:

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

Um das Objective-C-Segment der Beispielanwendung auszudrucken, kann man Folgendes verwenden:

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

Um einen kompakteren Objective-C-Code zu erhalten, können Sie class-dump verwenden:

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

Jedoch sind die besten Optionen zum Disassemblieren der Binärdatei: Hopper und IDA.


Verwenden Sie Trickest, um einfach Workflows zu erstellen und zu automatisieren, die von den weltweit fortschrittlichsten Community-Tools unterstützt werden.
Heute Zugriff erhalten:

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

Datenspeicherung

Um zu erfahren, wie iOS Daten auf dem Gerät speichert, lesen Sie diese Seite:

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

{% hint style="warning" %} Die folgenden Speicherorte für Informationen sollten direkt nach der Installation der Anwendung, nach Überprüfung aller Funktionen der Anwendung und sogar nach dem Abmelden von einem Benutzer und Anmelden bei einem anderen überprüft werden.
Das Ziel ist es, unprotected sensitive Informationen der Anwendung (Passwörter, Tokens), des aktuellen Benutzers und der zuvor angemeldeten Benutzer zu finden. {% endhint %}

Plist

plist-Dateien sind strukturierte XML-Dateien, die Schlüssel-Wert-Paare enthalten. Es ist eine Möglichkeit, persistente Daten zu speichern, daher können manchmal sensible Informationen in diesen Dateien gefunden werden. Es wird empfohlen, diese Dateien nach der Installation der App und nach intensiver Nutzung zu überprüfen, um zu sehen, ob neue Daten geschrieben werden.

Der häufigste Weg, um Daten in plist-Dateien zu speichern, ist die Verwendung von NSUserDefaults. Diese plist-Datei wird im App-Sandbox unter Library/Preferences/<appBundleID>.plist gespeichert.

Die NSUserDefaults-Klasse bietet eine programmatische Schnittstelle zum Interagieren mit dem Standardsystem. Das Standardsystem ermöglicht es einer Anwendung, ihr Verhalten entsprechend den Benutzervorlieben anzupassen. Daten, die von NSUserDefaults gespeichert werden, können im Anwendungs-Bundle eingesehen werden. Diese Klasse speichert Daten in einer plist-Datei, ist jedoch für die Verwendung mit kleinen Datenmengen gedacht.

Diese Daten können nicht direkt über einen vertrauenswürdigen Computer abgerufen werden, können jedoch durch ein Backup abgerufen werden.

Sie können die gespeicherten Informationen mit NSUserDefaults mithilfe von objection's ios nsuserdefaults get dumpen.

Um alle vom Anwendungen verwendeten plist-Dateien zu finden, können Sie auf /private/var/mobile/Containers/Data/Application/{APPID} zugreifen und ausführen:

find ./ -name "*.plist"

Um Dateien vom Format XML oder binär (bplist) in XML umzuwandeln, stehen je nach Betriebssystem verschiedene Methoden zur Verfügung:

Für macOS-Benutzer: Verwenden Sie den Befehl plutil. Es handelt sich um ein integriertes Tool in macOS (10.2+), das für diesen Zweck entwickelt wurde:

$ plutil -convert xml1 Info.plist

Für Linux-Benutzer: Installieren Sie zuerst libplist-utils und verwenden Sie dann plistutil, um Ihre Datei zu konvertieren:

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

Innerhalb einer Objection-Sitzung: Zum Analysieren von mobilen Anwendungen ermöglicht ein spezifischer Befehl das direkte Konvertieren von plist-Dateien:

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

Core Data

Core Data ist ein Framework zur Verwaltung der Modellschicht von Objekten in Ihrer Anwendung. Core Data kann SQLite als seinen persistenten Speicher verwenden, aber das Framework selbst ist keine Datenbank. CoreData verschlüsselt standardmäßig nicht seine Daten. Es kann jedoch eine zusätzliche Verschlüsselungsschicht zu CoreData hinzugefügt werden. Weitere Details finden Sie im GitHub Repo.

Sie können die SQLite Core Data-Informationen einer Anwendung im Pfad /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support finden.

Wenn Sie SQLite öffnen und auf sensible Informationen zugreifen können, haben Sie eine Fehlkonfiguration gefunden.

{% code title="Code aus 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 ist ein Key/Value-Speicher, der auf SQLite aufbaut.
Da die Yap-Datenbanken SQLite-Datenbanken sind, können Sie sie mithilfe des im vorherigen Abschnitt vorgeschlagenen Befehls finden.

Andere SQLite-Datenbanken

Es ist üblich, dass Anwendungen ihre eigenen SQLite-Datenbanken erstellen. Möglicherweise speichern sie sensible Daten darin und lassen sie unverschlüsselt. Daher ist es immer interessant, jede Datenbank im Anwendungsverzeichnis zu überprüfen. Gehen Sie daher in das Anwendungsverzeichnis, in dem die Daten gespeichert sind (/private/var/mobile/Containers/Data/Application/{APPID}).

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

Firebase-Echtzeitdatenbanken

Entwickler können Daten in einer NoSQL-Cloud-Datenbank speichern und synchronisieren, indem sie Firebase-Echtzeitdatenbanken verwenden. Die Daten werden im JSON-Format gespeichert und in Echtzeit mit allen verbundenen Clients synchronisiert.

Hier erfahren Sie, wie Sie nach fehlerhaft konfigurierten Firebase-Datenbanken suchen können:

{% content-ref url="../../network-services-pentesting/pentesting-web/buckets/firebase-database.md" %} firebase-database.md {% endcontent-ref %}

Realm-Datenbanken

Realm Objective-C und Realm Swift bieten eine leistungsstarke Alternative für die Datenspeicherung, die von Apple nicht bereitgestellt wird. Standardmäßig werden die Daten unverschlüsselt gespeichert, wobei Verschlüsselung durch spezifische Konfiguration verfügbar ist.

Die Datenbanken befinden sich unter: /private/var/mobile/Containers/Data/Application/{APPID}. Um diese Dateien zu erkunden, können Befehle wie:

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

Um diese Datenbankdateien anzuzeigen, wird das Realm Studio Tool empfohlen.

Um eine Verschlüsselung in einer Realm-Datenbank zu implementieren, kann der folgende Code-Schnipsel verwendet werden:

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

Couchbase Lite wird als leichtgewichtige und eingebettete Datenbank-Engine beschrieben, die dem dokumentenorientierten (NoSQL) Ansatz folgt. Entwickelt, um nativ für iOS und macOS zu sein, bietet sie die Möglichkeit, Daten nahtlos zu synchronisieren.

Um potenzielle Couchbase-Datenbanken auf einem Gerät zu identifizieren, sollte das folgende Verzeichnis überprüft werden:

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

Cookies

iOS speichert die Cookies der Apps im Library/Cookies/cookies.binarycookies innerhalb des Ordners jeder App. Manchmal entscheiden sich Entwickler jedoch dafür, sie im Schlüsselbund zu speichern, da die genannte Cookie-Datei in Backups abgerufen werden kann.

Um die Cookies-Datei zu inspizieren, können Sie dieses Python-Skript verwenden oder ios cookies get von objection nutzen.
Sie können auch objection verwenden, um diese Dateien in ein JSON-Format zu konvertieren und die Daten zu inspizieren.

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

Standardmäßig speichert NSURLSession Daten wie HTTP-Anfragen und -Antworten in der Cache.db-Datenbank. Diese Datenbank kann sensible Daten enthalten, wenn Tokens, Benutzernamen oder andere sensible Informationen zwischengespeichert wurden. Um die zwischengespeicherten Informationen zu finden, öffnen Sie das Datenverzeichnis der App (/var/mobile/Containers/Data/Application/<UUID>) und gehen Sie zu /Library/Caches/<Bundle Identifier>. Der WebKit-Cache wird ebenfalls in der Cache.db-Datei gespeichert. Objection kann die Datenbank mit dem Befehl sqlite connect Cache.db öffnen und damit interagieren, da es sich um eine normale SQLite-Datenbank handelt.

Es wird empfohlen, das Zwischenspeichern dieser Daten zu deaktivieren, da sie möglicherweise sensible Informationen in der Anfrage oder Antwort enthalten. Die folgende Liste zeigt verschiedene Möglichkeiten, dies zu erreichen:

  1. Es wird empfohlen, zwischengespeicherte Antworten nach dem Abmelden zu entfernen. Dies kann mit der von Apple bereitgestellten Methode removeAllCachedResponses durchgeführt werden. Sie können diese Methode wie folgt aufrufen:

URLCache.shared.removeAllCachedResponses()

Diese Methode entfernt alle zwischengespeicherten Anfragen und Antworten aus der Cache.db-Datei. 2. Wenn Sie den Vorteil von Cookies nicht benötigen, wird empfohlen, einfach die .ephemeral-Konfigurationseigenschaft von URLSession zu verwenden, die das Speichern von Cookies und Caches deaktiviert.

Apple-Dokumentation:

Ein ephemeres Sitzungskonfigurationsobjekt ähnelt einer Standard-Sitzungskonfiguration (siehe default), mit der Ausnahme, dass das entsprechende Sitzungsobjekt keine Caches, Anmeldeinformationsspeicher oder andere sitzungsbezogene Daten auf die Festplatte schreibt. Stattdessen werden sitzungsbezogene Daten im RAM gespeichert. Ein ephemeres Sitzungskonfigurationsobjekt schreibt Daten nur dann auf die Festplatte, wenn Sie ihm sagen, den Inhalt einer URL in eine Datei zu schreiben. 3. Die Cache kann auch deaktiviert werden, indem die Cache-Richtlinie auf .notAllowed gesetzt wird. Dadurch wird das Speichern des Caches in keiner Weise deaktiviert, weder im Speicher noch auf der Festplatte.

Snapshots

Immer wenn Sie die Home-Taste drücken, erstellt iOS einen Schnappschuss des aktuellen Bildschirms, um den Übergang zur Anwendung auf eine viel reibungslosere Weise zu ermöglichen. Wenn jedoch sensible Daten auf dem aktuellen Bildschirm vorhanden sind, werden sie im Bild gespeichert (das über Neustarts hinweg bestehen bleibt). Dies sind die Schnappschüsse, auf die Sie auch zugreifen können, indem Sie zweimal auf den Home-Bildschirm tippen, um zwischen Apps zu wechseln.

Sofern das iPhone nicht gejailbreakt ist, muss der Angreifer Zugriff auf das entsperrte Gerät haben, um diese Bildschirmdarstellungen zu sehen. Standardmäßig wird der letzte Schnappschuss im Sandbox der Anwendung im Ordner Library/Caches/Snapshots/ oder Library/SplashBoard/Snapshots gespeichert (vertrauenswürdige Computer können nicht ab iOS 7.0 auf das Dateisystem zugreifen).

Eine Möglichkeit, dieses unerwünschte Verhalten zu verhindern, besteht darin, einen leeren Bildschirm einzufügen oder die sensiblen Daten vor dem Erstellen des Schnappschusses mithilfe der Funktion ApplicationDidEnterBackground() zu entfernen.

Im Folgenden finden Sie eine Beispielmethode zur Behebung, die einen Standard-Screenshot festlegt.

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 ist eine objektorientierte Programmiersprache, die häufig für die Entwicklung von iOS-Apps verwendet wird. Es ist wichtig, Objective-C zu verstehen, um effektiv iOS-Apps zu pentesten.

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

Hintergrundbild

Dies setzt das Hintergrundbild auf overlayImage.png, wann immer die Anwendung in den Hintergrund verschoben wird. Es verhindert das Leaken sensibler Daten, da overlayImage.png immer die aktuelle Ansicht überschreibt.

Schlüsselbund

Zum Zugriff auf und Verwalten des iOS-Schlüsselbunds stehen Tools wie Keychain-Dumper zur Verfügung, die für gejailbreakte Geräte geeignet sind. Darüber hinaus bietet Objection den Befehl ios keychain dump für ähnliche Zwecke.

Anmeldeinformationen speichern

Die Klasse NSURLCredential eignet sich ideal zum Speichern sensibler Informationen direkt im Schlüsselbund, um die Notwendigkeit von NSUserDefaults oder anderen Wrappern zu umgehen. Um Anmeldeinformationen nach dem Login zu speichern, wird der folgende Swift-Code verwendet:

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

Um diese gespeicherten Anmeldeinformationen zu extrahieren, wird der Befehl ios nsurlcredentialstorage dump von Objection verwendet.

Benutzerdefinierte Tastaturen und Tastaturcache

Ab iOS 8.0 können Benutzer benutzerdefinierte Tastaturerweiterungen installieren, die unter Einstellungen > Allgemein > Tastatur > Tastaturen verwaltet werden können. Obwohl diese Tastaturen erweiterte Funktionalitäten bieten, stellen sie ein Risiko für Tastenanschlagprotokollierung und die Übertragung von Daten an externe Server dar, obwohl Benutzer über Tastaturen informiert werden, die Netzwerkzugriff erfordern. Apps können und sollten die Verwendung von benutzerdefinierten Tastaturen für die Eingabe sensibler Informationen einschränken.

Sicherheitsempfehlungen:

  • Es wird empfohlen, Drittanbieter-Tastaturen für erhöhte Sicherheit zu deaktivieren.
  • Achten Sie auf die Auto-Korrektur- und Auto-Vorschlagsfunktionen der Standard-iOS-Tastatur, die sensible Informationen in Cache-Dateien speichern könnten, die sich in Library/Keyboard/{locale}-dynamic-text.dat oder /private/var/mobile/Library/Keyboard/dynamic-text.dat befinden. Diese Cache-Dateien sollten regelmäßig auf sensible Daten überprüft werden. Es wird empfohlen, das Tastaturwörterbuch über Einstellungen > Allgemein > Zurücksetzen > Tastaturwörterbuch zurücksetzen zurückzusetzen, um zwischengespeicherte Daten zu löschen.
  • Das Abfangen des Netzwerkverkehrs kann aufzeigen, ob eine benutzerdefinierte Tastatur Tastenanschläge remote überträgt.

Verhindern des Cachens von Textfeldern

Das UITextInputTraits-Protokoll bietet Eigenschaften zur Verwaltung der Auto-Korrektur und zur sicheren Texteingabe, die für die Verhinderung des Cachens sensibler Informationen unerlässlich sind. Beispielsweise kann das Deaktivieren der Auto-Korrektur und das Aktivieren der sicheren Texteingabe mit folgendem erreicht werden:

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

Darüber hinaus sollten Entwickler sicherstellen, dass Textfelder, insbesondere solche zum Eingeben sensibler Informationen wie Passwörter und PINs, das Zwischenspeichern deaktivieren, indem sie autocorrectionType auf UITextAutocorrectionTypeNo und secureTextEntry auf YES setzen.

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

Protokolle

Die Fehlerbehebung von Code beinhaltet oft die Verwendung von Protokollierung. Es besteht ein Risiko, da Protokolle sensible Informationen enthalten können. Früher waren in iOS 6 und früheren Versionen die Protokolle für alle Apps zugänglich, was ein Risiko für die unerwünschte Offenlegung sensibler Daten darstellte. Jetzt haben Anwendungen nur Zugriff auf ihre eigenen Protokolle.

Trotz dieser Einschränkungen kann ein Angreifer mit physischem Zugriff auf ein entsperrtes Gerät dies immer noch ausnutzen, indem er das Gerät mit einem Computer verbindet und die Protokolle liest. Es ist wichtig zu beachten, dass die Protokolle auch nach der Deinstallation der App auf der Festplatte verbleiben.

Um Risiken zu minimieren, wird empfohlen, ausführlich mit der App zu interagieren, alle Funktionen und Eingaben zu erkunden, um sicherzustellen, dass keine sensiblen Informationen unbeabsichtigt protokolliert werden.

Beim Überprüfen des Quellcodes der App auf mögliche Lecks sollten sowohl vordefinierte als auch benutzerdefinierte Protokollierungsanweisungen gesucht werden, die Schlüsselwörter wie NSLog, NSAssert, NSCAssert, fprintf für integrierte Funktionen und Erwähnungen von Logging oder Logfile für benutzerdefinierte Implementierungen enthalten.

Überwachung von Systemprotokollen

Apps protokollieren verschiedene Informationen, die sensibel sein können. Zur Überwachung dieser Protokolle werden Tools und Befehle wie:

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

Sind nützlich. Darüber hinaus bietet Xcode eine Möglichkeit, Konsolenprotokolle zu sammeln:

  1. Öffnen Sie Xcode.
  2. Verbinden Sie das iOS-Gerät.
  3. Navigieren Sie zu Fenster -> Geräte und Simulatoren.
  4. Wählen Sie Ihr Gerät aus.
  5. Lösen Sie das Problem aus, das Sie untersuchen.
  6. Verwenden Sie die Schaltfläche Konsole öffnen, um Protokolle in einem neuen Fenster anzuzeigen.

Für fortgeschrittenes Protokollieren kann die Verbindung zur Geräteshell und die Verwendung von socat eine Echtzeit-Protokollüberwachung ermöglichen:

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

Sicherheitsrisiken

Die Einbeziehung von installierten Apps und deren Daten in Backups wirft die Frage nach potenziellen Datenlecks auf und das Risiko, dass Backup-Änderungen die App-Funktionalität beeinträchtigen könnten. Es wird empfohlen, keine sensiblen Informationen im Klartext im Verzeichnis einer App oder in dessen Unterverzeichnissen zu speichern, um diese Risiken zu minimieren.

Ausschließen von Dateien aus Backups

Dateien in Documents/ und Library/Application Support/ werden standardmäßig gesichert. Entwickler können bestimmte Dateien oder Verzeichnisse von Backups ausschließen, indem sie NSURL setResourceValue:forKey:error: mit dem NSURLIsExcludedFromBackupKey verwenden. Diese Praxis ist entscheidend, um sensible Daten vor der Aufnahme in Backups zu schützen.

Testen auf Sicherheitslücken

Um die Backup-Sicherheit einer App zu bewerten, beginnen Sie mit dem Erstellen eines Backups mit Finder und lokalisieren es mithilfe der Anleitung von Apple's offizieller Dokumentation. Analysieren Sie das Backup auf sensible Daten oder Konfigurationen, die geändert werden könnten, um das Verhalten der App zu beeinflussen.

Sensible Informationen können mithilfe von Befehlszeilentools oder Anwendungen wie iMazing gesucht werden. Bei verschlüsselten Backups kann die Verschlüsselung durch Überprüfen des Schlüssels "IsEncrypted" in der Datei "Manifest.plist" im Stammverzeichnis des Backups bestätigt werden.

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

Für den Umgang mit verschlüsselten Backups können Python-Skripte aus dem DinoSec GitHub-Repository wie backup_tool.py und backup_passwd.py nützlich sein, erfordern jedoch möglicherweise Anpassungen, um mit den neuesten iTunes/Finder-Versionen kompatibel zu sein. Das iOSbackup-Tool ist eine weitere Option zum Zugriff auf Dateien innerhalb von passwortgeschützten Backups.

Modifizierung des App-Verhaltens

Ein Beispiel für die Änderung des App-Verhaltens durch Backup-Modifikationen wird in der Bither Bitcoin Wallet App demonstriert, wo die UI-Sperr-PIN unter dem Schlüssel pin_code in net.bither.plist gespeichert ist. Durch Entfernen dieses Schlüssels aus der Plist und Wiederherstellen des Backups wird die PIN-Anforderung entfernt und bietet uneingeschränkten Zugriff.

Zusammenfassung zum Speichertesten sensibler Daten

Beim Umgang mit sensiblen Informationen, die in einem Anwendungs-Speicher gespeichert sind, ist es entscheidend, die Expositionszeit dieser Daten zu begrenzen. Es gibt zwei Hauptansätze zur Untersuchung des Speicherinhalts: Erstellen eines Speicher-Dumps und Analysieren des Speichers in Echtzeit. Beide Methoden haben ihre Herausforderungen, einschließlich der Möglichkeit, während des Dump-Prozesses oder der Analyse wichtige Daten zu übersehen.

Abrufen und Analysieren eines Speicher-Dumps

Für sowohl gejailbreakte als auch nicht-gejailbreakte Geräte ermöglichen Tools wie objection und Fridump das Dumpen des App-Prozessspeichers. Nach dem Dumpen erfordert die Analyse dieser Daten verschiedene Tools, abhängig von der Art der gesuchten Informationen.

Um Zeichenfolgen aus einem Speicher-Dump zu extrahieren, können Befehle wie strings oder rabin2 -zz verwendet werden:

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

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

Für eine genauere Analyse, einschließlich der Suche nach spezifischen Datentypen oder Mustern, bietet radare2 umfangreiche Suchmöglichkeiten:

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

Laufzeit-Speicheranalyse

r2frida bietet eine leistungsstarke Alternative zur Inspektion des Speichers einer App in Echtzeit, ohne dass ein Speicherauszug erforderlich ist. Dieses Tool ermöglicht die Ausführung von Suchbefehlen direkt im laufenden Speicher der Anwendung:

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

Fehlerhafte Kryptografie

Schlechte Schlüsselverwaltungsprozesse

Einige Entwickler speichern sensible Daten im lokalen Speicher und verschlüsseln sie mit einem im Code festgelegten/vorhersehbaren Schlüssel. Dies sollte vermieden werden, da durch Reverse Engineering Angreifer vertrauliche Informationen extrahieren könnten.

Verwendung unsicherer und/oder veralteter Algorithmen

Entwickler sollten keine veralteten Algorithmen zur Durchführung von Autorisierungsprüfungen, zum Speichern oder Senden von Daten verwenden. Einige dieser Algorithmen sind: RC4, MD4, MD5, SHA1... Wenn Hashes beispielsweise zum Speichern von Passwörtern verwendet werden, sollten hash-brute-force-resistente Hashes mit Salz verwendet werden.

Überprüfung

Die Hauptüberprüfungen, die durchgeführt werden müssen, sind das Auffinden von im Code festgelegten Passwörtern/Geheimnissen oder ob diese vorhersehbar sind, und ob der Code schwache Kryptografiealgorithmen verwendet.

Es ist interessant zu wissen, dass Sie einige Krypto-Bibliotheken automatisch mit objection überwachen können:

ios monitor crypt

Für weitere Informationen zu iOS-Kryptografie-APIs und Bibliotheken besuchen Sie https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography

Lokale Authentifizierung

Lokale Authentifizierung spielt eine entscheidende Rolle, insbesondere wenn es darum geht, den Zugriff an einem entfernten Endpunkt durch kryptografische Methoden abzusichern. Die Essenz hierbei ist, dass ohne ordnungsgemäße Implementierung lokale Authentifizierungsmechanismen umgangen werden können.

Apples Lokale Authentifizierungsframework und der Schlüsselbund bieten robuste APIs für Entwickler, um Benutzerauthentifizierungsdialoge zu erleichtern und geheime Daten sicher zu handhaben. Der Secure Enclave sichert die Fingerabdruck-ID für Touch ID, während Face ID auf Gesichtserkennung ohne Kompromittierung biometrischer Daten setzt.

Um Touch ID/Face ID zu integrieren, haben Entwickler zwei API-Optionen:

  • LocalAuthentication.framework für eine benutzerfreundliche Authentifizierung ohne Zugriff auf biometrische Daten.
  • Security.framework für den Zugriff auf Schlüsselbunddienste auf niedrigerer Ebene, um geheime Daten mit biometrischer Authentifizierung zu sichern. Verschiedene Open-Source-Wrapper vereinfachen den Zugriff auf den Schlüsselbund.

{% hint style="danger" %} Allerdings weisen sowohl LocalAuthentication.framework als auch Security.framework Sicherheitslücken auf, da sie hauptsächlich boolesche Werte zurückgeben, ohne Daten für Authentifizierungsprozesse zu übertragen, was sie anfällig für Umgehungen macht (siehe Don't touch me that way, von David Lindner et al). {% endhint %}

Implementierung der lokalen Authentifizierung

Um Benutzer zur Authentifizierung aufzufordern, sollten Entwickler die Methode evaluatePolicy innerhalb der Klasse LAContext verwenden und zwischen folgenden Optionen wählen:

  • deviceOwnerAuthentication: Fordert Touch ID oder Gerätepasscode an und schlägt fehl, wenn keines von beiden aktiviert ist.
  • deviceOwnerAuthenticationWithBiometrics: Fordert ausschließlich Touch ID an.

Eine erfolgreiche Authentifizierung wird durch einen booleschen Rückgabewert von evaluatePolicy angezeigt, was auf eine potenzielle Sicherheitslücke hinweist.

Lokale Authentifizierung mit Schlüsselbund

Die Implementierung der lokalen Authentifizierung in iOS-Apps beinhaltet die Verwendung von Schlüsselbund-APIs, um geheime Daten wie Authentifizierungstoken sicher zu speichern. Dieser Prozess stellt sicher, dass die Daten nur vom Benutzer über ihren Gerätepasscode oder die biometrische Authentifizierung wie Touch ID abgerufen werden können.

Der Schlüsselbund bietet die Möglichkeit, Elemente mit dem Attribut SecAccessControl festzulegen, das den Zugriff auf das Element einschränkt, bis der Benutzer sich erfolgreich über Touch ID oder Gerätepasscode authentifiziert. Diese Funktion ist entscheidend für die Verbesserung der Sicherheit.

Im Folgenden finden Sie Codebeispiele in Swift und Objective-C, die zeigen, wie ein String im Schlüsselbund gespeichert und abgerufen wird, wobei diese Sicherheitsfunktionen genutzt werden. Die Beispiele zeigen speziell, wie der Zugriffsschutz eingerichtet wird, um eine Touch ID-Authentifizierung zu erfordern und sicherzustellen, dass die Daten nur auf dem Gerät zugänglich sind, auf dem sie eingerichtet wurden, unter der Bedingung, dass ein Gerätepasscode konfiguriert ist.

{% tabs %} {% tab title="Swift" %}

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

Setting up the Environment

To start iOS application pentesting, you need a macOS system with Xcode installed. Xcode is the official IDE for developing iOS applications and comes with all the necessary tools for iOS pentesting.

Jailbreaking the Device

Jailbreaking an iOS device is often necessary for conducting in-depth security assessments. Tools like Checkra1n and Unc0ver can be used to jailbreak iOS devices.

Static Analysis

Static analysis involves examining the application's code without executing it. Tools like Hopper Disassembler, IDA Pro, and class-dump can be used for static analysis of iOS applications.

Dynamic Analysis

Dynamic analysis involves analyzing the application's behavior during runtime. Tools like Frida, Cycript, and objection can be used for dynamic analysis of iOS applications.

Network Traffic Analysis

Tools like Burp Suite, Charles Proxy, and mitmproxy can be used to intercept and analyze network traffic generated by iOS applications.

Runtime Manipulation

Runtime manipulation tools like Frida and Cycript can be used to hook into running processes, inspect and modify runtime behavior of iOS applications.

Data Storage Analysis

Tools like iExplorer and iMazing can be used to analyze the data stored by iOS applications on the device or in backups.

Reverse Engineering

Reverse engineering tools like Hopper Disassembler, IDA Pro, and Ghidra can be used to analyze and understand the inner workings of iOS applications.

Exploitation

Exploitation involves identifying and exploiting vulnerabilities in iOS applications to gain unauthorized access or perform malicious actions.

Reporting

A detailed report outlining the vulnerabilities discovered, exploitation steps, and recommendations for mitigation should be prepared at the end of the iOS application pentesting process.

References

{% 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
}

{% endtab %} {% endtabs %}

Jetzt können wir das gespeicherte Element aus dem Schlüsselbund anfordern. Die Schlüsselbunddienste zeigen dem Benutzer den Authentifizierungsdialog an und geben Daten oder nil zurück, abhängig davon, ob ein geeigneter Fingerabdruck bereitgestellt wurde oder nicht.

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

Setting up the Environment

To perform iOS application pentesting, you need a macOS system with Xcode installed. Xcode is an integrated development environment (IDE) containing a suite of software development tools developed by Apple for developing software for macOS, iOS, watchOS, and tvOS.

Tools Required

  1. Xcode: Required for building and running iOS applications on a simulator or a physical device.
  2. iOS Simulator: Comes bundled with Xcode and allows you to simulate iOS devices on your macOS system.
  3. Burp Suite: A proxy tool used for intercepting and modifying traffic between your iOS application and the backend server.
  4. Cycript: A developer's utility for in-depth examination and manipulation of running applications.
  5. Class-dump-z: Used for generating headers from Mach-O files.

Jailbroken vs. Non-JJailbroken Devices

When performing iOS application pentesting, it's essential to understand the differences between testing on jailbroken and non-jailbroken devices. Jailbroken devices provide more access and control, allowing for deeper analysis and testing. Non-jailbroken devices, on the other hand, represent the standard user environment and are useful for testing the application's security in a typical user scenario.

Common Vulnerabilities

Some common vulnerabilities to look for during iOS application pentesting include:

  • Insecure Data Storage: Check for sensitive data stored in plaintext or insecurely encrypted.
  • Insecure Communication: Look for the use of insecure communication channels that can be intercepted.
  • Improper Session Handling: Check for issues related to session management and authentication.
  • Client-Side Injection: Test for vulnerabilities like SQL injection or JavaScript injection.
  • Insecure Data Transmission: Ensure data is transmitted securely over the network.
  • Weak Server-Side Controls: Look for weaknesses in server-side controls that could be exploited.

Conclusion

iOS application pentesting requires a thorough understanding of the tools and techniques involved in testing the security of iOS applications. By setting up the right environment and using the appropriate tools, you can effectively identify and mitigate vulnerabilities in iOS applications.

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

Erkennung

Die Verwendung von Frameworks in einer App kann auch durch Analyse der Liste der gemeinsam genutzten dynamischen Bibliotheken der App-Binärdatei erkannt werden. Dies kann mit otool durchgeführt werden:

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

Wenn LocalAuthentication.framework in einer App verwendet wird, wird die Ausgabe beide der folgenden Zeilen enthalten (denken Sie daran, dass LocalAuthentication.framework Security.framework im Hintergrund verwendet):

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

Wenn Security.framework verwendet wird, wird nur der zweite angezeigt.

Umgehung des Local Authentication Frameworks

Einwand

Durch die Objection Biometrics Bypass, zu finden auf dieser GitHub-Seite, steht eine Technik zur Überwindung des LocalAuthentication-Mechanismus zur Verfügung. Der Kern dieses Ansatzes besteht darin, Frida zu nutzen, um die Funktion evaluatePolicy zu manipulieren, um sicherzustellen, dass sie konsequent ein True-Ergebnis liefert, unabhängig vom tatsächlichen Authentifizierungserfolg. Dies ist besonders nützlich, um fehlerhafte biometrische Authentifizierungsprozesse zu umgehen.

Um diese Umgehung zu aktivieren, wird der folgende Befehl verwendet:

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

Dieser Befehl löst eine Sequenz aus, bei der Objection eine Aufgabe registriert, die das Ergebnis der evaluatePolicy-Prüfung effektiv auf True ändert.

Frida

Ein Beispiel für die Verwendung von evaluatePolicy aus der DVIA-v2-Anwendung:

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

Um die Umgehung der lokalen Authentifizierung zu erreichen, wird ein Frida-Skript geschrieben. Dieses Skript zielt auf die evaluatePolicy-Überprüfung ab, indem es den Rückruf abfängt, um sicherzustellen, dass er success=1 zurückgibt. Durch Ändern des Verhaltens des Rückrufs wird die Authentifizierungsprüfung effektiv umgangen.

Das folgende Skript wird injiziert, um das Ergebnis der Methode evaluatePolicy zu ändern. Es ändert das Ergebnis des Rückrufs so, dass immer Erfolg angezeigt wird.

// 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!");
}

Um das Frida-Skript einzuspeisen und die biometrische Authentifizierung zu umgehen, wird der folgende Befehl verwendet:

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

Empfindliche Funktionalitätsexposition durch IPC

Benutzerdefinierte URI-Handler / Deeplinks / Benutzerdefinierte Schemata

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

Universelle Links

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

UIActivity Sharing

{% 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 %}

App-Erweiterungen

{% 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 %}

Serialisierung und Codierung

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

Netzwerkkommunikation

Es ist wichtig zu überprüfen, dass keine Kommunikation ohne Verschlüsselung erfolgt und dass die Anwendung das TLS-Zertifikat des Servers korrekt validiert.
Um diese Art von Problemen zu überprüfen, können Sie einen Proxy wie Burp verwenden:

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

Hostnamenprüfung

Ein häufiges Problem bei der Validierung des TLS-Zertifikats besteht darin, zu überprüfen, ob das Zertifikat von einer vertrauenswürdigen CA signiert wurde, aber nicht zu überprüfen, ob der Hostname des Zertifikats mit dem aufgerufenen Hostnamen übereinstimmt.
Um dieses Problem mit Burp zu überprüfen, können Sie nach dem Vertrauen in die Burp-CA auf dem iPhone ein neues Zertifikat mit Burp für einen anderen Hostnamen erstellen und verwenden. Wenn die Anwendung immer noch funktioniert, ist etwas verwundbar.

Zertifikats-Pinning

Wenn eine Anwendung SSL-Pinning korrekt verwendet, funktioniert die Anwendung nur, wenn das Zertifikat das erwartete ist. Beim Testen einer Anwendung kann dies ein Problem sein, da Burp sein eigenes Zertifikat ausstellt.
Um diesen Schutz auf einem jailbroken Gerät zu umgehen, können Sie die Anwendung SSL Kill Switch installieren oder Burp Mobile Assistant installieren.

Sie können auch objection's ios sslpinning disable verwenden.

Sonstiges

  • In /System/Library finden Sie die auf dem Telefon installierten Frameworks, die von Systemanwendungen verwendet werden.
  • Die vom Benutzer aus dem App Store installierten Anwendungen befinden sich in /User/Applications.
  • Und das /User/Library enthält Daten, die von Anwendungen auf Benutzerebene gespeichert wurden.
  • Sie können auf /User/Library/Notes/notes.sqlite zugreifen, um die in der Anwendung gespeicherten Notizen zu lesen.
  • Im Ordner einer installierten Anwendung (/User/Applications/<APP ID>/) finden Sie einige interessante Dateien:
    • iTunesArtwork: Das vom der App verwendete Symbol
    • iTunesMetadata.plist: Informationen zur App, die im App Store verwendet werden
    • /Library/*: Enthält die Einstellungen und den Cache. In /Library/Cache/Snapshots/* finden Sie den vor dem Hintergrundsenden der Anwendung durchgeführten Snapshot.

Hot Patching/Erzwungenes Update

Die Entwickler können alle Installationen ihrer App sofort remote patchen, ohne die Anwendung erneut im App Store einreichen und auf die Genehmigung warten zu müssen.
Zu diesem Zweck wird in der Regel JSPatch** verwendet.** Es gibt jedoch auch andere Optionen wie Siren und react-native-appstore-version-checker.
Dies ist ein gefährlicher Mechanismus, der von bösartigen Drittanbieter-SDKs missbraucht werden könnte. Daher wird empfohlen, zu überprüfen, welche Methode zum automatischen Aktualisieren (falls vorhanden) verwendet wird, und diese zu testen. Sie könnten versuchen, eine frühere Version der App herunterzuladen, um dies zu überprüfen.

Drittanbieter

Eine bedeutende Herausforderung bei Drittanbieter-SDKs ist das Fehlen einer granularen Kontrolle über ihre Funktionalitäten. Entwickler stehen vor der Wahl: Entweder integrieren sie das SDK und akzeptieren alle seine Funktionen, einschließlich potenzieller Sicherheitslücken und Datenschutzbedenken, oder verzichten vollständig auf dessen Vorteile. Oft können Entwickler Sicherheitslücken in diesen SDKs nicht selbst beheben. Darüber hinaus können einige SDKs, wenn sie das Vertrauen der Community gewinnen, möglicherweise Malware enthalten.

Die von Drittanbieter-SDKs bereitgestellten Dienste können das Tracking des Nutzerverhaltens, die Anzeige von Werbung oder die Verbesserung des Nutzererlebnisses umfassen. Dies birgt jedoch ein Risiko, da Entwickler möglicherweise nicht vollständig über den von diesen Bibliotheken ausgeführten Code informiert sind, was zu potenziellen Datenschutz- und Sicherheitsrisiken führen kann. Es ist entscheidend, die Informationen, die mit Drittanbieterdiensten geteilt werden, auf das Notwendigste zu beschränken und sicherzustellen, dass keine sensiblen Daten preisgegeben werden.

Die Implementierung von Drittanbieterdiensten erfolgt in der Regel in zwei Formen: als eigenständige Bibliothek oder als vollständiges SDK. Um die Privatsphäre der Benutzer zu schützen, sollten alle mit diesen Diensten geteilten Daten anonymisiert werden, um die Offenlegung personenbezogener Informationen (PII) zu verhindern.

Um die Bibliotheken zu identifizieren, die eine Anwendung verwendet, kann das otool-Befehl verwendet werden. Dieses Tool sollte gegen die Anwendung und jede gemeinsam genutzte Bibliothek ausgeführt werden, um zusätzliche Bibliotheken zu entdecken.

otool -L <application_path>

Verweise & Weitere Ressourcen


Verwenden Sie Trickest, um mühelos Workflows zu erstellen und zu automatisieren, unterstützt von den weltweit fortschrittlichsten Community-Tools.
Heute Zugriff erhalten:

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

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen: