iOS Pentesting

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Basiese iOS

iOS Basics

Toetsomgewing

Op hierdie bladsy kan jy inligting vind oor die iOS simulator, emulators en jailbreaking:

iOS Testing Environment

Aanvanklike Analise

Basic iOS Testing Operations

Tydens die toetsing sal verskeie operasies voorgestel word (koppel aan die device, lees/skryf/upload/download lêers, gebruik sekere tools…). Daarom, as jy nie weet hoe om enige van hierdie aksies uit te voer nie, begin asseblief deur die bladsy te lees:

iOS Basic Testing Operations

Tip

Vir die volgende stappe moet die app op die device geïnstalleer wees en behoort jy reeds die IPA file van die toepassing te hê.
Lees die Basic iOS Testing Operations bladsy om te leer hoe om dit te doen.

Basic Static Analysis

Sommige interessante iOS - IPA lêer dekompilers:

Dit word aanbeveel om die tool MobSF te gebruik om ’n outomatiese Static Analysis op die IPA file uit te voer.

Identifikasie van beskermings wat in die binêre teenwoordig is:

  • PIE (Position Independent Executable): Wanneer geaktiveer, laai die toepassing elke keer by ’n ewekansige geheue-adres, wat dit moeiliker maak om die aanvanklike geheue-adres te voorspel.
otool -hv <app-binary> | grep PIE   # It should include the PIE flag
  • Stack Canaries: Om die integriteit van die stack te valideer, word ’n ‘canary’ waarde op die stack geplaas voordat ’n funksie aangeroep word en word weer gevalideer wanneer die funksie eindig.
otool -I -v <app-binary> | grep stack_chk   # It should include the symbols: stack_chk_guard and stack_chk_fail
  • ARC (Automatic Reference Counting): Om algemene geheue-korrupsie foutjies te voorkom
otool -I -v <app-binary> | grep objc_release   # It should include the _objc_release symbol
  • Encrypted Binary: Die binêre behoort versleuteld te wees
otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # The cryptid should be 1

Identifikasie van Sensitiewe/Onveilige Funksies

  • 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: Kyk vir die teenwoordigheid van algemene jailbreak-lêers en -gidse, soos /Applications/Cydia.app of /Library/MobileSubstrate/MobileSubstrate.dylib.
  • Sandbox Violations: Probeer toegang kry tot beperkde gebiede van die lêerstelsel, wat op nie-jailbroken devices geblokkeer behoort te wees.
  • API Checks: Kontroleer of dit moontlik is om verbode oproepe te gebruik soos fork() om ’n kindproses te skep of system() om te sien of /bin/sh bestaan.
  • Process Checks: Moniteer vir die teenwoordigheid van bekende jailbreak-verwante prosesse, soos Cydia, Substrate, of ssh.
  • Kernel Exploits: Kyk vir die teenwoordigheid van kernel-exploits wat algemeen in jailbreaks gebruik word.
  • Environment Variables: Ondersoek omgewingveranderlikes vir tekens van ’n jailbreak, soos DYLD_INSERT_LIBRARIES.
  • Libraries Check: Kyk na die libs wat in die app-proses gelaai is.
  • Check schemes: Soos canOpenURL(URL(string: "cydia://")).

Common Anti-Debugging detection methods

  • Check for Debugger Presence: Gebruik sysctl of ander metodes om te kyk of ’n debugger aangeheg is.
  • Anti-Debugging APIs: Kyk vir oproepe na anti-debugging APIs soos ptrace of SIGSTOP soos ptrace(PT_DENY_ATTACH, 0, 0, 0).
  • Timing Checks: Meet die tyd wat sekere operasies neem en kyk vir afwykings wat debugging kan aandui.
  • Memory Checks: Inspekteer geheue vir bekende debugger-artefakte of modifikasies.
  • Environment Variables: Kyk na omgewingveranderlikes wat ’n debug-sessie kan aandui.
  • Mach Ports: Detect of mach exception ports gebruik word deur debuggers.

Anti-Debugging & Anti-Tamper Techniques (Layered Checks)

Werklike apps lae dikwels pre-exec, on-attach, en deurlopende kontroles. Algemene patrone om vir te kyk (en hoe om dit tydens toetsing te neutraliseer):

  • Private API side-channel fingerprinting: private launch APIs (bv. SBSLaunchApplicationWithIdentifierAndURLAndLaunchOptions) word misbruik om geïnstalleerde bundle IDs (com.opa334.TrollStore, org.coolstar.SileoStore, com.tigisoftware.Filza, ens.) te ondersoek op grond van return codes/logging. Hook die oproep en sanitiseer argumente/returnwaardes om ’n skoon device te emuleer.
  • Self-attestation via code-signing state: csops() met CS_OPS_ENTITLEMENTS_BLOB lees entitlements; onverwante waardes aktiveer ’n exit. Paar dit met integriteitskontroles (CRC32/MD5 van hulpbronne, sertifikaatvalidasie, Mach-O metadata soos LC_ENCRYPTION_INFO_64) om re-signing of patching te detecteer. Instrumenteer hierdie roetines en dwing “verwachte” resultate af tydens analise.
  • Kill-on-attach: ptrace(PT_DENY_ATTACH) gekombineer met abort()/exit() op attach. Omseil deur die beëindigingspad te neutraliseer of ptrace te hook sodat dit sukses behaal sonder om weigering af te dwing.
  • Crash forensics sabotage: oorskryf CPU-registers voor crash om backtraces te vernietig. Gebruik eerder breekpunte/hooks vroeër in die deteksiepad in plaas van op crash logs staat te maak.
  • Jetsam-based termination: doelbewuste geheugendruk om jetsam te veroorsaak, wat geen normale crash-log lewer nie. Kyk vir groot toewenings rondom deteksielogika en beperk/omseil dit om logs te behou.
  • Continuous checks with delayed enforcement: hartklop-timers hardloop deteksie weer en dwing later af. Trace timers/dispatch sources en hou die proses lewend deur die vertraagde kill-pad te omseil.

Basic Dynamic Analysis

Kyk na die dynamic analysis wat MobSF uitvoer. Jy sal deur die verskillende views moet navigeer en daarmee moet skakel, maar dit sal verskeie klasse hook terwyl jy ander dinge doen en ’n verslag voorberei sodra jy klaar is.

Listing Installed Apps

Gebruik die opdrag frida-ps -Uai om die bundle identifier van die geïnstalleerde apps te bepaal:

$ 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

Basiese Enumeration & Hooking

Leer hoe om die komponente van die toepassing te enumerate en hoe om maklik methods en classes te hook met objection:

iOS Hooking With Objection

IPA Struktuur

Die struktuur van ’n IPA file is in wese dié van ’n zipped package. Deur die uitbreiding na .zip te hernoem, kan dit gedekomprimeer word om die inhoud te openbaar. Binne hierdie struktuur verteenwoordig ’n Bundle ’n volledig gepakket toepassing gereed vir installasie. Binnein vind jy ’n gids met die naam <NAME>.app, wat die toepassing se hulpbronne enkapsuleer.

  • Info.plist: Hierdie lêer bevat spesifieke konfigurasie-detail van die toepassing.
  • _CodeSignature/: Hierdie gids sluit ’n plist-lêer in wat ’n handtekening bevat en sodoende die integriteit van alle lêers in die bundle verseker.
  • Assets.car: ’n Gepakte argief wat asset-lêers soos ikone stoor.
  • Frameworks/: Hierdie vouer huisves die toepassing se native libraries, wat in die vorm van .dylib of .framework lêers kan wees.
  • PlugIns/: Dit kan uitbreidings van die toepassing insluit, bekend as .appex lêers, alhoewel dit nie altyd teenwoordig is nie. * Core Data: It is used to save your application’s permanent data for offline use, to cache temporary data, and to add undo functionality to your app on a single device. To sync data across multiple devices in a single iCloud account, Core Data automatically mirrors your schema to a CloudKit container.
  • PkgInfo: Die PkgInfo lêer is ’n alternatiewe manier om die tipe- en skepperkode van jou toepassing of bundle te spesifiseer.
  • en.lproj, fr.proj, Base.lproj: Dit is die taalpakkette wat hulpbronne vir daardie spesifieke tale bevat, en ’n standaardhulpbron vir die geval dat ’n taal nie ondersteun word nie.
  • Security: Die _CodeSignature/ gids speel ’n kritieke rol in die app se sekuriteit deur die integriteit van alle ingesluit lêers deur digitale handtekeninge te verifieer.
  • Asset Management: Die Assets.car lêer gebruik kompressie om grafiese assette doeltreffend te bestuur, wat belangrik is vir die optimalisering van toepassingsprestasie en die vermindering van die algehele grootte.
  • Frameworks and PlugIns: Hierdie gidse beklemtoon die modulariteit van iOS-toepassings, wat ontwikkelaars in staat stel om herbruikbare kodelybraries (Frameworks/) in te sluit en app-funksionaliteit uit te brei (PlugIns/).
  • Localization: Die struktuur ondersteun meertaligheid en vergemaklik wêreldwye verspreiding deur hulpbronne vir spesifieke taalpakkette in te sluit.

Info.plist

Die Info.plist dien as ’n hoeksteen vir iOS-toepassings en enkapsuleer sleutelkonfigurasiedata in die vorm van key-value pare. Hierdie lêer is verpligtend nie net vir toepassings nie, maar ook vir app-uitbreidings en frameworks wat binne die bundle ingesluit is. Dit is gestruktureer in óf XML óf ’n binêre formaat en bevat kritieke inligting wat wissel van app-permissies tot sekuriteitskonfigurasies. Vir ’n gedetailleerde ondersoek van beskikbare sleutels kan gekyk word na die Apple Developer Documentation.

Vir diegene wat met hierdie lêer in ’n meer toeganklike formaat wil werk, kan die XML-omsetting moeiteloos bereik word deur die gebruik van plutil op macOS (natief beskikbaar op weergawes 10.2 en later) of plistutil op Linux. Die opdragte vir omskakeling is soos volg:

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

Onder die menigte inligting wat die Info.plist-lêer kan openbaar, is noemenswaardige inskrywings app toestemmingstrings (UsageDescription), pasgemaakte URL-skemas (CFBundleURLTypes), en konfigurasies vir App Transport Security (NSAppTransportSecurity). Hierdie inskrywings, tesame met ander soos geëksporteerde/geïmporteerde pasgemaakte dokumenttipes (UTExportedTypeDeclarations / UTImportedTypeDeclarations), kan moeiteloos gevind word deur die lêer te inspekteer of ’n eenvoudige grep-opdrag te gebruik:

$ grep -i <keyword> Info.plist

Data-paaie

In die iOS-omgewing word gidse spesifiek aangewys vir stelseltoepassings en deur gebruikers geïnstalleerde toepassings. Stelseltoepassings woon in die /Applications gids, terwyl deur gebruikers geïnstalleerde apps onder /var/mobile/containers/Data/Application/ geplaas word. Hierdie toepassings kry ’n unieke identifiseerder, bekend as ’n 128-bit UUID, wat die handmatige opsporing van ’n app se gids uitdagend maak weens die ewekansigheid van die gidsname.

Warning

Aangesien toepassings in iOS gesandbox moet wees, het elke app ook ’n gids binne $HOME/Library/Containers met die app se CFBundleIdentifier as die gidsnaam.

Beide gidse (data- en containergidse) bevat egter die lêer .com.apple.mobile_container_manager.metadata.plist wat albei gidse koppel deur die sleutel MCMetadataIdentifier).

Om die opsporing van ’n deur ’n gebruiker geïnstalleerde app se installasiegids te vergemaklik, bied die objection tool ’n nuttige opdrag, env. Hierdie opdrag openbaar gedetailleerde gidsinligting vir die betrokke app. Hieronder is ’n voorbeeld van hoe om hierdie opdrag te gebruik:

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

Alternatiewelik kan die app-naam binne /private/var/containers gesoek word met die find-opdrag:

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

Opdragte soos ps en lsof kan ook gebruik word om onderskeidelik die app se proses te identifiseer en oop lêers te lys, wat insig gee in die app se aktiewe directory-paadjies:

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

Bundel-gids:

  • AppName.app
  • Dit is die Application Bundle soos voorheen in die IPA gesien; dit bevat noodsaaklike toepassingsdata, statiese inhoud sowel as die toepassing se gekompileerde binêr.
  • Hierdie gids is sigbaar vir gebruikers, maar gebruikers kan nie daarin skryf nie.
  • Inhoud in hierdie gids word nie gerugsteun nie.
  • Die inhoud van hierdie vouer word gebruik om die kodehandtekening te valideer.

Datagids:

  • Documents/
  • Bevat al die deur gebruikers geskepte data. Die eindgebruiker van die toepassing initieer die skepping van hierdie data.
  • Sigbaar vir gebruikers en gebruikers kan daarin skryf.
  • Inhoud in hierdie gids word gerugsteun.
  • Die app kan paaie uitskakel deur NSURLIsExcludedFromBackupKey te stel.
  • Library/
  • Bevat alle lêers wat nie gebruikers-spesifiek is nie, soos caches, preferences, cookies, en property list (plist) konfigurasielêers.
  • iOS apps gebruik gewoonlik die Application Support en Caches subgidse, maar die app kan pasgemaakte subgidse skep.
  • Library/Caches/
  • Bevat semi-permanente gecachete lêers.
  • Onsigbaar vir gebruikers en gebruikers kan daar nie in skryf nie.
  • Inhoud in hierdie gids word nie gerugsteun nie.
  • Die OS kan die lêers in hierdie gids outomaties verwyder wanneer die app nie loop nie en stoorplek min raak.
  • Library/Application Support/
  • Bevat bestendige lêers wat nodig is vir die werking van die app.
  • Onsigbaar vir gebruikers en gebruikers kan nie daarin skryf nie.
  • Inhoud in hierdie gids is gerug steun.
  • Die app kan paaie uitskakel deur NSURLIsExcludedFromBackupKey te stel.
  • Library/Preferences/
  • Word gebruik om eienskappe te stoor wat selfs na herbegin van die toepassing kan voortbestaan.
  • Inligting word onversleuteld binne die toepassingsandbox gestoor in ’n plist-lêer genaamd [BUNDLE_ID].plist.
  • Alle sleutel/waarde-parings wat met NSUserDefaults gestoor is, kan in hierdie lêer gevind word.
  • tmp/
  • Gebruik hierdie gids om tydelike lêers te skryf wat nie tussen app-lanseeringe hoef te bly nie.
  • Bevat nie-permanente gecachete lêers.
  • Onsigbaar vir gebruikers.
  • Inhoud in hierdie gids word nie gerugsteun nie.
  • Die OS kan die lêers in hierdie gids outomaties verwyder wanneer die app nie loop nie en stoorplek min raak.

Kom ons kyk nader na iGoat-Swift se Application Bundle (.app)-gids binne die Bundel-gids (/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

Binne die <application-name>.app gids sal jy ’n binêre lêer vind met die naam <application-name>. Dit is die lêer wat uitgevoer sal word. Jy kan ’n basiese inspeksie van die binêre lêer uitvoer met die hulpmiddel 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)
[...]

Kontroleer of die app versleuteld is

Kyk of daar enige uitvoer is vir:

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

Disassembling the binary

Disassemble the text section:

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

Om die Objective-C segment van die voorbeeldtoepassing te druk, kan mens gebruik:

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

Om ’n meer kompakte Objective-C-kode te kry, kan jy class-dump gebruik:

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

Egter is die beste opsies om die binêre te disassembleer: Hopper en IDA.

Data-opslag

Om te leer hoe iOS data op die toestel stoor, lees hierdie bladsy:

iOS Basics

Warning

Die volgende plekke om inligting te stoor moet direk na die installering van die aansoek, na die kontrole van alle funksionaliteite van die aansoek en selfs na uitlog vanaf een gebruiker en inlog by ‘n ander’ nagegaan word.
Die doel is om onbeskermde sensitiewe inligting van die aansoek (wachtwoorde, tokens), van die huidige gebruiker en van voorheen aangemelde gebruikers te vind.

Plist

plist lêers is gestruktureerde XML-lêers wat sleutel-waarde pare bevat. Dit is ’n manier om volhoubare data te stoor, so soms kan jy sensitiewe inligting in hierdie lêers vind. Dit word aanbeveel om hierdie lêers te kontroleer nadat die app geïnstalleer is en na intensiewe gebruik om te sien of nuwe data geskryf is.

Die mees algemene manier om data in plist-lêers te behou is deur gebruik te maak van NSUserDefaults. Hierdie plist-lêer word binne die app-sandbox gestoor in Library/Preferences/<appBundleID>.plist

Die NSUserDefaults klas bied ’n programmeringskoppelvlak om met die standaardstelsel te kommunikeer. Die standaardstelsel laat ’n aansoek toe om sy gedrag aan te pas volgens user preferences. Data wat deur NSUserDefaults gestoor is, kan in die application bundle besigtig word. Hierdie klas stoor data in ’n plist file, maar dit is bedoel vir klein hoeveelhede data.

Hierdie data kan nie langer direk via ’n vertroude rekenaar toeganklik wees nie, maar kan verkry word deur ’n backup uit te voer.

Jy kan die inligting wat deur NSUserDefaults gestoor is, dump deur objection se ios nsuserdefaults get te gebruik

Om al die plist-lêers wat deur die aansoek gebruik word te vind, kan jy toegang kry tot /private/var/mobile/Containers/Data/Application/{APPID} en uitvoer:

find ./ -name "*.plist"

Om lêers van XML of binêr (bplist) formaat na XML om te skakel, is verskeie metodes beskikbaar, afhangend van jou bedryfstelsel:

Vir macOS-gebruikers: Gebruik die plutil opdrag. Dit is ’n ingeboude hulpmiddel in macOS (10.2+), ontwerp vir hierdie doel:

$ plutil -convert xml1 Info.plist

Vir Linux-gebruikers: Installeer libplist-utils eers, gebruik dan plistutil om jou lêer te omskep:

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

Binne ’n Objection-sessie: Om mobiele toepassings te ontleed, laat ’n spesifieke kommando jou toe om plist-lêers direk om te skakel:

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

Core Data

Core Data is ’n raamwerk vir die bestuur van die modellaag van objekte in jou toepassing. Core Data can use SQLite as its persistent store, maar die raamwerk self is nie ’n databasis nie.
CoreData enkripteer nie standaard sy data nie. Daar kan egter ’n bykomende enkripsielaag by CoreData gevoeg word. Sien die GitHub Repo vir meer besonderhede.

Jy kan die SQLite Core Data-inligting van ’n toepassing vind in die pad /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support

As jy die SQLite kan oopmaak en toegang tot sensitiewe inligting kry, het jy ’n miskonfigurasie gevind.

-(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 is ’n key/value store wat bo-op SQLite gebou is.
Aangesien die Yap-databasisse sqlite-databasisse is, kan jy hulle vind met die voorgestelde opdrag in die vorige afdeling.

Ander SQLite Databasisse

Dit is algemeen dat aansoeke hul eie sqlite-databasis skep. Hulle kan stoor gevoelige data daarop en dit onversleuteld laat. Daarom is dit altyd interessant om elke databasis binne die aansoekgids te kontroleer. Gaan dus na die aansoekgids waar die data gestoor word (/private/var/mobile/Containers/Data/Application/{APPID})

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

Firebase Real-Time Databases

Ontwikkelaars kan deur Firebase Real-Time Databases data stoor en sinkroniseer binne ’n NoSQL cloud-hosted database. In JSON-formaat gestoor, word die data in real time na alle gekoppelde kliënte gesinkroniseer.

Jy kan hier vind hoe om vir verkeerd gekonfigureerde Firebase-databasisse te kyk:

Firebase Database

Realm databases

Realm Objective-C and Realm Swift bied ’n kragtige alternatief vir dataopberging wat nie deur Apple verskaf word nie. Standaard stoor hulle data onversleuteld, en enkripsie is beskikbaar via spesifieke konfigurasie.

Die databasisse is geleë by: /private/var/mobile/Containers/Data/Application/{APPID}. Om hierdie lêers te verken, kan ’n mens kommando’s soos die volgende gebruik:

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

Om hierdie databasislêers te besigtig, word die Realm Studio hulpmiddel aanbeveel.

Om enkripsie binne ’n Realm-databasis te implementeer, kan die volgende kodestukkie gebruik word:

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

Couchbase Lite word beskryf as ’n liggewig en ingeslote databasis-enjin wat die dokumentgeoriënteerde (NoSQL) benadering volg. Ontwerp om inheems op iOS en macOS te wees, bied dit die vermoë om data naatloos te sinkroniseer.

Om potensiële Couchbase-databasisse op ’n toestel te identifiseer, moet die volgende gids ondersoek word:

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

Cookies

iOS stoor die cookies van die apps in die Library/Cookies/cookies.binarycookies binne elke app se gids. Sommige ontwikkelaars besluit egter om hulle in die keychain te stoor, aangesien die genoemde cookie file in backups toeganklik is.

Om die cookies-lêer te ondersoek kan jy this python script gebruik of gebruik objection se ios cookies get.
Jy kan ook objection gebruik om hierdie lêers na ’n JSON-formaat om te skakel en die data te inspekteer.

...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"
}
]

Kas

Standaard stoor NSURLSession data, soos HTTP versoeke en antwoorde in die Cache.db databasis. Hierdie databasis kan sensitiewe data bevat indien tokens, gebruikersname of enige ander sensitiewe inligting in die cache gestoor is. Om die gecachete inligting te vind, maak die data-gids van die app oop (/var/mobile/Containers/Data/Application/<UUID>) en gaan na /Library/Caches/<Bundle Identifier>. Die WebKit cache word ook in die Cache.db lêer gestoor. Objection kan die databasis open en daarmee kommunikeer met die opdrag sqlite connect Cache.db, aangesien dit ’normale SQLite-databasis is.

Dit word aanbeveel om die kasstoor van hierdie data uit te skakel, aangesien dit sensitiewe inligting in die versoek of antwoord kan bevat. Die volgende lys wys verskillende maniere om dit te bereik:

  1. Dit word aanbeveel om gecachede antwoorde na uitteken te verwyder. Dit kan gedoen word met die deur Apple verskafde metode genaamd removeAllCachedResponses Jy kan hierdie metode soos volg aanroep:

URLCache.shared.removeAllCachedResponses()

Hierdie metode sal alle gecachede versoeke en antwoorde uit die Cache.db-lêer verwyder.

  1. As jy nie die voordeel van koekies nodig het nie, word dit aanbeveel om net die .ephemeral konfigurasie-eienskap van URLSession te gebruik, wat die stoor van koekies en caches sal deaktiveer.

Apple documentation:

An ephemeral session configuration object is similar to a default session configuration (see default), except that the corresponding session object doesn’t store caches, credential stores, or any session-related data to disk. Instead, session-related data is stored in RAM. The only time an ephemeral session writes data to disk is when you tell it to write the contents of a URL to a file.

  1. Cache kan ook gedeaktiveer word deur die Cache Policy op .notAllowed te stel. Dit sal die stoor van cache op enige wyse deaktiveer, hetsy in geheue of op skyf.

Snapskote

Elke keer as jy die tuisknoppie druk, neem iOS ’n snapskoot van die huidige skerm om die oorgang na die toepassing gladder te laat verloop. As daar egter sensitiewe data op die huidige skerm is, sal dit in die beeld gestoor word (wat bly oor herlaaibeurte). Dit is die snapskote wat jy ook kan sien deur dubbel te tik op die tuisskerm om tussen apps te wissel.

Tensy die iPhone jailbroken is, moet die attacker access tot die device unblocked hê om hierdie skermskote te sien. Standaard word die laaste snapskoot in die toepassingssandbox gestoor in Library/Caches/Snapshots/ of Library/SplashBoard/Snapshots gids (trusted computers kan nie vanaf iOX 7.0 toegang tot die lêerstelsel kry nie).

Een manier om hierdie slegte gedrag te voorkom is om ’n leë skerm te wys of die sensitiewe data te verwyder voordat die snapskoot geneem word deur die ApplicationDidEnterBackground() funksie te gebruik.

Die volgende is ’n voorbeeld remediasiemetode wat ’n standaard skermskoot sal stel.

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

Dit stel die agtergrondbeeld op overlayImage.png elke keer as die aansoek in die agtergrond geplaas word. Dit voorkom sensitiewe data leaks omdat overlayImage.png altyd die huidige view sal oorheers.

Keychain

Om toegang tot en bestuur van die iOS keychain te kry, is gereedskap soos Keychain-Dumper beskikbaar, geskik vir jailbroken devices. Daarnaast verskaf Objection die opdrag ios keychain dump vir soortgelyke doeleindes.

Stoor Kredensiale

Die NSURLCredential klas is ideaal om sensitiewe inligting direk in die keychain te stoor, wat die behoefte aan NSUserDefaults of ander wrappers omseil. Om kredensiale na login te stoor, word die volgende Swift-kode gebruik:

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

Om hierdie gestoorde credentials uit te trek, word Objection se opdrag ios nsurlcredentialstorage dump gebruik.

Pasgemaakte sleutelborde en sleutelbord-cache

Vanaf iOS 8.0 kan gebruikers pasgemaakte sleutelbord-uitbreidings installeer, wat bestuur kan word onder Settings > General > Keyboard > Keyboards. Alhoewel hierdie sleutelborde uitgebreide funksionaliteit bied, dra hulle ’n risiko van keystroke logging en die oordrag van data na eksterne bedieners, alhoewel gebruikers gewaarsku word oor sleutelborde wat netwerktoegang benodig. Apps kan, en behoort, die gebruik van pasgemaakte sleutelborde vir die invoer van sensitiewe inligting te beperk.

Sekuriteitsaanbevelings:

  • Dit word aanbeveel om derdeparty-sleutelborde uit te skakel vir verbeterde sekuriteit.
  • Wees bewus van die autocorrect en auto-suggestions funksies van die standaard iOS keyboard, wat sensitiewe inligting in cache-lêers kan stoor wat geleë is in Library/Keyboard/{locale}-dynamic-text.dat of /private/var/mobile/Library/Keyboard/dynamic-text.dat. Hierdie cache-lêers moet gereeld nagegaan word vir sensitiewe data. Om die keyboard dictionary te herstel via Settings > General > Reset > Reset Keyboard Dictionary word aanbeveel om gekasheerde data skoon te maak.
  • Die onderskep van netwerkverkeer kan aantoon of ’n pasgemaakte sleutelbord keystrokes op afstand oordra.

Voorkoming van teksveld-kas

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;

Daarbenewens moet ontwikkelaars verseker dat teksvelde, veral dié vir die invoer van sensitiewe inligting soos wagwoorde en PINs, kasberging uitskakel deur autocorrectionType op UITextAutocorrectionTypeNo en secureTextEntry op YES te stel.

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

Logs

Foutopsporing van kode behels dikwels die gebruik van logging. Daar is ’n risiko aangesien logs sensitiewe inligting kan bevat. Voorheen, in iOS 6 en vroeër weergawes, was logs vir alle apps toeganklik, wat ’n risiko van sensitiewe data leak geskep het. Nou is toepassings beperk tot slegs toegang tot hul eie logs.

Ten spyte van hierdie beperkings kan ’n attacker met fisiese toegang tot ’n ontgrendelde toestel dit steeds misbruik deur die toestel aan ’n rekenaar te koppel en die logs te lees. Dit is belangrik om op te let dat logs op die skyf bly selfs na die app se verwydering.

Om risiko’s te beperk, word dit aanbeveel om deurgaans met die app te interaksie, en al die funksionaliteite en insette te verken om te verseker dat geen sensitiewe inligting per ongeluk in logs beland nie.

Wanneer jy die app se bronkode vir potensiële leaks hersien, kyk vir beide vooraf gedefinieerde en aangepaste logging-uitsprake deur te soek na sleutelwoorde soos NSLog, NSAssert, NSCAssert, fprintf vir ingeboude funksies, en enige verwysings na Logging of Logfile vir custom implementasies.

Monitoring System Logs

Apps log verskeie stukkies inligting wat sensitief kan wees. Om hierdie logs te monitor, gereedskap en opdragte soos:

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

is nuttig. Daarbenewens bied Xcode ’n manier om console logs te versamel:

  1. Maak Xcode oop.
  2. Koppel die iOS-toestel.
  3. Navigeer na Window -> Devices and Simulators.
  4. Selekteer jou toestel.
  5. Veroorsaak die probleem wat jy ondersoek.
  6. Gebruik die Open Console knoppie om logs in ’n nuwe venster te sien.

Vir meer gevorderde logging kan die verbinding met die toestel se shell en die gebruik van socat real-time logmonitering verskaf:

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

Gevolg deur opdragte om log-aktiwiteite waar te neem, wat van onskatbare waarde kan wees vir die diagnose van probleme of die identifisering van potensiële data leakage in logs.

Backups

Outomatiese rugsteunfunksies is geïntegreer in iOS en maak dit moontlik om kopieë van toesteldata te skep deur iTunes (tot macOS Catalina), Finder (vanaf macOS Catalina af), of iCloud. Hierdie rugsteunkopieë dek byna alle toesteldata, uitgesluit uiters sensitiewe elemente soos Apple Pay-besonderhede en Touch ID-konfigurasies.

Security Risks

Die inklusi van geïnstalleerde apps en hul data in rugsteunkopieë verhoog die kwessie van potensiële data leakage en die risiko dat wysigings aan rugsteunkopieë die app-funksionaliteit kan verander. Dit word aanbeveel om nie sensitiewe inligting in plaintext te stoor binne enige app se gids of subgids nie om hierdie risiko’s te verminder.

Excluding Files from Backups

Lêers in Documents/ en Library/Application Support/ word standaard gerugsteun. Ontwikkelaars kan spesifieke lêers of gidse van rugsteunkopieë uitsluit met NSURL setResourceValue:forKey:error: en die NSURLIsExcludedFromBackupKey. Hierdie praktyk is noodsaaklik om sensitiewe data te beskerm teen insluiting in rugsteunkopieë.

Testing for Vulnerabilities

Om ’n app se rugsteunsekuriteit te assesseer, begin deur ’n rugsteunkopie te skep met Finder, en lokaliseer dit dan met leiding vanaf Apple’s official documentation. Ontleed die rugsteunkopie vir sensitiewe data of konfigurasies wat verander kan word om app-gedrag te beïnvloed.

Sensitiewe inligting kan opgespoor word deur opdraglyn-gereedskap of toepassings soos iMazing. Vir geënkripteerde rugsteunkopieë kan die teenwoordigheid van enkripsie bevestig word deur die “IsEncrypted” sleutel in die “Manifest.plist” lêer op die wortel van die rugsteun te kontroleer.

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

Om met encrypted backups te werk, kan Python-skripte beskikbaar in DinoSec’s GitHub repo, soos backup_tool.py en backup_passwd.py, nuttig wees, alhoewel aanpassings nodig kan wees vir versoenbaarheid met die nuutste iTunes/Finder-weergawes. Die iOSbackup tool is nog ’n opsie om toegang tot lêers binne password-protected backups te kry.

App-gedrag wysig

’n Voorbeeld van die wysiging van app-gedrag deur backup-wysigings word gedemonstreer in die Bither bitcoin wallet app, waar die UI lock PIN gestoor word in net.bither.plist onder die pin_code sleutel. Deur hierdie sleutel uit die plist te verwyder en die backup te herstel, verdwyn die PIN-vereiste en kry jy onbeperkte toegang.

Opsomming oor geheue-toetsing vir sensitiewe data

Wanneer jy met sensitiewe inligting wat in ’n toepassing se geheue gestoor is werk, is dit noodsaaklik om die blootstellingsduur van hierdie data te beperk. Daar is twee primêre benaderings om geheue-inhoud te ondersoek: creating a memory dump en analyzing the memory in real time. Beide metodes het hul uitdagings, insluitend die potensiaal om kritieke data te mis tydens die dump-proses of analise.

Ophaling en ontleding van ’n Memory Dump

Vir beide jailbroken en non-jailbroken devices maak tools soos objection en Fridump dit moontlik om die prosesgeheue van ’n app te dump. Nadat dit gedump is, vereis die ontleding van hierdie data verskeie gereedskap, afhangende van die aard van die inligting waarna jy soek.

Om strings uit ’n memory dump te ekstraheer, kan opdragte soos strings of rabin2 -zz gebruik word:

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

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

Vir meer gedetailleerde ontleding, insluitend die soek na spesifieke datatipes of patrone, bied radare2 uitgebreide soekvermoëns:

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

Runtime Geheue-analise

r2frida bied ’n kragtige alternatief om die geheue van ’n app in reële tyd te inspekteer, sonder dat ’n memory dump nodig is. Hierdie hulpmiddel maak dit moontlik om soekopdragte direk op die lopende toepassing se geheue uit te voer:

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

Gebroke kriptografie

Swak sleutelbestuursprosesse

Sommige ontwikkelaars stoor sensitiewe data in die local storage en enkripteer dit met ’n sleutel wat hardcoded/predictable in die code is. Dit behoort nie gedoen te word nie, aangesien reversing ’n aanvaller kan toelaat om die vertroulike inligting te onttrek.

Gebruik van Onveilige en/of Verouderde Algoritmes

Ontwikkelaars behoort nie verouderde algoritmes te gebruik om autorisasie checks, data te store of te send nie. Sommige van hierdie algoritmes is: RC4, MD4, MD5, SHA1… As hashes byvoorbeeld gebruik word om wagwoorde te stoor, moet hashes wat bestand is teen brute-force (brute-force bestand) gebruik word met ’n salt.

Check

Die hoofkontroles om uit te voer is om te kyk of jy hardcoded wagwoorde/geheime in die code kan vind, of of dit predictable is, en of die code ’n tipe weak kriptografie algoritme gebruik.

Dit is interessant om te weet dat jy sekere crypto libraries outomaties kan monitor met objection met:

ios monitor crypt

Vir meer inligting oor iOS kriptografiese APIs en biblioteke besoek https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography

Plaaslike outentisering

Plaaslike outentisering speel ’n deurslaggewende rol, veral waar dit gaan oor die beskerming van toegang by ’n afgeleë eindpunt deur kriptografiese metodes. Die kern is dat sonder behoorlike implementering, plaaslike outentiseringsmeganismes omseil kan word.

Apple se Local Authentication framework en die keychain bied robuuste APIs vir ontwikkelaars om gebruikersoutentiseringsdialoë te fasiliteer en onderskeidelik geheime data veilig te hanteer. Die Secure Enclave beskerm vingerafdruk-ID vir Touch ID, terwyl Face ID op gesigsherkenning staatmaak sonder om biometriese data in gevaar te stel.

Om Touch ID/Face ID te integreer, het ontwikkelaars twee API-opsies:

  • LocalAuthentication.framework vir hoëvlak gebruikersoutentisering sonder toegang tot biometriese data.
  • Security.framework vir laer-vlak keychain-diensetoegang, wat geheime data met biometriese outentisering beveilig. Various open-source wrappers make keychain access simpler.

Caution

Echter, beide LocalAuthentication.framework en Security.framework stel kwesbaarhede voor, aangesien hulle hoofsaaklik boolean-waardes teruggee sonder om data vir outentiseringsprosesse te stuur, wat hulle vatbaar maak vir omseiling (verwys na Don’t touch me that way, by David Lindner et al).

Implementering van Plaaslike Outentisering

Om gebruikers vir outentisering te versoek, moet ontwikkelaars die evaluatePolicy metode binne die LAContext klas gebruik, en kies tussen:

  • deviceOwnerAuthentication: Vra vir Touch ID of toestelpaswoord; faal as geen van beide geaktiveer is.
  • deviceOwnerAuthenticationWithBiometrics: Vra uitsluitlik vir Touch ID.

’n Suksesvolle outentisering word aangedui deur ’n boolean terugwaarde van evaluatePolicy, wat ’n potensiële sekuriteitsgebrek uitwys.

Plaaslike outentisering met Keychain

Die implementering van plaaslike outentisering in iOS-apps behels die gebruik van keychain APIs om geheime data soos outentiseringstokens veilig te stoor. Hierdie proses verseker dat die data slegs deur die gebruiker toeganklik is, deur hul toestelpaswoord of biometriese outentisering soos Touch ID.

Die keychain bied die vermoë om items te stel met die SecAccessControl attribuut, wat toegang tot die item beperk totdat die gebruiker suksesvol outentiseer via Touch ID of toestelpaswoord. Hierdie funksie is deurslaggewend vir die verbetering van sekuriteit.

Hieronder is kodevoorbeelde in Swift en Objective-C wat demonstreer hoe om ’n string na/van die keychain te stoor en te herwin, deur gebruik te maak van hierdie sekuriteitsfunksies. Die voorbeelde toon spesifiek hoe om toegangbeheer op te stel om Touch ID-outentisering te vereis en te verseker dat die data slegs op die toestel waarop dit ingestel is toeganklik is, mits ’n toestelpaswoord gekonfigureer is.

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

Nou kan ons die gestoorde item van die Keychain versoek. Keychain services sal die authentication dialog aan die gebruiker aanbied en data of nil teruggee, afhangend daarvan of ’n geskikte fingerprint voorsien is of nie.

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

Opsporing

Die gebruik van frameworks in ’n app kan ook opgespoor word deur die app-binary se lys van gedeelde dinamiese biblioteke te ontleed. Dit kan gedoen word deur otool te gebruik:

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

As LocalAuthentication.framework in ’n app gebruik word, sal die uitvoer albei van die volgende reëls bevat (onthou dat LocalAuthentication.framework Security.framework onder die kap gebruik):

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

As Security.framework gebruik word, sal slegs die tweede een vertoon word.

Local Authentication Framework-omseiling

Objection

Deur die Objection Biometrics Bypass, te vinde op this GitHub page, is daar ’n tegniek beskikbaar om die LocalAuthentication-meganisme te oorbrug. Die kern van hierdie benadering behels die gebruik van Frida om die evaluatePolicy-funksie te manipuleer, sodat dit konstant True teruggee, ongeag die werklike status van die autentisering. Dit is veral nuttig om foutiewe biometriese autentiseringsprosesse te omseil.

Om hierdie bypass te aktiveer, word die volgende opdrag gebruik:

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

Hierdie opdrag stel ’n reeks in werking waar Objection ’n taak registreer wat effektief die uitslag van die evaluatePolicy-kontrole na True verander.

Frida

’n voorbeeld van die gebruik van evaluatePolicy uit DVIA-v2 application:

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

Om die bypass van Local Authentication te bereik, word ’n Frida-skrip geskryf. Hierdie skrip mik die evaluatePolicy-kontrole en onderskep sy callback om te verseker dat dit success=1 teruggee. Deur die callback se gedrag te verander, word die authentication check effektief gebypass.

Die onderstaande skrip word geïnjekteer om die resultaat van die evaluatePolicy method te wysig. Dit verander die callback se resultaat sodat dit altyd sukses aandui.

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

Om die Frida script te inject en die biometriese verifikasie te bypass, word die volgende opdrag gebruik:

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

Sensitiewe funksionaliteit blootgestel deur IPC

Custom URI Handlers / Deeplinks / Custom Schemes

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

Netwerkkommunikasie

Dit is belangrik om te verifieer dat geen kommunikasie sonder enkripsie plaasvind nie en ook dat die toepassing korrek die TLS-sertifikaat van die bediener valideer.
Om sulke probleme te kontroleer kan jy ’n proxy soos Burp gebruik:

iOS Burp Suite Configuration

Hostname-kontrole

Een algemene probleem by die validering van die TLS-sertifikaat is dat hulle kontroleer dat die sertifikaat deur ’n trusted CA geteken is, maar nie kontroleer of die hostname van die sertifikaat dieselfde is as die hostname wat geraak word nie.
Om hierdie probleem met Burp te toets, nadat jy Burp CA op die iPhone vertrou het, kan jy ’n nuwe sertifikaat met Burp vir ’n ander hostname skep en dit gebruik. As die toepassing steeds werk, is dit waarskynlik kwesbaar.

Certificate Pinning

As ’n toepassing korrek SSL Pinning gebruik, sal die toepassing slegs werk as die sertifikaat die verwagte een is. Wanneer ’n toepassing getoets word, kan dit problematies wees aangesien Burp sy eie sertifikaat bied.
Om hierdie beskerming op ’n jailbroken toestel te omseil, kan jy die toepassing SSL Kill Switch installeer of Burp Mobile Assistant installeer.

Jy kan ook objection se ios sslpinning disable gebruik.

Diverses

  • In /System/Library kan jy die frameworks vind wat op die foon geïnstalleer is en deur stelseltoepassings gebruik word
  • Die toepassings wat deur die gebruiker uit die App Store geïnstalleer is, bevind hom binne /User/Applications
  • En die /User/Library bevat data wat deur toepassings op gebruikersvlak gestoor is
  • Jy kan toegang kry tot /User/Library/Notes/notes.sqlite om die notas wat binne die aantekeningsapp gestoor is te lees.
  • In die vouer van ’n geïnstalleerde toepassing (/User/Applications/<APP ID>/) kan jy ’n paar interessante lêers vind:
  • iTunesArtwork: Die ikoon wat deur die app gebruik word
  • iTunesMetadata.plist: Inligting oor die app wat in die App Store gebruik word
  • /Library/*: Bevat die voorkeure en cache. In /Library/Cache/Snapshots/* kan jy die snapshot vind wat van die toepassing geneem is voordat dit na die agtergrond gestuur is.

Hot Patching/Enforced Updateing

Ontwikkelaars kan op afstand al die installasies van hul app onmiddellik patch sonder om die toepassing weer in te dien by die App Store en te wag tot goedkeuring.
Vir hierdie doel word gewoonlik JSPatch gebruik. Daar is egter ook ander opsies soos Siren en react-native-appstore-version-checker.
Dit is ’n gevaarlike meganisme wat deur kwaadwillige derdeparty-SDK’s misbruik kan word; dit word dus aanbeveel om te kontroleer watter metode vir outomatiese opdatering gebruik word (indien enige) en dit te toets. Jy kan probeer om ’n vorige weergawe van die app af te laai vir hierdie doeleinde.

Derdepartye

’n Groot uitdaging met 3rd party SDKs is die gebrek aan fyn beheer oor hul funksionaliteite. Ontwikkelaars staan voor ’n keuse: ofwel integreer hulle die SDK en aanvaar al sy funksies, insluitend potensiële sekuriteits- en privaatheidsrisiko’s, of hulle laat dit heeltemal vaar. Dikwels is ontwikkelaars nie in staat om kwesbaarhede binne hierdie SDK’s self te patch nie. Verder, soos SDK’s vertroue in die gemeenskap geniet, kan sommige begin malware bevat.

Die dienste wat deur derdeparty-SDK’s verskaf word kan gebruikersgedragtracking, advertensie-vertoning of verbeterings aan die gebruikerservaring insluit. Dit bring ’n risiko in dat ontwikkelaars moontlik nie ten volle bewus is van watter kode deur hierdie biblioteke uitgevoer word nie, wat tot privaatheids- en sekuriteitsrisiko’s kan lei. Dit is krities om die inligting wat met derdeparty-dienste gedeel word te beperk tot slegs wat nodig is en te verseker dat geen sensitiewe data uitgelewer word nie.

Implementering van derdeparty-dienste kom gewoonlik in twee vorme: ’n aparte biblioteek of ’n volledige SDK. Om gebruikersprivaatheid te beskerm, moet enige data wat met hierdie dienste gedeel word geanonimiseer word om die openbaarmaking van Personal Identifiable Information (PII) te voorkom.

Om die biblioteke wat ’n toepassing gebruik te identifiseer, kan die otool opdrag gebruik word. Hierdie instrument moet teen die toepassing en elke gedeelde biblioteek wat dit gebruik gedraai word om ekstra biblioteke op te spoor.

otool -L <application_path>

Interessante Kwesbaarhede & Gevallestudies

Air Keyboard Remote Input Injection

Itunesstored Bookassetd Sandbox Escape

Zero Click Messaging Image Parser Chains

Verwysings & Meer Hulpbronne

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks