iOS Pentesting

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

iOS Basics

iOS Basics

Testing Environment

In questa pagina puoi trovare informazioni su iOS simulator, emulators e jailbreaking:

iOS Testing Environment

Initial Analysis

Basic iOS Testing Operations

Durante i test verranno suggerite diverse operazioni (connettersi al dispositivo, leggere/scrivere/upload/download di file, usare alcuni strumenti…). Pertanto, se non sai come eseguire una di queste azioni, per favore inizia leggendo la pagina:

iOS Basic Testing Operations

Tip

Per i passaggi seguenti l’app dovrebbe essere installata sul dispositivo e dovrebbe essere già stato ottenuto il IPA file dell’applicazione.
Leggi la pagina Basic iOS Testing Operations per imparare come fare.

Basic Static Analysis

Alcuni decompilatori interessanti per iOS - IPA files:

È raccomandato usare lo strumento MobSF per eseguire un’analisi statica automatica del file IPA.

Identificazione delle protezioni presenti nel binario:

  • PIE (Position Independent Executable): Quando abilitato, l’applicazione viene caricata in un indirizzo di memoria casuale ogni volta che viene avviata, rendendo più difficile prevedere il suo indirizzo iniziale di memoria.
otool -hv <app-binary> | grep PIE   # It should include the PIE flag
  • Stack Canaries: Per validare l’integrità dello stack, un valore “canary” viene posizionato nello stack prima di chiamare una funzione e viene validato nuovamente quando la funzione termina.
otool -I -v <app-binary> | grep stack_chk   # It should include the symbols: stack_chk_guard and stack_chk_fail
  • ARC (Automatic Reference Counting): Per prevenire comuni vulnerabilità di corruzione della memoria
otool -I -v <app-binary> | grep objc_release   # It should include the _objc_release symbol
  • Encrypted Binary: Il binario dovrebbe essere criptato
otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # The cryptid should be 1

Identificazione di Funzioni Sensibili/Insicure

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

# On linux
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"
  • Insecure Random Functions
# On the iOS device
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# On linux
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"
  • Insecure ‘Malloc’ Function
# On the iOS device
otool -Iv <app> | grep -w "_malloc"

# On linux
grep -iER "_malloc"
  • Insecure and Vulnerable Functions
# On the iOS device
otool -Iv <app> | grep -w "_gets"
otool -Iv <app> | grep -w "_memcpy"
otool -Iv <app> | grep -w "_strncpy"
otool -Iv <app> | grep -w "_strlen"
otool -Iv <app> | grep -w "_vsnprintf"
otool -Iv <app> | grep -w "_sscanf"
otool -Iv <app> | grep -w "_strtok"
otool -Iv <app> | grep -w "_alloca"
otool -Iv <app> | grep -w "_sprintf"
otool -Iv <app> | grep -w "_printf"
otool -Iv <app> | grep -w "_vsprintf"

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

Common Jailbreak detection methods

  • File System Checks: Cerca la presenza di file e directory comuni dei jailbreak, come /Applications/Cydia.app o /Library/MobileSubstrate/MobileSubstrate.dylib.
  • Sandbox Violations: Prova ad accedere ad aree del file system ristrette, che dovrebbero essere bloccate sui dispositivi non-jailbroken.
  • API Checks: Verifica se è possibile usare chiamate proibite come fork() per creare un processo figlio o system() per vedere se /bin/sh esiste.
  • Process Checks: Monitora la presenza di processi noti legati al jailbreak, come Cydia, Substrate, o ssh.
  • Kernel Exploits: Controlla la presenza di exploit del kernel comunemente usati nei jailbreak.
  • Environment Variables: Ispeziona le variabili d’ambiente per segnali di jailbreak, come DYLD_INSERT_LIBRARIES.
  • Libraries Check: Controlla le librerie caricate nel processo dell’app.
  • Check schemes: Come canOpenURL(URL(string: "cydia://")).

Common Anti-Debugging detection methods

  • Check for Debugger Presence: Usa sysctl o altri metodi per verificare se un debugger è attaccato.
  • Anti-Debugging APIs: Cerca chiamate ad API anti-debugging come ptrace o SIGSTOP come ptrace(PT_DENY_ATTACH, 0, 0, 0).
  • Timing Checks: Misura il tempo impiegato per certe operazioni e cerca discrepanze che possano indicare un debug.
  • Memory Checks: Ispeziona la memoria alla ricerca di artefatti o modifiche note dei debugger.
  • Environment Variables: Controlla variabili d’ambiente che possano indicare una sessione di debugging.
  • Mach Ports: Rileva se mach exception ports sono usati da debugger.

Basic Dynamic Analysis

Dai un’occhiata all’analisi dinamica che MobSF esegue. Dovrai navigare tra le diverse visualizzazioni e interagire con esse, ma farà hooking di diverse classi mentre esegui altre azioni e preparerà un report una volta terminato.

Listing Installed Apps

Usa il comando frida-ps -Uai per determinare il bundle identifier delle app installate:

$ 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

Basic Enumeration & Hooking

Impara come enumerate i componenti dell’applicazione e come hook metodi e classi facilmente con objection:

iOS Hooking With Objection

IPA Structure

La struttura di un IPA file è essenzialmente quella di un zipped package. Rinominando la sua estensione in .zip, può essere decompressa per rivelarne il contenuto. All’interno di questa struttura, un Bundle rappresenta un’applicazione completamente confezionata pronta per l’installazione. Al suo interno troverai una directory chiamata <NAME>.app, che racchiude le risorse dell’applicazione.

  • Info.plist: Questo file contiene i dettagli di configurazione specifici dell’applicazione.
  • _CodeSignature/: Questa directory include un file plist che contiene una signature, garantendo l’integrità di tutti i file nel bundle.
  • Assets.car: Un archivio compresso che memorizza file di asset come le icone.
  • Frameworks/: Questa cartella ospita le librerie native dell’applicazione, che possono essere sotto forma di file .dylib o .framework.
  • PlugIns/: Qui possono essere incluse estensioni dell’applicazione, note come file .appex, anche se non sono sempre presenti. * Core Data: Viene utilizzato per salvare i dati permanenti della tua applicazione per l’uso offline, per cache di dati temporanei e per aggiungere funzionalità di undo alla tua app su un singolo dispositivo. Per sincronizzare i dati su più dispositivi con lo stesso account iCloud, Core Data replica automaticamente il tuo schema in un container CloudKit.
  • PkgInfo: Il file PkgInfo è un modo alternativo per specificare i codici di tipo e creator della tua applicazione o del tuo bundle.
  • en.lproj, fr.proj, Base.lproj: Sono i pacchetti di lingua che contengono risorse per quelle specifiche lingue, e una risorsa predefinita nel caso in cui una lingua non sia supportata.
  • Security: La directory _CodeSignature/ svolge un ruolo critico nella sicurezza dell’app verificando l’integrità di tutti i file inclusi nel bundle tramite firme digitali.
  • Asset Management: Il file Assets.car utilizza la compressione per gestire in modo efficiente gli asset grafici, fondamentale per ottimizzare le prestazioni dell’applicazione e ridurne la dimensione complessiva.
  • Frameworks and PlugIns: Queste directory sottolineano la modularità delle applicazioni iOS, permettendo agli sviluppatori di includere librerie di codice riutilizzabili (Frameworks/) ed estendere le funzionalità dell’app (PlugIns/).
  • Localization: La struttura supporta più lingue, facilitando la diffusione globale dell’app includendo risorse per pacchetti linguistici specifici.

Info.plist

L’Info.plist funge da pietra angolare per le applicazioni iOS, racchiudendo dati di configurazione chiave sotto forma di coppie key-value. Questo file è obbligatorio non solo per le applicazioni ma anche per le estensioni app e i framework inclusi nel bundle. È strutturato in formato XML o binario e contiene informazioni critiche che vanno dalle autorizzazioni dell’app alle configurazioni di sicurezza. Per un’esplorazione dettagliata delle chiavi disponibili, è possibile fare riferimento alla Apple Developer Documentation.

Per chi vuole lavorare con questo file in un formato più accessibile, la conversione in XML può essere ottenuta facilmente usando plutil su macOS (disponibile nativamente su versioni 10.2 e successive) o plistutil su Linux. I comandi per la conversione sono i seguenti:

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

Tra la miriade di informazioni che il file Info.plist può rivelare, voci rilevanti includono le stringhe di permessi dell’app (UsageDescription), gli schemi URL personalizzati (CFBundleURLTypes) e le configurazioni per App Transport Security (NSAppTransportSecurity). Queste voci, insieme ad altre come i tipi di documento personalizzati esportati/importati (UTExportedTypeDeclarations / UTImportedTypeDeclarations), possono essere individuate facilmente ispezionando il file o usando un semplice comando grep:

$ grep -i <keyword> Info.plist

Percorsi dei dati

Nell’ambiente iOS, le directory sono designate specificamente per le applicazioni di sistema e le applicazioni installate dall’utente. Le applicazioni di sistema risiedono nella directory /Applications, mentre le app installate dall’utente sono collocate sotto /var/mobile/containers/Data/Application/. A queste applicazioni viene assegnato un identificatore univoco noto come 128-bit UUID, il che rende difficile individuare manualmente la cartella di un’app a causa dell’aleatorietà dei nomi delle directory.

Warning

Poiché le applicazioni in iOS devono essere eseguite in un ambiente sandbox, ogni app avrà anche una cartella all’interno di $HOME/Library/Containers con il CFBundleIdentifier dell’app come nome della cartella.

Tuttavia, entrambe le cartelle (cartelle data & container) contengono il file .com.apple.mobile_container_manager.metadata.plist che collega entrambe le cartelle nella chiave MCMetadataIdentifier).

Per facilitare la scoperta della directory di installazione di un’app installata dall’utente, l’objection tool fornisce un comando utile, env. Questo comando rivela informazioni dettagliate sulle directory relative all’app in questione. Di seguito un esempio di come usare questo comando:

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

In alternativa, il nome dell’app può essere cercato all’interno di /private/var/containers usando il comando find:

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

I comandi come ps e lsof possono anche essere utilizzati per identificare il processo dell’app e per elencare i file aperti, rispettivamente, fornendo informazioni sui percorsi di directory attivi dell’applicazione:

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

Directory del bundle:

  • AppName.app
  • Questo è il bundle dell’applicazione come visto precedentemente nell’IPA; contiene i dati essenziali dell’app, contenuti statici e il binario compilato dell’applicazione.
  • Questa directory è visibile agli utenti, ma gli utenti non possono scriverci.
  • Il contenuto di questa directory non viene sottoposto a backup.
  • Il contenuto di questa cartella viene usato per convalidare la firma del codice.

Directory dei dati:

  • Documents/
  • Contiene tutti i dati generati dall’utente. L’utente finale dell’applicazione avvia la creazione di questi dati.
  • Visibile agli utenti e gli utenti possono scriverci.
  • Il contenuto di questa directory viene incluso nel backup.
  • L’app può escludere percorsi impostando NSURLIsExcludedFromBackupKey.
  • Library/
  • Contiene tutti i file non specifici dell’utente, come cache, preferenze, cookie, e file di configurazione property list (plist).
  • Le app iOS di solito usano le sottodirectory Application Support e Caches, ma l’app può creare sottodirectory personalizzate.
  • Library/Caches/
  • Contiene file di cache semi-persistenti.
  • Invisibile agli utenti e gli utenti non possono scriverci.
  • Il contenuto di questa directory non viene sottoposto a backup.
  • Il sistema operativo può eliminare automaticamente i file di questa directory quando l’app non è in esecuzione e lo spazio di archiviazione è insufficiente.
  • Library/Application Support/
  • Contiene persistenti file necessari per l’esecuzione dell’app.
  • Invisibile agli utenti e gli utenti non possono scriverci.
  • Il contenuto di questa directory è sottoposto a backup.
  • L’app può escludere percorsi impostando NSURLIsExcludedFromBackupKey.
  • Library/Preferences/
  • Usata per memorizzare proprietà che possono persistere anche dopo il riavvio dell’applicazione.
  • Le informazioni sono salvate, non criptate, all’interno del sandbox dell’applicazione in un file plist chiamato [BUNDLE_ID].plist.
  • Tutte le coppie chiave/valore memorizzate usando NSUserDefaults si trovano in questo file.
  • tmp/
  • Utilizza questa directory per scrivere file temporanei che non devono persistere tra avvii dell’app.
  • Contiene file di cache non persistenti.
  • Invisibile agli utenti.
  • Il contenuto di questa directory non viene sottoposto a backup.
  • Il sistema operativo può eliminare automaticamente i file di questa directory quando l’app non è in esecuzione e lo spazio di archiviazione è insufficiente.

Esaminiamo più da vicino la directory bundle dell’applicazione (.app) di iGoat-Swift all’interno della directory del bundle (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app):

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

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

Binary Reversing

All’interno della cartella <application-name>.app troverai un file binary chiamato <application-name>. Questo è il file che verrà eseguito. Puoi effettuare un’analisi di base del binary con lo strumento otool:

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

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

Verifica se l’app è criptata

Controlla se c’è qualche output per:

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

Disassemblare il binario

Disassemblare la sezione .text:

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

Per stampare il segmento Objective-C dell’applicazione di esempio si può usare:

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

Per ottenere un codice Objective-C più compatto puoi usare class-dump:

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

#pragma mark Named Structures

struct CGPoint {
double _field1;
double _field2;
};

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

struct CGSize {
double _field1;
double _field2;
};

Tuttavia, le migliori opzioni per disassemblare il binario sono: Hopper e IDA.

Archiviazione dei dati

Per imparare come iOS memorizza i dati nel dispositivo leggi questa pagina:

iOS Basics

Warning

The following places to store information should be checked right after installing the application, after checking all the functionalities of the application and even after login out from one user and login into a different one.
The goal is to find unprotected sensitive information of the application (passwords, tokens), of the current user and of previously logged users.

Plist

plist files are structured XML files that contains key-value pairs. It’s a way to store persistent data, so sometimes you may find sensitive information in these files. It’s recommended to check these files after installing the app and after using intensively it to see if new data is written.

The most common way to persist data in plist files is through the usage of NSUserDefaults. This plist file is saved inside the app sandbox in Library/Preferences/<appBundleID>.plist

The NSUserDefaults class provides a programmatic interface for interacting with the default system. The default system allows an application to customize its behaviour according to user preferences. Data saved by NSUserDefaults can be viewed in the application bundle. This class stores data in a plist file, but it’s meant to be used with small amounts of data.

This data cannot be longer accessed directly via a trusted computer, but can be accessed performing a backup.

You can dump the information saved using NSUserDefaults using objection’s ios nsuserdefaults get

To find all the plist of used by the application you can access to /private/var/mobile/Containers/Data/Application/{APPID} and run:

find ./ -name "*.plist"

Per convertire file da XML or binary (bplist) in formato XML, sono disponibili vari metodi a seconda del sistema operativo:

Per gli utenti macOS: Utilizza il comando plutil. È uno strumento integrato in macOS (10.2+), progettato per questo scopo:

$ plutil -convert xml1 Info.plist

Per utenti Linux: Installa prima libplist-utils, poi usa plistutil per convertire il tuo file:

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

Durante una sessione di Objection: Per analizzare applicazioni mobile, un comando specifico consente di convertire direttamente i file plist:

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

Core Data

Core Data è un framework per gestire il livello modello degli oggetti nella tua applicazione. Core Data can use SQLite as its persistent store, ma il framework in sé non è un database.
CoreData non cripta i suoi dati per impostazione predefinita. Tuttavia, è possibile aggiungere un livello di crittografia aggiuntivo a CoreData. Vedi il GitHub Repo per maggiori dettagli.

Puoi trovare le informazioni SQLite di Core Data di un’applicazione nel percorso /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support

Se puoi aprire il database SQLite e accedere a informazioni sensibili, allora hai trovato una misconfigurazione.

-(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 è un key/value store basato su SQLite.
Poiché i database Yap sono database SQLite, puoi trovarli usando il comando indicato nella sezione precedente.

Altri database SQLite

È comune che le applicazioni creino il proprio database SQLite. Potrebbero memorizzare dati sensibili al loro interno e lasciarli non cifrati. Perciò, è sempre utile controllare ogni database nella directory dell’applicazione. Vai quindi nella directory dell’applicazione dove i dati sono salvati (/private/var/mobile/Containers/Data/Application/{APPID})

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

Firebase Real-Time Databases

Gli sviluppatori possono memorizzare e sincronizzare i dati in un database NoSQL ospitato nel cloud tramite Firebase Real-Time Databases. Memorizzati in formato JSON, i dati vengono sincronizzati a tutti i client connessi in tempo reale.

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

Firebase Database

Realm databases

Realm Objective-C e Realm Swift offrono un’alternativa potente per l’archiviazione dei dati, non fornita da Apple. Per impostazione predefinita, essi memorizzano i dati non cifrati, mentre la crittografia è disponibile tramite una configurazione specifica.

I database si trovano in: /private/var/mobile/Containers/Data/Application/{APPID}. Per esplorare questi file, è possibile utilizzare comandi come:

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

Per visualizzare questi file di database, è consigliato utilizzare Realm Studio.

Per implementare la crittografia all’interno di un database Realm, può essere utilizzato il seguente snippet di codice:

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

Database Couchbase Lite

Couchbase Lite è descritto come un motore di database leggero e incorporato che segue l’approccio document-oriented (NoSQL). Progettato per essere nativo su iOS e macOS, offre la possibilità di sincronizzare i dati in modo trasparente.

Per identificare potenziali database Couchbase su un dispositivo, dovrebbe essere ispezionata la seguente directory:

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

Cookies

iOS memorizza i cookies delle app in Library/Cookies/cookies.binarycookies all’interno della cartella di ogni app. Tuttavia gli sviluppatori a volte decidono di salvarli nel keychain, poiché il suddetto cookie file può essere accessibile nei backup.

Per ispezionare il file dei cookies puoi usare this python script o usare objection con ios cookies get.
Puoi anche usare objection per convertire questi file in formato JSON e ispezionare i dati.

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

Per impostazione predefinita NSURLSession memorizza dati, come HTTP requests and responses in the Cache.db database. Questo database può contenere dati sensibili, se token, username o qualsiasi altra informazione sensibile è stata memorizzata nella cache. Per trovare le informazioni memorizzate nella cache, apri la directory dei dati dell’app (/var/mobile/Containers/Data/Application/<UUID>) e vai in /Library/Caches/<Bundle Identifier>. Anche la WebKit cache viene memorizzata nel file Cache.db. Objection può aprire e interagire con il database con il comando sqlite connect Cache.db, poiché è un normale database SQLite.

È consigliato disabilitare il caching di questi dati, poiché possono contenere informazioni sensibili nella richiesta o nella risposta. L’elenco seguente mostra diversi modi per farlo:

  1. Si consiglia di rimuovere le Cached responses dopo il logout. Questo può essere fatto con il metodo fornito da Apple chiamato removeAllCachedResponses. Puoi chiamare questo metodo come segue:

URLCache.shared.removeAllCachedResponses()

Questo metodo rimuoverà tutte le richieste e le risposte memorizzate nella cache dal file Cache.db.

  1. Se non hai bisogno dei vantaggi dei cookie, è consigliabile usare la proprietà di configurazione .ephemeral di URLSession, che disabiliterà il salvataggio di cookie e cache.

Apple documentation:

Un oggetto di configurazione di sessione ephemeral è simile a una default session configuration (vedi default), eccetto che l'oggetto session corrispondente non memorizza cache, credential stores, o qualsiasi dato relativo alla sessione su disco. Invece, i dati relativi alla sessione sono memorizzati in RAM. L'unica volta in cui una sessione ephemeral scrive dati su disco è quando le dici di scrivere il contenuto di un URL su un file.

  1. La Cache può anche essere disabilitata impostando la Cache Policy su .notAllowed. Questo impedirà la memorizzazione della cache in qualsiasi modo, sia in memoria che su disco.

Snapshots

Ogni volta che premi il tasto home, iOS scatta uno snapshot dello schermo corrente per rendere la transizione tra le applicazioni più fluida. Tuttavia, se sono presenti dati sensibili nello schermo corrente, saranno salvati nell’immagine (che persiste anche dopo i riavvii). Questi sono gli snapshot che puoi anche visualizzare facendo doppio tap sul tasto home per passare tra le app.

A meno che l’iPhone non sia jailbroken, l’attacker deve avere accesso al device sbloccato per vedere questi screenshot. Per impostazione predefinita l’ultimo snapshot è memorizzato nella sandbox dell’app in Library/Caches/Snapshots/ o nella cartella Library/SplashBoard/Snapshots (i trusted computers non possono accedere al filesystem da iOX 7.0).

Un modo per prevenire questo comportamento indesiderato è mostrare uno schermo vuoto o rimuovere i dati sensibili prima che venga scattato lo snapshot, usando la funzione ApplicationDidEnterBackground().

Di seguito un metodo di remediation di esempio che imposterà uno screenshot di default.

Swift:

private var backgroundImage: UIImageView?

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

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

Objective-C:

@property (UIImageView *)backgroundImage;

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

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

This imposta l’immagine di sfondo su overlayImage.png ogni volta che l’applicazione viene messa in background. Previene i leaks di dati sensibili perché overlayImage.png sovrascriverà sempre la vista corrente.

Keychain

Per accedere e gestire il keychain di iOS, sono disponibili strumenti come Keychain-Dumper, adatti a dispositivi jailbroken. Inoltre, Objection fornisce il comando ios keychain dump per scopi simili.

Salvataggio delle credenziali

La classe NSURLCredential è ideale per salvare informazioni sensibili direttamente nel keychain, evitando la necessità di NSUserDefaults o di altri wrapper. Per salvare le credenziali dopo il login, si usa il seguente codice Swift:

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

Per estrarre queste credenziali memorizzate, si utilizza il comando di Objection ios nsurlcredentialstorage dump.

Custom Keyboards and Keyboard Cache

With iOS 8.0 onwards, users can install custom keyboard extensions, which are manageable under Settings > General > Keyboard > Keyboards. While these keyboards offer extended functionality, they pose a risk of keystroke logging and transmitting data to external servers, though users are notified about keyboards requiring network access. Apps can, and should, restrict the use of custom keyboards for sensitive information entry.

Security Recommendations:

  • Si consiglia di disabilitare le tastiere di terze parti per una maggiore sicurezza.
  • Prestare attenzione alle funzioni di autocorrezione e di suggerimenti automatici della tastiera iOS predefinita, che potrebbero memorizzare informazioni sensibili in file di cache situati in Library/Keyboard/{locale}-dynamic-text.dat o /private/var/mobile/Library/Keyboard/dynamic-text.dat. Questi file di cache dovrebbero essere controllati regolarmente alla ricerca di dati sensibili. Per cancellare i dati memorizzati nella cache, si consiglia di resettare il dizionario della tastiera tramite Settings > General > Reset > Reset Keyboard Dictionary.
  • L’intercettazione del traffico di rete può rivelare se una tastiera personalizzata sta trasmettendo le pressioni dei tasti a server remoti.

Preventing Text Field Caching

The UITextInputTraits protocol offers properties to manage autocorrection and secure text entry, essential for preventing sensitive information caching. For example, disabling autocorrection and enabling secure text entry can be achieved with:

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

Inoltre, gli sviluppatori dovrebbero assicurarsi che i campi di testo, specialmente quelli per l’inserimento di informazioni sensibili come password e PIN, disabilitino la memorizzazione nella cache impostando autocorrectionType su UITextAutocorrectionTypeNo e secureTextEntry su YES.

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

Logs

Il debugging del codice spesso prevede l’uso di logging. C’è un rischio perché i logs possono contenere informazioni sensibili. In passato, in iOS 6 e nelle versioni precedenti, i logs erano accessibili da tutte le app, causando il rischio di leak di dati sensibili. Ora, le applicazioni sono limitate ad accedere solo ai propri logs.

Nonostante queste restrizioni, un attaccante con accesso fisico a un dispositivo sbloccato può ancora sfruttare questo collegando il dispositivo a un computer e leggendo i logs. È importante notare che i logs rimangono sul disco anche dopo la disinstallazione dell’app.

Per mitigare i rischi, si consiglia di interagire approfonditamente con l’app, esplorando tutte le sue funzionalità e input per assicurarsi che nessuna informazione sensibile venga registrata involontariamente.

Quando si esamina il codice sorgente dell’app per possibili leak, cercare sia istruzioni di logging predefinite che logging personalizzate usando parole chiave come NSLog, NSAssert, NSCAssert, fprintf per le funzioni integrate, e qualsiasi riferimento a Logging o Logfile per implementazioni custom.

Monitoraggio dei System Logs

Le app registrano varie informazioni che possono essere sensibili. Per monitorare questi logs, strumenti e comandi come:

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

sono utili. Inoltre, Xcode offre un modo per raccogliere i log della console:

  1. Apri Xcode.
  2. Collega il dispositivo iOS.
  3. Vai su Window -> Devices and Simulators.
  4. Seleziona il tuo dispositivo.
  5. Riproduci il problema che stai indagando.
  6. Usa il pulsante Apri Console per visualizzare i log in una nuova finestra.

Per un logging più avanzato, connettersi alla shell del dispositivo e usare socat può fornire il monitoraggio dei log in tempo reale:

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

Segue una serie di comandi per osservare le attività dei log, che possono essere preziosi per diagnosticare problemi o identificare potenziali leak nei log.

Backup

Funzionalità di backup automatico sono integrate in iOS, facilitando la creazione di copie dei dati del dispositivo tramite iTunes (fino a macOS Catalina), Finder (da macOS Catalina in poi), o iCloud. Questi backup comprendono quasi tutti i dati del dispositivo, escludendo elementi altamente sensibili come i dettagli di Apple Pay e le configurazioni di Touch ID.

Rischi per la sicurezza

L’inclusione di app installate e i loro dati nei backup solleva la questione del potenziale leak di dati e il rischio che modifiche al backup potrebbero alterare il funzionamento dell’app. Si consiglia di non memorizzare informazioni sensibili in plaintext all’interno della directory di qualsiasi app o delle sue sottodirectory per mitigare questi rischi.

Escludere file dai backup

I file in Documents/ e Library/Application Support/ vengono inclusi nel backup per impostazione predefinita. Gli sviluppatori possono escludere file o directory specifiche dai backup usando NSURL setResourceValue:forKey:error: con la chiave NSURLIsExcludedFromBackupKey. Questa pratica è cruciale per proteggere i dati sensibili dall’essere inclusi nei backup.

Test per le vulnerabilità

Per valutare la sicurezza del backup di un’app, inizia creando un backup usando Finder, poi localizzalo seguendo le indicazioni di Apple’s official documentation. Analizza il backup alla ricerca di dati sensibili o configurazioni che potrebbero essere modificate per influenzare il comportamento dell’app.

Le informazioni sensibili possono essere cercate utilizzando strumenti da riga di comando o applicazioni come iMazing. Per i backup crittografati, la presenza della crittografia può essere confermata controllando la chiave “IsEncrypted” nel file “Manifest.plist” alla radice del backup.

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

Per gestire backup crittografati, gli script Python disponibili in DinoSec’s GitHub repo, come backup_tool.py e backup_passwd.py, possono essere utili, anche se potrebbero richiedere aggiustamenti per la compatibilità con le versioni più recenti di iTunes/Finder. Lo strumento iOSbackup tool è un’altra opzione per accedere ai file all’interno di backup protetti da password.

Modificare il comportamento dell’app

Un esempio di alterazione del comportamento di un’app tramite modifiche al backup è mostrato in Bither bitcoin wallet app, dove il PIN di blocco dell’interfaccia utente è memorizzato in net.bither.plist sotto la chiave pin_code. Rimuovendo questa chiave dal plist e ripristinando il backup si elimina la richiesta del PIN, fornendo accesso senza restrizioni.

Riepilogo sul testing della memoria per dati sensibili

Quando si gestiscono informazioni sensibili memorizzate nella memoria di un’applicazione, è cruciale limitare il tempo di esposizione di questi dati. Esistono due approcci principali per investigare il contenuto della memoria: creare un memory dump e analizzare la memoria in tempo reale. Entrambi i metodi presentano sfide, incluso il rischio di perdere dati critici durante il processo di dump o durante l’analisi.

Recupero e analisi di un memory dump

Per dispositivi sia jailbroken che non-jailbroken, tool come objection e Fridump permettono di effettuare il dump della memoria di processo di un’app. Una volta dumpata, l’analisi di questi dati richiede vari strumenti, a seconda della natura delle informazioni che si stanno cercando.

Per estrarre stringhe da un memory dump, si possono usare comandi come strings o rabin2 -zz:

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

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

Per un’analisi più dettagliata, inclusa la ricerca di tipi di dati specifici o modelli, radare2 offre ampie capacità di ricerca:

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

Analisi della memoria in tempo reale

r2frida offre un’alternativa potente per ispezionare la memoria di un’app in tempo reale, senza la necessità di un memory dump. Questo strumento permette l’esecuzione di comandi di ricerca direttamente sulla memoria dell’applicazione in esecuzione:

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

Cryptography compromessa

Processi di gestione delle chiavi inadeguati

Alcuni sviluppatori salvano dati sensibili nel local storage e li cifrano con una key hardcoded/predictable nel codice. Questo non dovrebbe essere fatto, perché il reverse engineering potrebbe permettere ad attaccanti di estrarre le informazioni riservate.

Uso di algoritmi insicuri e/o deprecati

Gli sviluppatori non dovrebbero usare deprecated algorithms per eseguire controlli di autorizzazione (checks), store o send dei dati. Alcuni di questi algoritmi sono: RC4, MD4, MD5, SHA1… Se vengono usati hashes per memorizzare le password, dovrebbero essere utilizzati hash resistenti al brute-force con salt.

Verifica

Le principali verifiche da eseguire sono trovare se è possibile individuare password/secrets hardcoded nel codice, o se queste sono predictable, e se il codice sta usando qualche tipo di weak cryptography algorithms.

È utile sapere che è possibile monitor alcune crypto libraries automaticamente usando objection con:

ios monitor crypt

Per maggiori informazioni sulle API e le librerie crittografiche iOS accedi https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography

Local Authentication

Local authentication svolge un ruolo cruciale, soprattutto quando si tratta di proteggere l’accesso a un endpoint remoto mediante metodi crittografici. Il punto è che, senza un’implementazione corretta, i meccanismi di local authentication possono essere aggirati.

Apple’s Local Authentication framework and the keychain provide robust APIs for developers to facilitate user authentication dialogs and securely handle secret data, respectively. Il Secure Enclave protegge l’ID dell’impronta per Touch ID, mentre Face ID si basa sul riconoscimento facciale senza compromettere i dati biometrici.

Per integrare Touch ID/Face ID, gli sviluppatori hanno due API tra cui scegliere:

  • LocalAuthentication.framework per l’autenticazione utente di alto livello senza accesso ai dati biometrici.
  • Security.framework per l’accesso ai servizi keychain a basso livello, proteggendo i dati segreti con l’autenticazione biometrica. Vari open-source wrappers rendono l’accesso al keychain più semplice.

Caution

Tuttavia, sia LocalAuthentication.framework che Security.framework presentano vulnerabilità, poiché restituiscono principalmente valori booleani senza trasmettere dati per i processi di autenticazione, rendendoli suscettibili ad essere aggirati (vedi Don’t touch me that way, by David Lindner et al).

Implementazione di Local Authentication

Per richiedere l’autenticazione agli utenti, gli sviluppatori dovrebbero utilizzare il metodo evaluatePolicy nella classe LAContext, scegliendo tra:

  • deviceOwnerAuthentication: Richiede Touch ID o il passcode del dispositivo, fallendo se nessuno dei due è abilitato.
  • deviceOwnerAuthenticationWithBiometrics: Richiede esclusivamente Touch ID.

Un’autenticazione riuscita è indicata da un valore booleano restituito da evaluatePolicy, evidenziando una potenziale falla di sicurezza.

Local Authentication usando Keychain

L’implementazione di local authentication nelle app iOS prevede l’uso delle keychain APIs per memorizzare in modo sicuro dati segreti come i token di autenticazione. Questo processo assicura che i dati possano essere accessibili solo dall’utente, utilizzando il passcode del dispositivo o l’autenticazione biometrica come Touch ID.

Il keychain offre la possibilità di impostare elementi con l’attributo SecAccessControl, che limita l’accesso all’elemento fino a quando l’utente non si autentica con successo tramite Touch ID o il passcode del dispositivo. Questa caratteristica è cruciale per aumentare la sicurezza.

Di seguito sono riportati esempi di codice in Swift e Objective-C che mostrano come salvare e recuperare una stringa dal keychain, sfruttando queste funzioni di sicurezza. Gli esempi mostrano in particolare come configurare il controllo di accesso per richiedere l’autenticazione Touch ID e garantire che i dati siano accessibili solo sul dispositivo su cui sono stati impostati, a condizione che sia configurato un passcode del dispositivo.

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

Ora possiamo richiedere l’elemento salvato dal keychain. Keychain services presenteranno la finestra di autenticazione all’utente e restituiranno data o nil a seconda che sia stato fornito un fingerprint appropriato o meno.

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

Rilevamento

L’uso dei framework in un’app può anche essere rilevato analizzando l’elenco delle librerie dinamiche condivise del binario dell’app. Questo può essere fatto usando otool:

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

Se LocalAuthentication.framework viene utilizzato in un’app, l’output conterrà entrambe le seguenti righe (ricorda che LocalAuthentication.framework usa Security.framework sotto il cofano):

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

Se viene utilizzato Security.framework, verrà mostrato solo il secondo.

Bypass del Local Authentication Framework

Objection

Attraverso Objection Biometrics Bypass, located at this GitHub page, è disponibile una tecnica per superare il meccanismo LocalAuthentication. La parte centrale di questo approccio consiste nell’usare Frida per manipolare la funzione evaluatePolicy, garantendo che restituisca costantemente un risultato True, indipendentemente dall’effettivo successo dell’autenticazione. Questo è particolarmente utile per aggirare processi di autenticazione biometrica difettosi.

Per attivare questo bypass, viene usato il seguente comando:

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

Questo comando avvia una sequenza in cui Objection registra un task che di fatto altera l’esito del controllo evaluatePolicy a True.

Frida

Un esempio di utilizzo di evaluatePolicy dall’applicazione DVIA-v2:

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

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

Per ottenere il bypass di Local Authentication, viene scritto uno script Frida. Questo script prende di mira il controllo evaluatePolicy, intercettando il suo callback per assicurarsi che restituisca success=1. Modificando il comportamento del callback, si ottiene il bypass del controllo di autenticazione.

Lo script qui sotto viene iniettato per modificare il risultato del metodo evaluatePolicy. Modifica il risultato del callback in modo che indichi sempre successo.

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

Per iniettare lo script Frida e effettuare il bypass dell’autenticazione biometrica, viene usato il seguente comando:

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

Esposizione di funzionalità sensibili tramite IPC

Gestori URI personalizzati / Deeplinks / Schemi personalizzati

iOS Custom URI Handlers / Deeplinks / Custom Schemes

iOS Universal Links

UIActivity Sharing

iOS UIActivity Sharing

UIPasteboard

iOS UIPasteboard

App Extensions

iOS App Extensions

WebViews

iOS WebViews

Serialisation and Encoding

iOS Serialisation and Encoding

Comunicazione di rete

È importante verificare che non avvengano comunicazioni senza crittografia e anche che l’applicazione stia correttamente validando il certificato TLS del server.
Per verificare questo tipo di problemi puoi usare un proxy come Burp:

iOS Burp Suite Configuration

Verifica del hostname

Un problema comune nella validazione del certificato TLS è verificare che il certificato sia stato firmato da una CA trusted, ma non verificare se l’hostname del certificato corrisponde all’hostname effettivamente contattato.
Per controllare questo problema usando Burp, dopo aver trustato la CA di Burp nell’iPhone, puoi creare un nuovo certificato con Burp per un hostname diverso e usarlo. Se l’applicazione continua a funzionare, allora è vulnerabile.

Certificate Pinning

Se un’applicazione usa correttamente lo SSL Pinning, allora l’applicazione funzionerà solo se il certificato è quello previsto. Quando si testa un’applicazione questo può essere un problema poiché Burp fornirà il proprio certificato.
Per bypassare questa protezione su un dispositivo jailbroken, puoi installare l’app SSL Kill Switch o installare Burp Mobile Assistant

Puoi anche usare objection ios sslpinning disable

Varie

  • In /System/Library puoi trovare i framework installati nel telefono usati dalle applicazioni di sistema
  • Le applicazioni installate dall’utente tramite App Store si trovano in /User/Applications
  • E /User/Library contiene i dati salvati dalle applicazioni a livello utente
  • Puoi accedere a /User/Library/Notes/notes.sqlite per leggere le note salvate nell’applicazione.
  • All’interno della cartella di un’applicazione installata (/User/Applications/<APP ID>/) puoi trovare alcuni file interessanti:
  • iTunesArtwork: L’icona usata dall’app
  • iTunesMetadata.plist: Informazioni dell’app usate nell’App Store
  • /Library/*: Contiene le preferenze e la cache. In /Library/Cache/Snapshots/* puoi trovare lo snapshot eseguito all’applicazione prima di inviarla in background.

Hot Patching/Aggiornamenti forzati

Gli sviluppatori possono patchare remotamente tutte le installazioni della loro app istantaneamente senza dover risottomettere l’applicazione all’App Store e aspettare l’approvazione.
A questo scopo solitamente si usa JSPatch. Ma ci sono altre opzioni come Siren e react-native-appstore-version-checker.
Questo è un meccanismo pericoloso che potrebbe essere abusato da SDK di terze parti malevoli; quindi è consigliabile verificare quale metodo viene usato per l’aggiornamento automatico (se presente) e testarlo. Potresti provare a scaricare una versione precedente dell’app per questo scopo.

Terze parti

Una sfida significativa con gli SDK di terze parti è la mancanza di controllo granulare sulle loro funzionalità. Gli sviluppatori si trovano davanti a una scelta: integrare lo SDK e accettare tutte le sue funzionalità, inclusi potenziali bug di sicurezza e problemi di privacy, oppure rinunciarne totalmente ai benefici. Spesso gli sviluppatori non possono correggere le vulnerabilità all’interno di questi SDK da soli. Inoltre, man mano che gli SDK guadagnano fiducia nella community, alcuni potrebbero iniziare a contenere malware.

I servizi forniti dagli SDK di terze parti possono includere tracking del comportamento degli utenti, visualizzazione di advertising o miglioramenti dell’esperienza utente. Tuttavia, questo introduce un rischio poiché gli sviluppatori potrebbero non essere completamente consapevoli del codice eseguito da queste librerie, portando a potenziali rischi per la privacy e la sicurezza. È cruciale limitare le informazioni condivise con i servizi di terze parti a ciò che è strettamente necessario e assicurarsi che nessun dato sensibile venga esposto.

L’implementazione dei servizi di terze parti di solito avviene in due forme: una libreria standalone o un SDK completo. Per proteggere la privacy degli utenti, qualsiasi dato condiviso con questi servizi dovrebbe essere anonimizzato per prevenire la divulgazione di Personal Identifiable Information (PII).

Per identificare le librerie che un’applicazione utilizza, può essere impiegato il comando otool. Questo strumento dovrebbe essere eseguito contro l’applicazione e ciascuna shared library che usa per scoprire librerie aggiuntive.

otool -L <application_path>

Vulnerabilità interessanti & Casi di studio

Air Keyboard Remote Input Injection

Itunesstored Bookassetd Sandbox Escape

Zero Click Messaging Image Parser Chains

Riferimenti & Altre risorse

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks