German - Ht
HackTricks Training Twitter Linkedin Sponsor

iOS Pentesting

Verwenden Sie Trickest, um einfach Workflows zu erstellen und zu automatisieren, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden. Zugang heute erhalten:

LogoAutomate OffSec, EASM, and Custom Security Processes | Trickest
Support HackTricks

iOS Grundlagen

iOS Basics

Testumgebung

Auf dieser Seite finden Sie Informationen über den iOS-Simulator, Emulatoren und Jailbreaking:

iOS Testing Environment

Erste Analyse

Grundlegende iOS-Testoperationen

Während des Tests werden mehrere Operationen vorgeschlagen (Verbinden mit dem Gerät, Lesen/Schreiben/Hochladen/Herunterladen von Dateien, Verwendung einiger Tools...). Wenn Sie also nicht wissen, wie Sie eine dieser Aktionen ausführen, lesen Sie bitte die Seite:

iOS Basic Testing Operations

Für die folgenden Schritte sollte die App installiert sein und die IPA-Datei der Anwendung sollte bereits vorliegen. Lesen Sie die Grundlegenden iOS-Testoperationen Seite, um zu erfahren, wie Sie dies tun.

Grundlegende statische Analyse

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

Identifizierung von Schutzmaßnahmen, die im Binärformat vorhanden sind:

  • PIE (Position Independent Executable): Wenn aktiviert, wird die Anwendung jedes Mal an einer zufälligen Speicheradresse geladen, was es schwieriger macht, ihre ursprüngliche Speicheradresse vorherzusagen.

otool -hv <app-binary> | grep PIE   # Es sollte das PIE-Flag enthalten

  • Stack Canaries: Um die Integrität des Stacks zu validieren, wird ein „Canary“-Wert auf den Stack gelegt, bevor eine Funktion aufgerufen wird, und nach dem Ende der Funktion erneut validiert.

otool -I -v <app-binary> | grep stack_chk   # Es sollte die Symbole: stack_chk_guard und stack_chk_fail enthalten

  • ARC (Automatic Reference Counting): Um häufige Speicherbeschädigungsfehler zu verhindern

otool -I -v <app-binary> | grep objc_release   # Es sollte das _objc_release-Symbol enthalten

  • Verschlüsselte Binärdatei: Die Binärdatei 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 Hash-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

Überprüfen Sie die dynamische Analyse, die MobSF durchführt. Sie müssen durch die verschiedenen Ansichten navigieren und mit ihnen interagieren, aber es wird mehrere Klassen hooken, während es andere Dinge tut, und einen Bericht erstellen, sobald Sie fertig sind.

Auflistung installierter Apps

Verwenden Sie den Befehl frida-ps -Uai, um die Bundle-ID 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

Lernen Sie, wie man die Komponenten der Anwendung enumeriert und wie man einfach Methoden und Klassen mit Objection hookt:

iOS Hooking With Objection

IPA-Struktur

Die Struktur einer IPA-Datei ist im Wesentlichen die eines zipped Pakets. Durch Umbenennen der Erweiterung in .zip kann sie dekomprimiert werden, um ihren Inhalt zu enthüllen. Innerhalb dieser Struktur stellt ein Bundle eine vollständig verpackte Anwendung dar, die bereit für die Installation ist. Darin finden Sie ein Verzeichnis mit dem Namen <NAME>.app, das die Ressourcen der Anwendung kapselt.

  • Info.plist: Diese Datei enthält spezifische Konfigurationsdetails der Anwendung.

  • _CodeSignature/: Dieses Verzeichnis enthält eine plist-Datei, die eine Signatur enthält und die Integrität aller Dateien im Bundle sicherstellt.

  • Assets.car: Ein komprimiertes Archiv, das Asset-Dateien wie Icons speichert.

  • Frameworks/: Dieser Ordner beherbergt 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: Es wird verwendet, um die permanenten Daten Ihrer Anwendung für die Offline-Nutzung zu speichern, temporäre Daten zwischenzuspeichern und eine Rückgängig-Funktionalität für Ihre App auf einem einzelnen Gerät hinzuzufügen. Um Daten über mehrere Geräte in einem einzigen iCloud-Konto zu synchronisieren, spiegelt Core Data automatisch Ihr Schema in einen CloudKit-Container.

  • PkgInfo: Die PkgInfo-Datei ist eine alternative Möglichkeit, die Typ- und 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 für die 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 für die Optimierung der Anwendungsleistung und die Reduzierung ihrer Gesamtgröße ist.

  • Frameworks und PlugIns: Diese Verzeichnisse unterstreichen die Modularität von iOS-Anwendungen, die es Entwicklern ermöglichen, wiederverwendbare Codebibliotheken (Frameworks/) einzuschließen und die Funktionalität der App zu erweitern (PlugIns/).

  • Lokalisierung: Die Struktur unterstützt mehrere Sprachen und erleichtert die globale Reichweite der Anwendung, indem Ressourcen für spezifische Sprachpakete enthalten sind.

Info.plist

Die Info.plist dient als Grundpfeiler für iOS-Anwendungen und kapselt wichtige Konfigurationsdaten in Form von Schlüssel-Wert-Paaren. Diese Datei ist eine Voraussetzung nicht nur für Anwendungen, sondern auch für App-Erweiterungen und Frameworks, die darin gebündelt sind. Sie ist entweder im XML- oder im Binärformat strukturiert und enthält kritische Informationen, die von App-Berechtigungen bis zu Sicherheitskonfigurationen reichen. Für eine detaillierte Erkundung der verfügbaren Schlüssel kann auf die Apple Developer Documentation verwiesen werden.

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 (verfügbar nativ in Versionen 10.2 und später) oder plistutil auf Linux erreicht werden. Die Befehle zur Konvertierung sind 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 wie App-Berechtigungsstrings (UsageDescription), benutzerdefinierte URL-Schemata (CFBundleURLTypes) und Konfigurationen für App Transport Security (NSAppTransportSecurity). Diese Einträge, zusammen mit anderen wie exportierten/importierten benutzerdefinierten 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

Im iOS-Umfeld sind Verzeichnisse speziell für Systemanwendungen und vom Benutzer installierte Anwendungen vorgesehen. Systemanwendungen befinden sich im Verzeichnis /Applications, während vom Benutzer installierte Apps unter /var/mobile/containers/Data/Application/ abgelegt werden. Diese Anwendungen erhalten eine eindeutige Kennung, die als 128-Bit UUID bekannt ist, was die manuelle Lokalisierung des App-Ordners aufgrund der Zufälligkeit der Verzeichnisnamen erschwert.

Da Anwendungen in iOS sandboxed sein müssen, hat jede App auch einen Ordner innerhalb von $HOME/Library/Containers mit der CFBundleIdentifier der App als Ordnernamen.

Beide Ordner (Daten- und Containerordner) enthalten jedoch die Datei .com.apple.mobile_container_manager.metadata.plist, die beide Dateien im Schlüssel MCMetadataIdentifier verknüpft.

Um die Entdeckung des Installationsverzeichnisses einer vom Benutzer installierten App zu erleichtern, bietet das objection tool einen nützlichen Befehl, env. Dieser Befehl zeigt detaillierte Verzeichnisinformationen für die betreffende App an. Nachfolgend ein Beispiel, wie man diesen Befehl verwendet:

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 innerhalb von /private/var/containers mit dem Befehl find 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 offene Dateien aufzulisten, was Einblicke in die aktiven Verzeichnispfade der Anwendung bietet:

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

Bundle-Verzeichnis:

  • AppName.app

  • Dies ist das Anwendungsbundle, wie zuvor im IPA gesehen, es enthält essentielle Anwendungsdaten, statische Inhalte sowie die kompilierte Binärdatei der Anwendung.

  • Dieses Verzeichnis ist für Benutzer sichtbar, aber Benutzer können nicht darin schreiben.

  • Inhalte in diesem Verzeichnis werden nicht gesichert.

  • Der Inhalt dieses Ordners wird verwendet, um die Code-Signatur zu validieren.

Datenverzeichnis:

  • Documents/

  • Enthält alle vom Benutzer generierten Daten. Der Endbenutzer der Anwendung initiiert die Erstellung dieser Daten.

  • Sichtbar für Benutzer und Benutzer können darin schreiben.

  • Inhalte in diesem Verzeichnis werden gesichert.

  • Die App kann Pfade deaktivieren, indem sie NSURLIsExcludedFromBackupKey setzt.

  • Library/

  • Enthält alle Dateien, die nicht benutzerspezifisch sind, wie Caches, Einstellungen, Cookies und Konfigurationsdateien im Property List (plist)-Format.

  • iOS-Apps verwenden normalerweise die Unterverzeichnisse Application Support und Caches, aber die App kann benutzerdefinierte Unterverzeichnisse erstellen.

  • Library/Caches/

  • Enthält semi-permanente zwischengespeicherte Dateien.

  • Unsichtbar für Benutzer und Benutzer können nicht darin schreiben.

  • Inhalte in diesem Verzeichnis werden nicht gesichert.

  • Das Betriebssystem kann die Dateien dieses Verzeichnisses automatisch löschen, wenn die App nicht läuft und der Speicherplatz knapp wird.

  • Library/Application Support/

  • Enthält persistente Dateien, die zum Ausführen der App erforderlich sind.

  • Unsichtbar für Benutzer und Benutzer können nicht darin schreiben.

  • Inhalte in diesem Verzeichnis werden gesichert.

  • Die App kann Pfade deaktivieren, indem sie NSURLIsExcludedFromBackupKey setzt.

  • Library/Preferences/

  • Wird verwendet, um Eigenschaften zu speichern, die auch nach einem Neustart der Anwendung bestehen bleiben können.

  • Informationen werden unverschlüsselt im Anwendungs-Sandbox in einer plist-Datei namens [BUNDLE_ID].plist gespeichert.

  • Alle Schlüssel/Wert-Paare, die mit NSUserDefaults gespeichert werden, sind in dieser Datei zu finden.

  • tmp/

  • Verwenden Sie dieses Verzeichnis, um temporäre Dateien zu schreiben, die zwischen den App-Starts nicht bestehen bleiben müssen.

  • Enthält nicht-persistente zwischengespeicherte Dateien.

  • Unsichtbar für Benutzer.

  • Inhalte in diesem Verzeichnis werden 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 Anwendungsbundle (.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

Binary Reversing

Im <application-name>.app-Ordner 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

Sehen Sie nach, ob es eine Ausgabe für gibt:

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

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

Allerdings sind die besten Optionen, um die Binärdatei zu disassemblieren: Hopper und IDA.

Verwenden Sie Trickest, um einfach Workflows zu erstellen und zu automatisieren, die von den fortschrittlichsten Community-Tools der Welt unterstützt werden. Zugang heute erhalten:

LogoAutomate OffSec, EASM, and Custom Security Processes | Trickest

Datenspeicherung

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

iOS Basics

Die folgenden Orte zur Speicherung von Informationen sollten unmittelbar nach der Installation der Anwendung, nach Überprüfung aller Funktionen der Anwendung und sogar nach dem Abmelden von einem Benutzer und dem Anmelden bei einem anderen überprüft werden. Das Ziel ist es, unprotected sensitive information der Anwendung (Passwörter, Tokens), des aktuellen Benutzers und von zuvor angemeldeten Benutzern zu finden.

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 Sie manchmal sensible Informationen in diesen Dateien finden. 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 gebräuchlichste Weg, um Daten in plist-Dateien zu persistieren, ist die Verwendung von NSUserDefaults. Diese plist-Datei wird im App-Sandbox unter Library/Preferences/<appBundleID>.plist gespeichert.

Die NSUserDefaults Klasse bietet eine programmgesteuerte Schnittstelle zur Interaktion mit dem Standardsystem. Das Standardsystem ermöglicht es einer Anwendung, ihr Verhalten gemäß Benutzereinstellungen anzupassen. Daten, die von NSUserDefaults gespeichert werden, können im Anwendungsbundle angezeigt werden. Diese Klasse speichert Daten in einer plist-Datei, ist jedoch für die Verwendung mit kleinen Datenmengen gedacht.

Diese Daten können nicht mehr direkt über einen vertrauenswürdigen Computer zugegriffen werden, können jedoch durch das Durchführen eines Backups abgerufen werden.

Sie können die Informationen, die mit NSUserDefaults gespeichert wurden, mit objections ios nsuserdefaults get dumpen.

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

find ./ -name "*.plist"

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

Für macOS-Benutzer: Verwenden Sie den Befehl plutil. Es ist 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, plist-Dateien direkt zu konvertieren:

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 seine Daten standardmäßig nicht. Es kann jedoch eine zusätzliche Verschlüsselungsschicht zu CoreData hinzugefügt werden. Weitere Details finden Sie im GitHub Repo.

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

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

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

NSManagedObjectContext *context =[appDelegate managedObjectContext];

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

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

YapDatabase

YapDatabase ist ein Schlüssel/Wert-Speicher, der auf SQLite basiert. Da die Yap-Datenbanken SQLite-Datenbanken sind, können Sie sie mit dem im vorherigen Abschnitt vorgeschlagenen Befehl finden.

Andere SQLite-Datenbanken

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

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

Firebase Real-Time-Datenbanken

Entwickler können Daten speichern und synchronisieren innerhalb einer NoSQL, cloud-hosted Datenbank über Firebase Real-Time-Datenbanken. Die Daten werden im JSON-Format gespeichert und in Echtzeit mit allen verbundenen Clients synchronisiert.

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

Firebase Database

Realm-Datenbanken

Realm Objective-C und Realm Swift bieten eine leistungsstarke Alternative zur Datenspeicherung, die von Apple nicht bereitgestellt wird. Standardmäßig speichern sie Daten unverschlüsselt, 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, kann man Befehle wie verwenden:

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 die Verschlüsselung innerhalb einer Realm-Datenbank zu implementieren, kann der folgende Code-Snippet 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 eine leichte und eingebettete Datenbank-Engine beschrieben, die den dokumentenorientierten (NoSQL) Ansatz verfolgt. Entwickelt für iOS und macOS, bietet es die Möglichkeit, Daten nahtlos zu synchronisieren.

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

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

Cookies

iOS speichert die Cookies der Apps in der Library/Cookies/cookies.binarycookies innerhalb des Ordners jeder App. Entwickler entscheiden sich jedoch manchmal, sie im Keychain zu speichern, da die erwähnte Cookie-Datei in Backups zugänglich ist.

Um die Cookie-Datei zu inspizieren, können Sie dieses Python-Skript verwenden oder objections ios cookies get 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 Caching dieser Daten zu deaktivieren, da es sensible Informationen in der Anfrage oder Antwort enthalten kann. Die folgende Liste zeigt verschiedene Möglichkeiten, dies zu erreichen:

  1. Es wird empfohlen, zwischengespeicherte Antworten nach dem Logout zu entfernen. Dies kann mit der von Apple bereitgestellten Methode removeAllCachedResponses erfolgen. 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 nutzen müssen, wird empfohlen, einfach die .ephemeral Konfigurationseigenschaft von URLSession zu verwenden, die das Speichern von Cookies und Caches deaktiviert.

Apple-Dokumentation:

Ein temporäres Sitzungs-Konfigurationsobjekt ist ähnlich wie ein Standard-Sitzungs-Konfigurationsobjekt (siehe Standard), mit dem Unterschied, dass das entsprechende Sitzungsobjekt keine Caches, Anmeldeinformationen oder andere sitzungsbezogene Daten auf der Festplatte speichert. Stattdessen werden sitzungsbezogene Daten im RAM gespeichert. Das einzige Mal, dass eine temporäre Sitzung Daten auf die Festplatte schreibt, ist, wenn Sie ihr sagen, den Inhalt einer URL in eine Datei zu schreiben. 3. Der Cache kann auch deaktiviert werden, indem die Cache-Richtlinie auf .notAllowed gesetzt wird. Dadurch wird das Speichern des Caches in irgendeiner Form, entweder im Speicher oder auf der Festplatte, deaktiviert.

Snapshots

Immer wenn Sie die Home-Taste drücken, nimmt iOS einen Snapshot des aktuellen Bildschirms auf, um den Übergang zur Anwendung viel reibungsloser zu gestalten. Wenn jedoch sensible Daten auf dem aktuellen Bildschirm vorhanden sind, werden sie im Bild gespeichert (das über Neustarts hinaus besteht). Dies sind die Snapshots, auf die Sie auch zugreifen können, indem Sie doppelt auf den Home-Bildschirm tippen, um zwischen Apps zu wechseln.

Es sei denn, das iPhone ist jailbreaked, muss der Angreifer Zugriff auf das Gerät entblockt haben, um diese Screenshots zu sehen. Standardmäßig wird der letzte Snapshot im Sandbox der Anwendung im Library/Caches/Snapshots/ oder Library/SplashBoard/Snapshots-Ordner gespeichert (vertrauenswürdige Computer können ab iOS 7.0 nicht auf das Dateisystem zugreifen).

Eine Möglichkeit, dieses unerwünschte Verhalten zu verhindern, besteht darin, einen leeren Bildschirm anzuzeigen oder die sensiblen Daten zu entfernen, bevor der Snapshot mit der Funktion ApplicationDidEnterBackground() aufgenommen wird.

Die folgende ist eine Beispiel-Maßnahme, 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()
}

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

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

Keychain

Für den Zugriff auf und die Verwaltung des iOS-Keychains sind Tools wie Keychain-Dumper verfügbar, die für jailbroken Geräte geeignet sind. Darüber hinaus bietet Objection den Befehl ios keychain dump für ähnliche Zwecke.

Speichern von Anmeldeinformationen

Die NSURLCredential-Klasse ist ideal, um sensible Informationen direkt im Keychain zu speichern, wodurch die Notwendigkeit für NSUserDefaults oder andere Wrapper umgangen wird. 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 Tastatur-Cache

Mit iOS 8.0 und höher können Benutzer benutzerdefinierte Tastaturerweiterungen installieren, die unter Einstellungen > Allgemein > Tastatur > Tastaturen verwaltet werden können. Während diese Tastaturen erweiterte Funktionen bieten, besteht das Risiko von Tastenanschlagprotokollierung und der Übertragung von Daten an externe Server, obwohl die Benutzer über Tastaturen informiert werden, die Netzwerkzugriff benötigen. Apps können und sollten die Verwendung von benutzerdefinierten Tastaturen für die Eingabe sensibler Informationen einschränken.

Sicherheitsempfehlungen:

  • Es wird empfohlen, Drittanbieter-Tastaturen zur Verbesserung der Sicherheit zu deaktivieren.

  • Seien Sie sich der Autokorrektur- und Auto-Vervollständigungsfunktionen der Standard-iOS-Tastatur bewusst, 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 von Netzwerkverkehr kann aufdecken, ob eine benutzerdefinierte Tastatur Tastenanschläge remote überträgt.

Verhindern von Textfeld-Caching

Das UITextInputTraits-Protokoll bietet Eigenschaften zur Verwaltung der Autokorrektur und der sicheren Texteingabe, die entscheidend sind, um das Caching sensibler Informationen zu verhindern. Zum Beispiel kann das Deaktivieren der Autokorrektur und das Aktivieren der sicheren Texteingabe erreicht werden mit:

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

Zusätzlich sollten Entwickler sicherstellen, dass Textfelder, insbesondere solche zur Eingabe sensibler Informationen wie Passwörter und PINs, das Caching deaktivieren, indem sie autocorrectionType auf UITextAutocorrectionTypeNo und secureTextEntry auf YES setzen.

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

Logs

Das Debuggen von Code beinhaltet oft die Verwendung von Logging. Es besteht ein Risiko, da Logs sensible Informationen enthalten können. Früher, in iOS 6 und früheren Versionen, waren Logs für alle Apps zugänglich, was ein Risiko für die Offenlegung sensibler Daten darstellte. Jetzt sind Anwendungen darauf beschränkt, nur auf ihre eigenen Logs zuzugreifen.

Trotz dieser Einschränkungen kann ein Angreifer mit physischem Zugriff auf ein entsperrtes Gerät dies ausnutzen, indem er das Gerät mit einem Compu