🍏iOS
Dernière mise à jour
Dernière mise à jour
https://www.corellium.com/: VM iOS
https://github.com/prateek147/DVIA-v2: Damn Vulnerable iOS Application
https://github.com/OWASP/igoat: Application iOS vulnérable de l'OWASP
https://canijailbreak.com/: Vérifier si l'appareil est jailbreakable
Les différents composants des appareils IOS sont les suivants
Le noyau et pilote de l'appareil: Au plus bas niveau se trouve le noyau, l'environnement du noyau est construit sur Mach 3.0 (un micro-noyau qui remplace le noyau dans la version BSD d'Unix) et fournit des installations de mise en réseau hautes performances et la prise en charge de plusieurs systèmes de fichiers intégrés.
Core OS: Le core OS fournit diverses fonctionnalités de bas niveau sur lesquelles différents services sont construits. Ceux-ci incluent Accelerate Framework, Directory Services, System Configuration, OpenCL, etc.
Core service: La couche des services principaux fournit une abstraction des services fournis dans la couche du système d'exploitation principal. Ces services incluent généralement Carnet d'adresses, Social, Sécurité, Webkit, etc.
Media: La couche multimédia fournit divers services multimédias qui peuvent être utilisés dans l'appareil, c'est-à-dire qu'elle permet essentiellement toutes les technologies audiovisuelles. Il fournit diverses fonctions telles que Core Image, Core Audio, Core Text, etc.
Cocoa Touch (Application): Il s'agit de la couche la plus élevée de l'architecture qui expose diverses API pour la programmation des appareils iPhone.
Pas de Java ou Flash
Gestion des types de fichiers autorisés (.psd)
Selection des éléments à afficher lors du parsing (pour les fichiers pdf par exemple)
Absence de shell (/bin/sh)
IOS gére les privilèges de manière intelligente en attribuant un utilisateur avec des privilèges spécifiques pour certains types de processus (mobile, root, _wireless, _mdnsresponder...). Un attaquant prenant le contrôle d'un processus sera alors limité par les privilèges de l'utilisateur executant celui-ci.
L'un des mécanismes de sécurité les plus importants d'iOS est la signature de code.
Tous les fichiers binaires et bibliothèques doivent être signés par une autorité de confiance (telle que Apple) avant que le noyau ne leur permette d'être exécutés. De plus, seules les pages en mémoire provenant de sources signées seront exécutées.
Cela signifie que les applications ne peuvent pas modifier leur comportement de manière dynamique ou se mettre à niveau elles-mêmes. Ensemble, ces actions empêchent les utilisateurs de télécharger et exécuter des fichiers à partir d'Internet hors du contrôle de Apple. Toutes les applications doivent provenir de l'Apple App Store (sauf si l'appareil est configuré pour accepter d'autres sources).
Apple a l'approbation ultime et inspecte les applications avant qu'elles ne puissent être hébergées sur l'App Store. De cette façon, Apple empêche toutes introductions d'applications malicieuses dans le système de ses clients.
Cela empêche également l'utilisation de downloaders car en effet, chaque executables installés sur l'appareil doivent également être signé par une autorité de confiance.
Il s'agit d'un mecanisme permettant à l'appareil de différencier les données executables des autres dans sa mémoire empêchant ainsi l'execution non prévu de code.
Le bit XN permet au système d'exploitation de marquer des segments de mémoire comme non exécutables. Dans iOS, ce bit est appliqué par défaut à la pile et au tas d'un programme. Cela signifie que si un attaquant parvient à insérer du code malveillant dans l'un des deux, il ne pourra pas faire jump le programme vers son code à exécuter.
Dans iOS, l'emplacement des binaires, des bibliothèques, de l'éditeur de liens dynamique, de la pile et des adresses de mémoire de tas sont tous aléatoire. Lorsque les systèmes ont à la fois le DEP et l'ASLR, il n'y a pas de moyen générique d'écrire un exploit. En pratique, cela signifie généralement un attaquant a besoin de deux vulnérabilités, une pour obtenir l'exécution du code et une pour divulguer une adresse mémoire afin d'exécuter une ROP.
iOS détients plusieurs mécanismes de checks d'intégrité ainsi que la possibiliter de wipe à distance les données d'un appareil en cas de perte ou de vol de l'appareil. (Via l'API Data Protection)
Il permet également le chiffrement complet du disque de l'appareil.
Sur iOS, vous pouvez réaliser le chiffrement des fichiers. même lorsque l'appareil change d'état (par exemple, si l'appareil est initié ou déverrouillé ou si l'utilisateur a été authentifié au moins une fois).
Les clés de chiffrement sont ordonnées de manière hiérarchique comme ceci:
La clé de fichier (File Key) est une clé individuelle générée par fichier et stockée dans le métadonnées du fichier
La clé de classe (Class Key) est une clé dédiée pour une classe de protection des données particulière afin que les fichiers classés avec différents niveaux de protection utilisent des clés cryptographiques distinctes. Dans les anciennes versions d'iOS, la classe de protection par défaut était NSFileProtectionNone; à partir de la version 5, la classe de protection par défaut est NSFileProtectionCompleteUntilFirstUserAuthentication;
La clé de filesystem est une clé de chiffrement globale utilisée pour chiffrer les métadonnées liées à la sécurité du fichier une fois que les métadonnées sont chiffrées par la clé de classe.
La clé de Passcode si activée est une clé définie par l'utilisateur qui est combinée avec la clé materielle pour créer la clè de classe
La clé hardware également connue sous le nom de clé UID, est unique pour chaque appareil et accessible uniquement par le moteur hardware AES, et non par le système d'exploitation lui-même. Il s'agit de la clé principale du système, pour ainsi dire, qui chiffre la clé du filesystem et les clés de classe
Permet aux développeurs de stocker des informations telles que les mots de passe, les clés de chiffrement et les données utilisateur sensibles dans un emplacement sécurisé non accessible aux autres applications. Les appels à l'API Keychain sont transmis via le deamon securityd, qui extrait les données d'une base de données SQLite. Le développeur peut spécifier dans quelles circonstances les clés doivent être lisibles par les applications.
Fournie une couche de protection supplémentaire aux fichiers. Cela limite les circonstances dans lesquelles les processus du système peuvent lire ces fichiers. Cette API est le plus souvent utilisée pour rendre les données inaccessibles lorsqu'un appareil est verrouillé.
Sur iOS, Toutes les applications fonctionnent avec le même utilisateur (mobile) dans une sandbox qui ne donne accès qu'à sa propre partie du filesystem. De plus, iOS empêche les applications de faire certains appels système.
IOS possède un mécanisme de secure boot permettant de valider que toutes les ressources chargées au démarrage de l'appareil proviennent de sources sécurisés.
Il existe trois types d'applications IOS:
Les applications natives utilisent Objective C/Swift pour créer l'application
Les applications hybrides utilisent des frameworks comme Xamarin, Cordova etc. avec Objective C/Swift.
Les applications Web sont des versions réactives de sites Web conçues pour fonctionner sur un appareil mobile.
Les IPA sont comme des fichiers ZIP qui contiennent tout ce dont une application IOS a besoin pour fonctionner, on y retrouve les éléments suivants:
Le conteneur Bundle ou le conteneur IPA se compose de tous les fichiers qui accompagnent l'application lorsqu'elle est installée à partir de l'App Store d'Apple ou de toute autre source. Ainsi, les fichiers de ce répertoire resteront les mêmes dans une version particulière d'une application.
Le fichier Payload contient toutes les données de l'application
Le fichier exemple.app contient les données applicatives elles-mêmes (code compilé ARM) et les ressources statiques associées.
L'executable de l'application
L'icône de l'application
Le fichier info.plist contient les informations de configuration, telles que l'ID du bundle, le numéro de version et le nom d'affichage de l'application. Elles peuvent être affichées avec un éditeur de texte. Si c'est dans un format binaire, peut être converti en utilisant l'utilitaire plistutil.
L'image de lancement de l'application (celle que l'on voit à l'ouverture de l'application)
Le fichier MainWindow.nib qui contient les objets d'interface par défaut chargés au lancement de l'application. D'autres objets d'interface sont ensuite soit chargés à partir d'autres fichiers nib, soit créés par programme par l'application.
Le fichier Settings.bundle qui contient les préférences spécifiques à l'application.
D'autres ressources tels que des fichiers nib, images, fichiers audio, fichiers de configuration, fichiers de strings et tout autre fichier de données personnalisé utilisé par l'application.
Le fichier iTunesArtwork contient l'image PNG de l'icône de l'application
Le fichier iTunesMetadata.plist contient diverses informations, y compris le nom et l'identifiant du développeur, l'identifiant du bundle, les informations de copyright, le genre, le nom de l'application, la date de sortie, la date d'achat, etc.
Le fichier /WatchKitSupport/WK est un exemple de groupe d'extension. Ce bundle spécifique contient le délégué d'extension et les contrôleurs pour gérer les interfaces et répondre aux interactions des utilisateurs sur une Apple Watch. Par exemple, le SDK AWS.
Le dossier META-INF contenant deux fichiers qui eux même contienent des metadatas de l'application.
Le fichier Storyboard/nib contient les informations chiffrées du storyboard de l'application
Les fichier xx.lproj sont les fichiés spécifiques aux langues qu'utilisent l'application (FR, EN, PT...)
Le fichier _CodeSignature/CodeResources qui contient la signature de tous les fichiers signés du bundle container.
Le répertoire Frameworks qui contient les informations des frameworks utilisés par l'application.
Le répertoire SC_Info qui contient les clés utilisées pour déchiffrer l'executable de l'application, on y retrouve également tous les fichiers permettant les checks d'intégrité de l'application.
Le fichier Assets.car qui contient les images utilisées par l'application
Le fichier PkgInfo (Optionnel) qui est une alternative pour spécifier le code type et le code créateur.
Le répertoire "Data" ou le conteneur Local Data Storage se compose des fichiers que le développeur souhaite stocker pour l'application pendant la durée où l'application est installé sur l'appareil.
Les fichiers peuvent être utilisés pour mettre en cache des informations pour un accès rapide ou pour stocker des informations hors ligne en tant que sauvegarde pour reprendre l'application à partir du point prévu par le développeur. Ainsi, les fichiers de ce répertoire ainsi que les informations contenues dans les fichiers continueront de changer pendant l'utilisation de l'application.
On peut y retrouver:
Des documents potentiellement stockés localement lors de l'utilisation de l'application
Le répertoire Library contenant:
Le répertoire Application Support utilisé pour stockées les données de l'application hors données de l'utilisateur (est backup dans iCloud et iTunes)
Le répertoire Caches contenant les données mises en cache par l'application.
Le répertoire Preferences contenant les fichiers de préférences de l'application.
Le répertoire tmp contenant les données en backup et dont la finalité est d'être supprimés à la fin d'un processus. (données temporaires)
Le répertoire Storekit qui est spécifique au business, il donne accès aux éléments suivants:
In-App Purchase: Gére les achats dans l'application
Apple Music
Recommendations et review: permet à l'utilisateur de faire un feedback et évaluer l'application
Ce conteneur contient des données utilisées par les applications iOS compatibles iCloud. Les fichiers de ce répertoire sont destinés à être stockés et mis à jour par les sources à partir desquelles un utilisateur décide de mettre à jour le fichier.
Il est décomposé en deux parties:
Le répertoire Documents contenant les fichiers destinés à être lus et mis à jour directement par l'utilisateur. Ces fichiers sont régulièrement sauvegardés sur iCloud pour rester synchronisés.
Le répertoire Data contenant les fichiers qui ne sont pas destinés à être modifiés ou ajoutés directement par l'utilisateur. Les données peuvent être conservées dans différents répertoires selon les souhaits du développeur.
Needle est un framework de tests de sécurité automatique pour iOS.
ressource: https://github.com/WithSecureLabs/needle
BinaryCookieReader est un outil python permettant de lire le format binarycookie des Cookies sur les applications iOS.
Utilisation:
$ python BinaryCookieReader.py path/to/exemple.cookie.binarycookie
ressource: https://github.com/as0ler/BinaryCookieReader/
Keychain-Dumper est un outil permettant de vérifier quels éléments de la keychain sont disponibles pour un attaquant une fois qu'un appareil iOS a été jailbreaké.
Exemple Utilisation:
$ ./keychain-dumper -a
ressource: https://github.com/ptoomey3/Keychain-Dumper/
Outil Blackbox pour aider à comprendre ce que fait une application iOS pendant son fonctionnement et aider à l'identification des problèmes de sécurité potentiels.
ressource: https://github.com/iSECPartners/Introspy-iOS
