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

Privilege Separation and Sandbox

In iOS bestaan daar ’n onderskeid in privilige tussen die gebruiker-toeganklike toepassings en die stelsels se kernprosesse. Toepassings loop onder die mobile gebruikersidentiteit, terwyl die belangrike stelsels prosesse as root werk. Hierdie skeiding word versterk deur ’n sandbox-meganisme, wat streng beperkings op wat aksies toepassings kan onderneem, afdwing. Byvoorbeeld, selfs al deel toepassings dieselfde gebruikersidentiteit, is hulle verbied om toegang te verkry tot of mekaar se data te verander.

Toepassings word in ’n spesifieke gids geïnstalleer (private/var/mobile/Applications/{random ID}) en het beperkte lees toegang tot sekere stelsels areas en funksies, soos SMS en telefoonoproepe. Toegang tot beskermde areas aktiveer ’n pop-up versoek om gebruikers toestemming.

Data Protection

iOS bied ontwikkelaars die Data Protection APIs, gebou op die Secure Enclave Processor (SEP) — ’n toegewyde koprosessor vir kriptografiese operasies en sleutelbestuur. Die SEP verseker data beskerming integriteit deur ’n unieke toestel-spesifieke sleutel, die toestel UID, wat daarin ingebed is.

By die skep van ’n lĂȘer, word ’n unieke 256-bit AES-enkripsiesleutel gegenereer, wat die lĂȘer se inhoud enkripteer. Hierdie enkripsiesleutel, saam met ’n klas ID, word dan geĂ«nkripteer met ’n klas sleutel en in die lĂȘer se metadata gestoor. Om ’n lĂȘer te dekripteer, behels die gebruik van die stelselsleutel om toegang tot die metadata te verkry, die klas sleutel met die klas ID te onttrek, en dan die lĂȘer se unieke enkripsiesleutel te dekripteer.

iOS definieer vier beskermingsklasse vir datasekuriteit, wat bepaal wanneer en hoe data toegang kan verkry:

  • Complete Protection (NSFileProtectionComplete): Data is ontoeganklik totdat die toestel ontgrendel word met die gebruiker se toegangscode.
  • Protected Unless Open (NSFileProtectionCompleteUnlessOpen): Laat lĂȘer toegang toe selfs nadat die toestel vergrendel is, mits die lĂȘer geopen was toe die toestel ontgrendel is.
  • Protected Until First User Authentication (NSFileProtectionCompleteUntilFirstUserAuthentication): Data is toeganklik na die eerste gebruiker ontgrendel na opstart, en bly toeganklik selfs al is die toestel weer vergrendel.
  • No Protection (NSFileProtectionNone): Data is slegs beskerm deur die toestel UID, wat vinnige afstandsdata-wissing fasiliteer.

Die enkripsie van al die klasse, behalwe vir NSFileProtectionNone, behels ’n sleutel wat afgelei is van beide die toestel UID en die gebruiker se toegangscode, wat verseker dat dekripsie slegs op die toestel met die korrekte toegangscode moontlik is. Vanaf iOS 7 en verder is die standaard beskermingsklas “Protected Until First User Authentication”.

Ontwikkelaars kan FileDP gebruik, ’n hulpmiddel om die dataprotectie klas van lĂȘers op ’n iPhone te inspekteer.

# Example code to use FileDP for checking file protection class
# Note: Ensure your device is jailbroken and has Python installed to use FileDP.
# Installation and usage of FileDP:
git clone https://github.com/abjurato/FileDp-Source
cd FileDp-Source
python filedp.py /path/to/check

Die Sleutelhouer

In iOS dien ’n Sleutelhouer as ’n veilige geĂ«nkripteerde houer vir die stoor van sensitiewe inligting, wat slegs toeganklik is deur die toepassing wat dit gestoor het of diĂ© wat eksplisiet gemagtig is. Hierdie enkripsie word versterk deur ’n unieke wagwoord wat deur iOS gegenereer is, wat self geĂ«nkripteer is met AES. Hierdie enkripsieproses maak gebruik van ’n PBKDF2-funksie, wat die gebruiker se toegangscode kombineer met ’n sout wat afkomstig is van die toestel se UID, ’n komponent waartoe slegs die veilige enclave-skyfie toegang kan hĂȘ. Gevolglik, selfs al is die gebruiker se toegangscode bekend, bly die Sleutelhouer-inhoud ontoeganklik op enige toestel anders as die een waar dit oorspronklik geĂ«nkripteer is.

Bestuur en toegang tot die Sleutelhouer-data word hanteer deur die securityd daemon, gebaseer op spesifieke app-regte soos Keychain-access-groups en application-identifier.

Sleutelhouer API Operasies

Die Sleutelhouer API, gedetailleerd by Apple se Sleutelhouer Dienste dokumentasie, bied essensiële funksies vir veilige stoorbestuur:

  • SecItemAdd: Voeg ’n nuwe item by die Sleutelhouer.
  • SecItemUpdate: Werk ’n bestaande item in die Sleutelhouer op.
  • SecItemCopyMatching: Verkry ’n item uit die Sleutelhouer.
  • SecItemDelete: Verwyder ’n item uit die Sleutelhouer.

Brute-forcing van die Sleutelhouer wagwoord behels of die geĂ«nkripteerde sleutel direk aan te val of te probeer om die toegangscode op die toestel self te raai, wat aansienlik belemmer word deur die veilige enclave se afdwinging van ’n vertraging tussen mislukte pogings.

Konfigurasie van Sleutelhouer Item Data Beskerming

Data beskermingsvlakke vir Sleutelhouer-items word gestel met die kSecAttrAccessible attribuut tydens item skep of opdatering. Hierdie vlakke, soos gespesifiseer deur Apple, bepaal wanneer en hoe Sleutelhouer-items toeganklik is:

  • kSecAttrAccessibleAlways: Te alle tye toeganklik, ongeag toestel se vergrendelstatus.
  • kSecAttrAccessibleAlwaysThisDeviceOnly: Altijd toeganklik, maar nie ingesluit in rugsteun nie.
  • kSecAttrAccessibleAfterFirstUnlock: Toeganklik na die eerste ontgrendeling na herbegin.
  • kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly: Dieselfde as hierbo, maar nie oordraagbaar na nuwe toestelle nie.
  • kSecAttrAccessibleWhenUnlocked: Slegs toeganklik wanneer die toestel ontgrendel is.
  • kSecAttrAccessibleWhenUnlockedThisDeviceOnly: Toeganklik wanneer ontgrendel, nie ingesluit in rugsteun nie.
  • kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly: Vereis toestel toegangscode, nie ingesluit in rugsteun nie.

AccessControlFlags verfyn verder toegangmetodes, wat biometriese verifikasie of toegangscode gebruik toelaat.

Waarskuwing vir Jailbroken Toestelle

Warning

Op jailbroken toestelle is die Sleutelhouer se beskerming gecompromitteer, wat ’n beduidende sekuriteitsrisiko inhou.

Volharding van Sleutelhouer Data

Anders as app-spesifieke data wat verwyder word wanneer die app verwyder word, volhard Sleutelhouer data op die toestel. Hierdie eienskap kan nuwe eienaars van ’n tweedehandse toestel in staat stel om toegang te verkry tot die vorige eienaar se toepassingsdata bloot deur die apps weer te installeer. Ontwikkelaars word aangeraai om proaktief Sleutelhouer data te skoon te maak tydens app installasie of tydens afmelding om hierdie risiko te verminder. Hier is ’n Swift kode voorbeeld wat demonstreer hoe om Sleutelhouer data skoon te maak tydens die eerste app-lancering:

let userDefaults = UserDefaults.standard

if userDefaults.bool(forKey: "hasRunBefore") == false {
// Remove Keychain items here

// Update the flag indicator
userDefaults.set(true, forKey: "hasRunBefore")
userDefaults.synchronize() // Forces the app to update UserDefaults
}

App Vermoëns

In die wĂȘreld van app ontwikkeling, speel sandboxing ’n belangrike rol in die verbetering van sekuriteit. Hierdie proses verseker dat elke app binne sy eie unieke huisgids werk, wat dit verhoed om toegang te verkry tot stelselfeite of data wat aan ander apps behoort. Die afdwinging van hierdie beperkings word uitgevoer deur middel van sandbox beleid, wat ’n deel van die Trusted BSD (MAC) Mandatory Access Control Framework is.

Ontwikkelaars het die vermoĂ« om sekere vermoĂ«ns of toestemmings vir hul apps te konfigureer, soos Data Beskerming of Keychain Deling. Hierdie toestemmings word onmiddellik toegepas nadat die app geĂŻnstalleer is. Nietemin, om toegang te verkry tot sekere beskermde hulpbronne, moet die app eksplisiete toestemming van die gebruiker verkry tydens die eerste poging. Dit word bereik deur die gebruik van doelstrings of gebruik beskrywing strings, wat aan gebruikers in ’n toestemming versoek waarskuwing voorgelĂȘ word.

Vir diegene met toegang tot die bronkode, kan die verifikasie van toestemmings ingesluit in die Info.plist lĂȘer gedoen word deur:

  1. Die projek in Xcode te open.
  2. Die Info.plist lĂȘer te vind en te open.
  3. Te soek na sleutels wat met "Privacy -" begin, met die opsie om rou sleutels/waardes te sien vir duidelikheid.

Wanneer daar met ’n IPA-lĂȘer gewerk word, kan die volgende stappe gevolg word:

  1. Unzip die IPA.
  2. Vind die Info.plist lĂȘer binne Payload/<appname>.app/.
  3. Converteer die lĂȘer na XML-formaat indien nodig, vir makliker inspeksie.

Byvoorbeeld, die doelstrings in die Info.plist lĂȘer mag soos volg lyk:

<plist version="1.0">
<dict>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Your location is used to provide turn-by-turn directions to your destination.</string>

Toestelle Vermoëns

Die Info.plist lĂȘer van ’n app spesifiseer toestelle vermoĂ«ns wat die App Store help om apps vir toestelkompatibiliteit te filter. Hierdie word gedefinieer onder die UIRequiredDeviceCapabilities sleutel. Byvoorbeeld:

<key>UIRequiredDeviceCapabilities</key>
<array>
<string>armv7</string>
</array>

Hierdie voorbeeld dui aan dat die aansoek versoenbaar is met die armv7 instruksieset. Ontwikkelaars kan ook vermoëns soos nfc spesifiseer om te verseker dat hul aansoek slegs beskikbaar is vir toestelle wat NFC ondersteun.

Regte

Regte is ’n ander kritieke aspek van iOS aansoekontwikkeling, wat dien as sleutel-waarde pare wat aansoeke toestemming gee om sekere operasies uit te voer wat buite tydsduur kontroles val. Byvoorbeeld, om Data Protection in ’n aansoek in te skakel, behels die toevoeging van ’n spesifieke reg in die Xcode-projek, wat dan in die aansoek se regte-lĂȘer of die ingebedde mobiele voorsieningslĂȘer vir IPA’s weerspieĂ«l word.

Verwysings

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