iOS Pentesting
Last updated
Last updated
Gebruik Trickest om maklik werkvloei te bou en te automate wat deur die wêreld se mees gevorderde gemeenskapstools aangedryf word. Kry Toegang Vandag:
Op hierdie bladsy kan jy inligting vind oor die iOS simulator, emulators en jailbreaking:
iOS Testing EnvironmentTydens die toetsing sal verskeie operasies voorgestel word (verbinding maak met die toestel, lêers lees/schryf/oplaai/aflaai, sommige gereedskap gebruik...). Daarom, as jy nie weet hoe om enige van hierdie aksies uit te voer nie, begin asseblief om die bladsy te lees:
iOS Basic Testing OperationsVir die volgende stappe moet die app geïnstalleer wees op die toestel en moet die IPA-lêer van die toepassing reeds verkry gewees het. Lees die Basic iOS Testing Operations bladsy om te leer hoe om dit te doen.
Dit word aanbeveel om die hulpmiddel MobSF te gebruik om 'n outomatiese Statiese Analise op die IPA-lêer uit te voer.
Identifikasie van beskermings wat in die binêre teenwoordig is:
PIE (Position Independent Executable): Wanneer geaktiveer, laai die toepassing in 'n ewekansige geheue adres elke keer as dit begin, wat dit moeiliker maak om sy aanvanklike geheue adres te voorspel.
Stack Canaries: Om die integriteit van die stapel te valideer, word 'n ‘canary’ waarde op die stapel geplaas voordat 'n funksie aangeroep word en weer geverifieer sodra die funksie eindig.
ARC (Automatic Reference Counting): Om algemene geheue korrupsie foute te voorkom
Enkripteerde Binêre: Die binêre moet geënkripteer wees
Identifikasie van Sensitiewe/Onveilige Funksies
Swak Hashing Algoritmes
Onveilige Ewekansige Funksies
Onveilige ‘Malloc’ Funksie
Onveilige en Kwetsbare Funksies
Kyk na die dinamiese analise wat MobSF uitvoer. Jy sal deur die verskillende weergawes moet navigeer en met hulle moet interaksie hê, maar dit sal verskeie klasse aanraak terwyl dit ander dinge doen en 'n verslag voorberei sodra jy klaar is.
Gebruik die opdrag frida-ps -Uai om die bundel identifiseerder van die geïnstalleerde apps te bepaal:
Leer hoe om die komponente van die toepassing te evalueer en hoe om maklik metodes en klasse te hook met objection:
iOS Hooking With ObjectionDie struktuur van 'n IPA-lêer is essensieel dié van 'n gecomprimeerde pakket. Deur die uitbreiding na .zip te hernoem, kan dit dekomprimeer word om sy inhoud te onthul. Binne hierdie struktuur verteenwoordig 'n Bundle 'n volledig verpakte toepassing wat gereed is vir installasie. Binne-in sal jy 'n gids met die naam <NAME>.app vind, wat die toepassing se hulpbronne bevat.
Info.plist: Hierdie lêer hou spesifieke konfigurasiedetails van die toepassing.
_CodeSignature/: Hierdie gids sluit 'n plist-lêer in wat 'n handtekening bevat, wat die integriteit van alle lêers in die bundel verseker.
Assets.car: 'n Gecomprimeerde argief wat hulpbronlêers soos ikone stoor.
Frameworks/: Hierdie gids huisves die toepassing se inheemse biblioteke, 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 hulle nie altyd teenwoordig is. * Core Data: Dit word gebruik om jou toepassing se permanente data vir offline gebruik te stoor, om tydelike data te kas, en om 'n ongedaan funksionaliteit aan jou app op 'n enkele toestel toe te voeg. Om data oor verskeie toestelle in 'n enkele iCloud-rekening te sinkroniseer, spieël Core Data outomaties jou skema na 'n CloudKit-container.
PkgInfo: Die PkgInfo-lêer is 'n alternatiewe manier om die tipe en skepper kodes van jou toepassing of bundel te spesifiseer.
en.lproj, fr.proj, Base.lproj: Is die taal pakkette wat hulpbronne vir daardie spesifieke tale bevat, en 'n standaard hulpbron in die geval dat 'n taal nie ondersteun word nie.
Sekuriteit: Die _CodeSignature/ gids speel 'n kritieke rol in die app se sekuriteit deur die integriteit van alle gebundelde lêers deur middel van digitale handtekeninge te verifieer.
Hulpbronbestuur: Die Assets.car-lêer gebruik kompressie om grafiese hulpbronne doeltreffend te bestuur, wat noodsaaklik is vir die optimalisering van toepassingprestasie en die vermindering van die algehele grootte.
Frameworks en PlugIns: Hierdie gidse beklemtoon die modulariteit van iOS-toepassings, wat ontwikkelaars in staat stel om herbruikbare kode biblioteke (Frameworks/) in te sluit en app-funksionaliteit uit te brei (PlugIns/).
Lokaliserings: Die struktuur ondersteun verskeie tale, wat globale toepassingsbereik fasiliteer deur hulpbronne vir spesifieke taal pakkette in te sluit.
Info.plist
Die Info.plist dien as 'n hoeksteen vir iOS-toepassings, wat sleutel konfigurasiedata in die vorm van sleutel-waarde pare kapsuleer. Hierdie lêer is 'n vereiste nie net vir toepassings nie, maar ook vir app-uitbreidings en frameworks wat binne ingesluit is. Dit is gestruktureer in óf XML óf 'n binêre formaat en hou kritieke inligting wat wissel van app-toestemmings tot sekuriteitskonfigurasies. Vir 'n gedetailleerde verkenning van beskikbare sleutels, kan 'n mens na die Apple Developer Documentation verwys.
Vir diegene wat met hierdie lêer in 'n meer toeganklike formaat wil werk, kan die XML-omskakeling moeiteloos bereik word deur die gebruik van plutil op macOS (beskikbaar vanweë op weergawes 10.2 en later) of plistutil op Linux. Die opdragte vir omskakeling is soos volg:
Vir macOS:
Vir Linux:
Onder die menigte inligting wat die Info.plist lêer kan bekendmaak, sluit noemenswaardige inskrywings app toestemming stringe (UsageDescription), pasgemaakte URL skemas (CFBundleURLTypes), en konfigurasies vir App Transport Security (NSAppTransportSecurity) in. Hierdie inskrywings, saam met ander soos uitgevoerde/ingevoerde pasgemaakte dokumenttipes (UTExportedTypeDeclarations / UTImportedTypeDeclarations), kan maklik gevind word deur die lêer te ondersoek of 'n eenvoudige grep opdrag te gebruik:
Data Paaie
In die iOS-omgewing is daar spesifieke gidse aangewys vir stelsels toepassings en gebruikers geïnstalleerde toepassings. Stelsels toepassings woon in die /Applications gids, terwyl gebruikers geïnstalleerde toepassings onder /var/mobile/containers/Data/Application/ geplaas word. Hierdie toepassings word toegeslaan met 'n unieke identifiseerder bekend as 'n 128-bit UUID, wat die taak om 'n toepassing se gids handmatig te vind uitdagend maak weens die ewekansigheid van die gidsname.
Aangesien toepassings in iOS in 'n sandbox moet wees, sal elke toepassing ook 'n gids hê binne $HOME/Library/Containers met die toepassing se CFBundleIdentifier as die gidsnaam.
Tog het beide gidse (data & houer gidse) die lêer .com.apple.mobile_container_manager.metadata.plist wat beide lêers verbind in die sleutel MCMetadataIdentifier).
Om die ontdekking van 'n gebruikers geïnstalleerde toepassing se installasie gids te vergemaklik, bied die objection tool 'n nuttige opdrag, env. Hierdie opdrag onthul gedetailleerde gidsinligting vir die betrokke toepassing. Hieronder is 'n voorbeeld van hoe om hierdie opdrag te gebruik:
Alternatiewelik kan die app naam binne die /private/var/containers gesoek word met die find opdrag:
Opdragte soos ps en lsof kan ook gebruik word om die app se proses te identifiseer en oop lêers te lys, onderskeidelik, wat insigte bied in die aansoek se aktiewe gidspade:
Bundle directory:
AppName.app
Dit is die Aansoek Bundel soos voorheen in die IPA gesien, dit bevat noodsaaklike aansoekdata, statiese inhoud sowel as die aansoek se gecompileerde binêre.
Hierdie gids is sigbaar vir gebruikers, maar gebruikers kan nie daarin skryf nie.
Inhoud in hierdie gids is nie gebackup nie.
Die inhoud van hierdie vouer word gebruik om die kodehandtekening te valideer.
Data directory:
Documents/
Bevat al die gebruiker-gegenereerde data. Die aansoek eindgebruiker begin die skepping van hierdie data.
Sigbaar vir gebruikers en gebruikers kan daarin skryf.
Inhoud in hierdie gids is gebackup.
Die aansoek kan paaie deaktiveer deur NSURLIsExcludedFromBackupKey in te stel.
Library/
Bevat al lêers wat nie gebruiker-spesifiek is nie, soos caches, voorkeure, cookies, en eiendomslys (plist) konfigurasielêers.
iOS aansoeke gebruik gewoonlik die Application Support en Caches subgidsen, maar die aansoek kan pasgemaakte subgidsen skep.
Library/Caches/
Bevat semi-permanente gekapte lêers.
Onsigbaar vir gebruikers en gebruikers kan nie daarin skryf nie.
Inhoud in hierdie gids is nie gebackup nie.
Die OS mag hierdie gids se lêers outomaties verwyder wanneer die aansoek nie loop nie en stoorplek laag is.
Library/Application Support/
Bevat permanente lêers wat nodig is om die aansoek te laat loop.
Onsigbaar vir gebruikers en gebruikers kan nie daarin skryf nie.
Inhoud in hierdie gids is geback up.
Die aansoek kan paaie deaktiveer deur NSURLIsExcludedFromBackupKey in te stel.
Library/Preferences/
Gebruik om eienskappe te stoor wat kan volhard selfs nadat 'n aansoek herbegin is.
Inligting word onversleuteld, binne die aansoek sandbox in 'n plist-lêer genaamd [BUNDLE_ID].plist gestoor.
Alle sleutel/waarde pare wat met NSUserDefaults gestoor word, kan in hierdie lêer gevind word.
tmp/
Gebruik hierdie gids om tydelike lêers te skryf wat nie tussen aansoeklopies hoef te volhard nie.
Bevat nie-permanente gekapte lêers.
Onsigbaar vir gebruikers.
Inhoud in hierdie gids is nie gebackup nie.
Die OS mag hierdie gids se lêers outomaties verwyder wanneer die aansoek nie loop nie en stoorplek laag is.
Kom ons kyk nader na iGoat-Swift se Aansoek Bundel (.app) gids binne die Bundel gids (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app):
Binne die <application-name>.app gids sal jy 'n binêre lêer vind wat <application-name> genoem word. Dit is die lêer wat uitgevoer sal word. Jy kan 'n basiese inspeksie van die binêre met die hulpmiddel otool uitvoer:
Kontroleer of die aansoek versleuteld is
Kyk of daar enige uitvoer is vir:
Ontleed die binêre
Ontleed die teksgedeelte:
Om die Objective-C segment van die voorbeeldtoepassing te druk, kan mens gebruik maak van:
Om 'n meer kompakte Objective-C kode te verkry, kan jy class-dump gebruik:
However, the best options to disassemble the binary are: Hopper and IDA.
Use Trickest om maklik te bou en outomatiese werksvloei te skep wat aangedryf word deur die wêreld se mees gevorderde gemeenskapstools. Kry Toegang Vandag:
Om te leer hoe iOS data in die toestel stoor, lees hierdie bladsy:
iOS BasicsDie volgende plekke om inligting te stoor moet reg na die installering van die toepassing nagegaan word, na die kontrole van al die funksies van die toepassing en selfs na uitteken van een gebruiker en inteken in 'n ander. Die doel is om onbeskermde sensitiewe inligting van die toepassing (wagwoorde, tokens), van die huidige gebruiker en van voorheen ingelogde gebruikers te vind.
plist lêers is gestruktureerde XML-lêers wat sleutel-waarde pare bevat. Dit is 'n manier om volgehoue data te stoor, so soms kan jy sensitiewe inligting in hierdie lêers vind. Dit word aanbeveel om hierdie lêers na die installering van die app en na intensiewe gebruik daarvan na te gaan om te sien of nuwe data geskryf is.
Die mees algemene manier om data in plist-lêers te behou, is deur die gebruik van NSUserDefaults. Hierdie plist-lêer word binne die app-sandbokse in Library/Preferences/<appBundleID>.plist gestoor.
Die NSUserDefaults klas bied 'n programmatiese koppelvlak vir interaksie met die standaardstelsel. Die standaardstelsel laat 'n toepassing toe om sy gedrag aan te pas volgens gebruikersvoorkeure. Data wat deur NSUserDefaults gestoor word, kan in die toepassingsbundel gesien word. Hierdie klas stoor data in 'n plist lêer, maar dit is bedoel om met klein hoeveelhede data gebruik te word.
Hierdie data kan nie langer direk via 'n vertroude rekenaar verkry word nie, maar kan verkry word deur 'n rugsteun uit te voer.
Jy kan die inligting wat gestoor is met NSUserDefaults dump met objection se ios nsuserdefaults get.
Om al die plist-lêers wat deur die toepassing gebruik word te vind, kan jy toegang verkry tot /private/var/mobile/Containers/Data/Application/{APPID} en uitvoer:
Om lêers van XML of binêre (bplist) formaat na XML te omskakel, is verskeie metodes beskikbaar, afhangende van jou bedryfstelsel:
Vir macOS gebruikers: Gebruik die plutil opdrag. Dit is 'n ingeboude hulpmiddel in macOS (10.2+), ontwerp vir hierdie doel:
Vir Linux gebruikers: Installeer eers libplist-utils, en gebruik dan plistutil om jou lêer te omskep:
Binne 'n Objection-sessie: Vir die ontleding van mobiele toepassings, laat 'n spesifieke opdrag jou toe om plist-lêers direk om te skakel:
Core Data is 'n raamwerk vir die bestuur van die modellaag van objekke in jou aansoek. Core Data kan SQLite as sy volhoubare stoor gebruik, maar die raamwerk self is nie 'n databasis nie.
CoreData enkripteer nie sy data standaard nie. Daar kan egter 'n addisionele enkripsielaag by CoreData gevoeg word. Sien die GitHub Repo vir meer besonderhede.
Jy kan die SQLite Core Data-inligting van 'n aansoek in die pad /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support vind.
As jy die SQLite kan oopmaak en toegang tot sensitiewe inligting kan kry, het jy 'n verkeerde konfigurasie gevind.
YapDatabase is 'n sleutel/waarde stoor wat op SQLite gebou is. Aangesien die Yap databasisse sqlite databasisse is, kan jy hulle vind met die voorgestelde opdrag in die vorige afdeling.
Dit is algemeen dat toepassings hul eie sqlite databasis skep. Hulle mag sensitiewe data daarop stoor en dit ongeënkripteerd laat. Daarom is dit altyd interessant om elke databasis binne die toepassingsgids na te gaan. Gaan dus na die toepassingsgids waar die data gestoor word (/private/var/mobile/Containers/Data/Application/{APPID})
Ontwikkelaars kan data stoor en sinkroniseer binne 'n NoSQL wolk-gehoste databasis deur Firebase Real-Time Databases. Gestoor in JSON-formaat, word die data in werklike tyd gesinkroniseer na alle gekonnekteerde kliënte.
Jy kan vind hoe om na verkeerd geconfigureerde Firebase databasisse te kyk hier:
Firebase DatabaseRealm Objective-C en Realm Swift bied 'n kragtige alternatief vir datastoor, wat nie deur Apple voorsien word nie. Standaard stoor hulle data ongeënkripteer, met enkripsie beskikbaar deur spesifieke konfigurasie.
Die databasisse is geleë by: /private/var/mobile/Containers/Data/Application/{APPID}. Om hierdie lêers te verken, kan 'n mens opdragte soos gebruik:
Vir die sien van hierdie databasislêers, word die Realm Studio hulpmiddel aanbeveel.
Om versleuteling binne 'n Realm-databasis te implementeer, kan die volgende kode-snippet gebruik word:
Couchbase Lite word beskryf as 'n liggewig en ingebedde databasis enjin wat die dokument-georiënteerde (NoSQL) benadering volg. Dit is ontwerp om inheems te wees aan iOS en macOS, en bied die vermoë om data naatloos te sink.
Om potensiële Couchbase databasisse op 'n toestel te identifiseer, moet die volgende gids ondersoek word:
iOS stoor die koekies van die programme in die Library/Cookies/cookies.binarycookies binne elke program se gids. egter, ontwikkelaars besluit soms om dit in die keychain te stoor aangesien die genoemde koekie-lêer in rugsteun toeganklik is.
Om die koekie-lêer te ondersoek, kan jy hierdie python-skrip gebruik of objection se ios cookies get.
Jy kan ook objection gebruik om hierdie lêers na 'n JSON-formaat te omskep en die data te ondersoek.
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 geberg is. Om die gebergde inligting te vind, open die datagids van die toepassing (/var/mobile/Containers/Data/Application/<UUID>) en gaan na /Library/Caches/<Bundle Identifier>. Die WebKit-kas word ook in die Cache.db lêer gestoor. Objection kan die databasis oopmaak en daarmee interaksie hê met die opdrag sqlite connect Cache.db, aangesien dit 'n normale SQLite databasis is.
Dit word aanbeveel om die kas van hierdie data te deaktiveer, aangesien dit sensitiewe inligting in die versoek of antwoord kan bevat. Die volgende lys hieronder toon verskillende maniere om dit te bereik:
Dit word aanbeveel om gebergde antwoorde na afmelding te verwyder. Dit kan gedoen word met die metode wat deur Apple verskaf word, genaamd removeAllCachedResponses. U kan hierdie metode soos volg aanroep:
URLCache.shared.removeAllCachedResponses()
Hierdie metode sal alle gebergde versoeke en antwoorde uit die Cache.db lêer verwyder. 2. As u nie die voordeel van koekies hoef te gebruik nie, word dit aanbeveel om net die .ephemeral konfigurasie eienskap van URLSession te gebruik, wat die stoor van koekies en kaste sal deaktiveer.
'n Ephemeral sessie konfigurasie objek is soortgelyk aan 'n standaard sessie konfigurasie (sien standaard), behalwe dat die ooreenstemmende sessie objek nie kaste, geloofwaardigheidswinkels, of enige sessie-verwante data op skyf stoor nie. In plaas daarvan word sessie-verwante data in RAM gestoor. Die enigste keer dat 'n ephemeral sessie data op skyf skryf, is wanneer jy dit sê om die inhoud van 'n URL na 'n lêer te skryf.' 3. Die kas kan ook gedeaktiveer word deur die Kasbeleid op .notAllowed in te stel. Dit sal die stoor van die kas op enige manier, hetsy in geheue of op skyf, deaktiveer.
Wanneer jy die tuisknoppie druk, neem iOS 'n snapshot van die huidige skerm om die oorgang na die toepassing op 'n baie gladder manier te kan doen. As daar egter sensitiewe data op die huidige skerm teenwoordig is, sal dit in die beeld gestoor word (wat volhard oor herlaaiings). Dit is die snapshots waartoe jy ook toegang kan verkry deur dubbel te tik op die tuisskerm om tussen toepassings te wissel.
Tensy die iPhone gejailbreak is, moet die aanvaller toegang tot die toestel ontsluit hê om hierdie skermskote te sien. Standaard word die laaste snapshot in die toepassings sandkas in die Library/Caches/Snapshots/ of Library/SplashBoard/Snapshots gids gestoor (die vertroude rekenaars kan nie toegang tot die lêerstelsel vanaf iOX 7.0 verkry nie).
Een manier om hierdie slegte gedrag te voorkom, is om 'n leë skerm te plaas of die sensitiewe data te verwyder voordat die snapshot geneem word met die ApplicationDidEnterBackground() funksie.
Die volgende is 'n voorbeeld van 'n herstelmetode wat 'n standaard skermskoot sal stel.
Swift:
Objective-C:
Dit stel die agtergrondbeeld in op overlayImage.png wanneer die aansoek in die agtergrond is. Dit voorkom sensitiewe data leaks omdat overlayImage.png altyd die huidige weergawe sal oorskry.
Vir toegang tot en bestuur van die iOS keychain, is gereedskap soos Keychain-Dumper beskikbaar, geskik vir jailbroken toestelle. Boonop bied Objection die opdrag ios keychain dump vir soortgelyke doeleindes.
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 aanmelding te stoor, word die volgende Swift-kode gebruik:
Om hierdie gestoor geloofsbriewe te onttrek, word Objection se opdrag ios nsurlcredentialstorage dump gebruik.
Met iOS 8.0 en later kan gebruikers pasgemaakte toetsborduitbreidings installeer, wat hanteerbaar is onder Instellings > Algemeen > Toetsbord > Toetsborde. Terwyl hierdie toetsborde uitgebreide funksionaliteit bied, stel hulle 'n risiko van toetsaanslaglogging en die oordrag van data na eksterne bedieners, alhoewel gebruikers in kennis gestel word van toetsborde wat netwerktoegang benodig. Programme kan, en behoort, die gebruik van pasgemaakte toetsborde vir die invoer van sensitiewe inligting te beperk.
Sekuriteitsaanbevelings:
Dit word aanbeveel om derdeparty-toetsborde te deaktiveer vir verbeterde sekuriteit.
Wees bewus van die outokorreksie- en outo-suggestiesfunksies van die standaard iOS-toetsbord, wat sensitiewe inligting in kaslêers kan stoor wat geleë is in Library/Keyboard/{locale}-dynamic-text.dat of /private/var/mobile/Library/Keyboard/dynamic-text.dat. Hierdie kaslêers moet gereeld nagegaan word vir sensitiewe data. Dit word aanbeveel om die toetsbordwoordeboek te reset via Instellings > Algemeen > Reset > Reset Toetsbordwoordeboek om gekapte data te verwyder.
Om netwerkverkeer te onderskep kan onthul of 'n pasgemaakte toetsbord toetsaanslae op afstand oordra.
Die UITextInputTraits-protokol bied eienskappe om outokorreksie en veilige teksinvoer te bestuur, wat noodsaaklik is om die kas van sensitiewe inligting te voorkom. Byvoorbeeld, om outokorreksie te deaktiveer en veilige teksinvoer in te skakel kan bereik word met:
Daarnaast moet ontwikkelaars verseker dat teksvelde, veral dié vir die invoer van sensitiewe inligting soos wagwoorde en PIN's, kasgeheue deaktiveer deur autocorrectionType op UITextAutocorrectionTypeNo en secureTextEntry op YES te stel.
Die ontfouting van kode behels dikwels die gebruik van logging. Daar is 'n risiko betrokke aangesien logs sensitiewe inligting kan bevat. Voorheen, in iOS 6 en vroeëre weergawes, was logs toeganklik vir alle toepassings, wat 'n risiko van sensitiewe data lek veroorsaak het. Nou is toepassings beperk tot die toegang van slegs hul logs.
Ten spyte van hierdie beperkings, kan 'n aanvaller met fisiese toegang tot 'n ontgrendelde toestel steeds hiervan voordeel trek deur die toestel aan 'n rekenaar te koppel en die logs te lees. Dit is belangrik om te noem dat logs op die skyf bly selfs nadat die app verwyder is.
Om risiko's te verminder, word dit aanbeveel om grondig met die app te interaksie, alle funksies en invoere te verken om te verseker dat geen sensitiewe inligting per ongeluk gelog word nie.
Wanneer jy die app se bronkode hersien vir potensiële lekke, soek vir beide vooraf gedefinieerde en aangepaste logging verklarings met sleutelwoorde soos NSLog, NSAssert, NSCAssert, fprintf vir ingeboude funksies, en enige vermeldings van Logging of Logfile vir aangepaste implementasies.
Apps log verskeie stukke inligting wat sensitief kan wees. Om hierdie logs te monitor, gereedskap en opdragte soos:
is nuttig. Boonop, Xcode bied 'n manier om konsol logs te versamel:
Maak Xcode oop.
Koppel die iOS toestel.
Navigeer na Window -> Devices and Simulators.
Kies jou toestel.
Trigger die probleem wat jy ondersoek.
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 werklike tyd log monitering bied:
Volg op met opdragte om logaktiwiteite te observeer, wat van onskatbare waarde kan wees vir die diagnose van probleme of die identifisering van potensiële datalekke in logs.
Gebruik Trickest om maklik te bou en werkvloei te outomatiseer wat deur die wêreld se mees gevorderde gemeenskapstools aangedryf word. Kry Toegang Vandag:
Outo-rugsteun funksies is in iOS geïntegreer, wat die skepping van toesteldata-kopieë deur iTunes (tot macOS Catalina), Finder (vanaf macOS Catalina) of iCloud vergemaklik. Hierdie rugsteun sluit byna alle toesteldata in, met uitsondering van hoogs sensitiewe elemente soos Apple Pay besonderhede en Touch ID konfigurasies.
Die insluiting van geïnstalleerde programme en hul data in rugsteun bring die kwessie van potensiële datalekke en die risiko dat rugsteunwysigings programfunksionaliteit kan verander na vore. Dit word aanbeveel om nie sensitiewe inligting in platte teks binne enige program se gids of sy subgidsen te stoor om hierdie risiko's te verminder.
Lêers in Documents/ en Library/Application Support/ word standaard geback-up. Ontwikkelaars kan spesifieke lêers of gidse van rugsteun uitsluit deur NSURL setResourceValue:forKey:error: met die NSURLIsExcludedFromBackupKey te gebruik. Hierdie praktyk is van kardinale belang om sensitiewe data te beskerm teen insluiting in rugsteun.
Om 'n program se rugsteun sekuriteit te evalueer, begin deur 'n rugsteun te skep met Finder, en vind dit dan met leiding van Apple se amptelike dokumentasie. Analiseer die rugsteun vir sensitiewe data of konfigurasies wat verander kan word om programgedrag te beïnvloed.
Sensitiewe inligting kan gesoek word met behulp van opdraglyn gereedskap of toepassings soos iMazing. Vir versleutelde rugsteun kan die teenwoordigheid van versleuteling bevestig word deur die "IsEncrypted" sleutel in die "Manifest.plist" lêer by die rugsteun se wortel te kontroleer.
Vir die hantering van versleutelde rugsteun, kan Python-skripte beskikbaar in DinoSec se GitHub-repo, soos backup_tool.py en backup_passwd.py, nuttig wees, alhoewel dit moontlik aanpassings mag vereis vir kompatibiliteit met die nuutste iTunes/Finder weergawes. Die iOSbackup-instrument is 'n ander opsie om toegang te verkry tot lêers binne wagwoord-beskermde rugsteun.
'n Voorbeeld van die verandering van app gedrag deur rugsteun wysigings word gedemonstreer in die Bither bitcoin beursie app, waar die UI slot PIN binne net.bither.plist onder die pin_code sleutel gestoor word. Om hierdie sleutel uit die plist te verwyder en die rugsteun te herstel, verwyder die PIN vereiste, wat onbeperkte toegang bied.
Wanneer daar met sensitiewe inligting wat in 'n toepassing se geheue gestoor is, gewerk word, is dit van kardinale belang om die blootstellingstyd van hierdie data te beperk. Daar is twee primêre benaderings om geheue-inhoud te ondersoek: die skep van 'n geheue dump en die ontleding van die geheue in werklike tyd. Beide metodes het hul uitdagings, insluitend die potensiaal om kritieke data tydens die dump proses of ontleding te mis.
Vir beide jailbroken en nie-jailbroken toestelle, laat gereedskap soos objection en Fridump die dumping van 'n app se proses geheue toe. Sodra dit gedump is, vereis die ontleding van hierdie data verskeie gereedskap, afhangende van die aard van die inligting waarna jy soek.
Om stringe uit 'n geheue dump te onttrek, kan opdragte soos strings of rabin2 -zz gebruik word:
Vir meer gedetailleerde analise, insluitend die soek na spesifieke datatipe of patrone, bied radare2 uitgebreide soekvermoëns:
r2frida bied 'n kragtige alternatief om 'n app se geheue in werklike tyd te inspekteer, sonder om 'n geheue-dump te benodig. Hierdie hulpmiddel stel die uitvoering van soekopdragte direk op die lopende toepassing se geheue in staat:
Sommige ontwikkelaars stoor sensitiewe data in die plaaslike stoor en enkripteer dit met 'n sleutel wat in die kode hardgecodeer/voorspelbaar is. Dit moet nie gedoen word nie, aangesien sommige omgekeerde ingenieurswese aanvallers in staat kan stel om die vertroulike inligting te onttrek.
Ontwikkelaars moet nie verouderde algoritmes gebruik om autorisasie kontroles uit te voer, stoor of stuur data nie. Sommige van hierdie algoritmes is: RC4, MD4, MD5, SHA1... As hashes gebruik word om wagwoorde te stoor, moet hashes wat teen brute-force weerstandig is, met sout gebruik word.
Die hoofkontroles om uit te voer, is om te vind of jy hardgecodeerde wagwoorde/geheime in die kode kan vind, of dit voorspelbaar is, en of die kode 'n soort swak kriptografie algoritmes gebruik.
Dit is interessant om te weet dat jy sommige crypto biblioteke outomaties kan monitor met objection met:
For meer inligting oor iOS-kodering-API's en biblioteke, toegang tot https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography
Plaaslike verifikasie speel 'n belangrike rol, veral wanneer dit kom by die beskerming van toegang by 'n afgeleë eindpunt deur middel van koderingmetodes. Die essensie hier is dat sonder behoorlike implementering, plaaslike verifikasiemeganismes omseil kan word.
Apple se Plaaslike Verifikasie-raamwerk en die sleutelsak bied robuuste API's vir ontwikkelaars om gebruikersverifikasiedialoge te fasiliteer en veilig geheime data te hanteer, onderskeidelik. Die Veilige Enklave beveilig 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-keuses:
LocalAuthentication.framework vir hoëvlak gebruikersverifikasie sonder toegang tot biometriese data.
Security.framework vir laevlak sleutelsakdienste toegang, wat geheime data beveilig met biometriese verifikasie. Verskeie oopbron-wrappers maak sleutelsaktoegang eenvoudiger.
Egter, beide LocalAuthentication.framework en Security.framework bied kwesbaarhede, aangesien hulle hoofsaaklik booleaanse waardes teruggee sonder om data vir verifikasieprosesse oor te dra, wat hulle vatbaar maak vir omseiling (verwys na Don't touch me that way, deur David Lindner et al).
Om gebruikers vir verifikasie te vra, moet ontwikkelaars die evaluatePolicy metode binne die LAContext klas gebruik, en kies tussen:
deviceOwnerAuthentication: Vra vir Touch ID of toestel se toegangskode, en faal as geen een geaktiveer is nie.
deviceOwnerAuthenticationWithBiometrics: Vra eksklusief vir Touch ID.
'n Suksesvolle verifikasie word aangedui deur 'n booleaanse terugwaarde van evaluatePolicy, wat 'n potensiële sekuriteitsfout beklemtoon.
Die implementering van plaaslike verifikasie in iOS-apps behels die gebruik van sleutelsak API's om geheime data soos verifikasietokens veilig te stoor. Hierdie proses verseker dat die data slegs deur die gebruiker, met behulp van hul toestel se toegangskode of biometriese verifikasie soos Touch ID, toegang verkry kan word.
Die sleutelsak bied die vermoë om items met die SecAccessControl attribuut in te stel, wat toegang tot die item beperk totdat die gebruiker suksesvol deur Touch ID of toestel se toegangskode verifieer. Hierdie kenmerk is van kardinale belang om sekuriteit te verbeter.
Hieronder is kodevoorbeelde in Swift en Objective-C wat demonstreer hoe om 'n string na/vanaf die sleutelsak te stoor en te onttrek, terwyl hierdie sekuriteitskenmerke benut word. Die voorbeelde toon spesifiek hoe om toegangbeheer op te stel om Touch ID-verifikasie te vereis en te verseker dat die data slegs op die toestel waaraan dit opgestel is, toeganklik is, onder die voorwaarde dat 'n toestel se toegangskode geconfigureer is.
Nou kan ons die gestoor item van die sleutelhouer aanvra. Sleutelhouer dienste sal die verifikasiedialoog aan die gebruiker aanbied en data of nil teruggee, afhangende van of 'n geskikte vingerafdruk verskaf is of nie.
Die gebruik van raamwerke in 'n app kan ook opgespoor word deur die app-binary se lys van gedeelde dinamiese biblioteke te analiseer. Dit kan gedoen word deur otool te gebruik:
As LocalAuthentication.framework in 'n app gebruik word, sal die uitvoer beide van die volgende lyne bevat (onthou dat LocalAuthentication.framework Security.framework onder die motorkap gebruik):
As Security.framework gebruik word, sal slegs die tweede een vertoon word.
Deur die Objection Biometriese Omseiling, geleë op hierdie GitHub-bladsy, is 'n tegniek beskikbaar om die LocalAuthentication meganisme te oorkom. Die kern van hierdie benadering behels die gebruik van Frida om die evaluatePolicy funksie te manipuleer, wat verseker dat dit konsekwent 'n True uitkoms lewer, ongeag die werklike verifikasie sukses. Dit is veral nuttig om gebrekkige biometriese verifikasieprosesse te omseil.
Om hierdie omseiling te aktiveer, word die volgende opdrag gebruik:
Hierdie opdrag stel 'n reeks in werking waar Objection 'n taak registreer wat effektief die uitkoms van die evaluatePolicy kontrole na True verander.
'n Voorbeeld van 'n gebruik van evaluatePolicy van DVIA-v2 toepassing:
Om die bypass van Plaaslike Verifikasie te bereik, word 'n Frida-skrip geskryf. Hierdie skrip teiken die evaluatePolicy kontrole, wat sy terugroep onderskep om te verseker dat dit success=1 teruggee. Deur die gedrag van die terugroep te verander, word die verifikasiekontrole effektief omseil.
Die skrip hieronder word ingespuit om die resultaat van die evaluatePolicy metode te wysig. Dit verander die terugroep se resultaat om altyd sukses aan te dui.
Om die Frida-skripte in te spuit en die biometriese verifikasie te omseil, word die volgende opdrag gebruik:
Dit is belangrik om te kontroleer dat daar geen kommunikasie plaasvind sonder versleuteling nie en ook dat die toepassing korrek die TLS sertifikaat van die bediener valideer. Om hierdie tipe probleme te kontroleer, kan jy 'n proxy soos Burp gebruik:
iOS Burp Suite ConfigurationEen algemene probleem met die validasie van die TLS sertifikaat is om te kontroleer dat die sertifikaat deur 'n vertroude CA onderteken is, maar nie te kontroleer of die gasheernaam van die sertifikaat die gasheernaam is wat toeganklik is nie. Om hierdie probleem met Burp te kontroleer, nadat jy Burp CA op die iPhone vertrou het, kan jy 'n nuwe sertifikaat met Burp vir 'n ander gasheernaam skep en dit gebruik. As die toepassing steeds werk, dan is daar iets wat kwesbaar is.
As 'n toepassing korrek SSL Pinning gebruik, sal die toepassing slegs werk as die sertifikaat die verwagte een is. Wanneer jy 'n toepassing toets, kan dit 'n probleem wees aangesien Burp sy eie sertifikaat sal dien. Om hierdie beskerming binne 'n jailbroken toestel te omseil, kan jy die toepassing SSL Kill Switch installeer of Burp Mobile Assistant installeer.
Jy kan ook objection's ios sslpinning disable gebruik.
In /System/Library kan jy die raamwerke vind wat op die telefoon geïnstalleer is deur stelsels toepassings.
Die toepassings wat deur die gebruiker vanaf die App Store geïnstalleer is, is geleë binne /User/Applications.
En die /User/Library bevat data wat deur die gebruiker vlak toepassings gestoor is.
Jy kan toegang verkry tot /User/Library/Notes/notes.sqlite om die notas wat binne die toepassing gestoor is, te lees.
Binne die gids 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 van die app wat in die App Store gebruik word.
/Library/*: Bevat die voorkeure en kas. In /Library/Cache/Snapshots/* kan jy die snapshot vind wat aan die toepassing gedoen is voordat dit na die agtergrond gestuur is.
Die ontwikkelaars kan op afstand alle installasies van hul app onmiddellik patch sonder om die toepassing weer aan die App Store in te dien en te wag totdat dit goedgekeur is. Vir hierdie doel word gewoonlik JSPatch** gebruik.** Maar daar is ook ander opsies soos Siren en react-native-appstore-version-checker. Dit is 'n gevaarlike mechanisme wat deur kwaadwillige derdeparty SDK's misbruik kan word, daarom word dit aanbeveel om te kontroleer watter metode gebruik word vir outomatiese opdatering (indien enige) en dit te toets. Jy kan probeer om 'n vorige weergawe van die app vir hierdie doel af te laai.
'n Beduidende uitdaging met 3de party SDK's is die gebrek aan fyn beheer oor hul funksies. Ontwikkelaars staan voor 'n keuse: of om die SDK te integreer en al sy funksies te aanvaar, insluitend potensiële sekuriteitskwesbaarhede en privaatheidskwessies, of om die voordele daarvan heeltemal te verwerp. Dikwels is ontwikkelaars nie in staat om kwesbaarhede binne hierdie SDK's self te patch nie. Verder, soos SDK's vertroue binne die gemeenskap verkry, kan sommige begin om malware te bevat.
Die dienste wat deur derdeparty SDK's verskaf word, kan gebruikersgedragopsporing, advertensie vertonings of gebruikerservaring verbeterings insluit. Dit stel egter 'n risiko in, aangesien ontwikkelaars dalk nie ten volle bewus is van die kode wat deur hierdie biblioteke uitgevoer word nie, wat lei tot potensiële privaatheids- en sekuriteitsrisiko's. Dit is van kardinale belang om die inligting wat met derdeparty dienste gedeel word, te beperk tot wat nodig is en te verseker dat geen sensitiewe data blootgestel word nie.
Die implementering van derdeparty dienste kom gewoonlik in twee vorme: 'n standalone biblioteek of 'n volledige SDK. Om gebruikersprivaatheid te beskerm, moet enige data wat met hierdie dienste gedeel word, geanonimiseer word om die bekendmaking van Persoonlike Identifiseerbare Inligting (PII) te voorkom.
Om die biblioteke wat 'n toepassing gebruik, te identifiseer, kan die otool opdrag gebruik word. Hierdie hulpmiddel moet teen die toepassing en elke gedeelde biblioteek wat dit gebruik, uitgevoer word om addisionele biblioteke te ontdek.
OWASP iGoat https://github.com/OWASP/igoat <<< Objective-C weergawe https://github.com/OWASP/iGoat-Swift <<< Swift weergawe
Gebruik Trickest om maklik te bou en werkvloei te automate wat deur die wêreld se mees gevorderde gemeenskapstoestelle aangedryf word. Kry Toegang Vandag:
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
