☁️ 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](https://github.com/sponsors/carlospolop) ! - Découvrez [La famille PEASS](https://opensea.io/collection/the-peass-family), notre collection d'[NFTs](https://opensea.io/collection/the-peass-family) exclusifs. - Obtenez le [swag officiel PEASS & HackTricks](https://peass.creator-spring.com) - Rejoignez le [💬](https://emojipedia.org/speech-balloon/) groupe Discord ou le groupe [telegram](https://t.me/peass) ou suivez-moi sur Twitter [🐦](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[@carlospolopm](https://twitter.com/hacktricks_live). - Partagez vos astuces de piratage en soumettant des PR au [dépôt hacktricks](https://github.com/carlospolop/hacktricks) et au [dépôt hacktricks-cloud](https://github.com/carlospolop/hacktricks-cloud).
# Séparation des privilèges et bac à sable Les applications auxquelles l'utilisateur peut accéder s'exécutent en tant qu'utilisateur **mobile** tandis que les processus système critiques s'exécutent en tant que **root**.\ Cependant, le bac à sable permet un meilleur contrôle des actions que les processus et les applications peuvent effectuer. Par exemple, même si deux processus s'exécutent en tant que même utilisateur (mobile), ils ne sont **pas autorisés à accéder ou à modifier les données de l'autre**. Chaque application est installée sous **`private/var/mobile/Applications/{ID aléatoire}`**\ Une fois installées, les applications ont un accès en lecture limité à certaines zones et fonctions du système (SMS, appel téléphonique...). Si une application souhaite accéder à une **zone protégée**, une **fenêtre contextuelle demandant l'autorisation** apparaît. # Protection des données Les développeurs d'applications peuvent exploiter les API de _Protection des données_ d'iOS pour mettre en œuvre un **contrôle d'accès fin** pour les données utilisateur stockées dans la mémoire flash. Les API sont construites sur le **processeur Secure Enclave** (SEP). Le SEP est un coprocesseur qui fournit des **opérations cryptographiques pour la protection des données et la gestion des clés**. Une clé matérielle spécifique au dispositif - l'**UID de dispositif** (identifiant unique) - est **intégrée dans l'enclave sécurisée**, assurant l'intégrité de la protection des données même lorsque le noyau du système d'exploitation est compromis. Lorsqu'un **fichier est créé** sur le disque, une nouvelle **clé AES de 256 bits est générée** à l'aide du générateur de nombres aléatoires basé sur le matériel de l'enclave sécurisée. Le **contenu du fichier est ensuite chiffré avec la clé générée**. Et ensuite, cette **clé est enregistrée chiffrée avec une clé de classe** avec **l'ID de classe**, avec **les deux données chiffrées par la clé du système**, à l'intérieur des **métadonnées** du fichier. ![](<../../.gitbook/assets/image (473).png>) Pour déchiffrer le fichier, les **métadonnées sont déchiffrées en utilisant la clé du système**. Ensuite, en utilisant l'**ID de classe**, la **clé de classe est récupérée** **pour déchiffrer la clé par fichier et déchiffrer le fichier.** Les fichiers peuvent être attribués à l'une des **quatre classes de protection différentes**, qui sont expliquées en détail dans le [Guide de sécurité de la plateforme Apple](https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf) : * **Protection complète (NSFileProtectionComplete)** : Une clé dérivée du code d'accès de l'utilisateur et de l'UID de l'appareil protège cette clé de classe. La clé dérivée est effacée de la mémoire peu de temps après que l'appareil est verrouillé, rendant les données inaccessibles jusqu'à ce que l'utilisateur déverrouille l'appareil. * **Protégé sauf ouvert (NSFileProtectionCompleteUnlessOpen)** : Cette classe de protection est similaire à la ```objectivec 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 } ``` * Lors du développement de la fonctionnalité de déconnexion pour une application iOS, assurez-vous que les données du trousseau sont effacées lors de la déconnexion du compte. Cela permettra aux utilisateurs de supprimer leurs comptes avant de désinstaller une application. # **Fonctionnalités de l'application** **Chaque application a un répertoire principal unique et est isolée**, de sorte qu'elle ne peut pas accéder aux ressources système protégées ou aux fichiers stockés par le système ou par d'autres applications. Ces restrictions sont mises en œuvre via des politiques de bac à sable (alias _profils_), qui sont appliquées par le biais du [Trusted BSD (MAC) Mandatory Access Control Framework](http://www.trustedbsd.org/mac.html) via une extension de noyau. Certaines [**fonctionnalités/autorisations**](https://help.apple.com/developer-account/#/dev21218dfd6) peuvent être configurées par les développeurs de l'application (par exemple, la protection des données ou le partage de trousseau) et prendront effet directement après l'installation. Cependant, pour d'autres, **l'utilisateur sera explicitement invité la première fois que l'application tente d'accéder à une ressource protégée**. Les chaînes de but (ou _usage description strings_) sont des textes personnalisés qui sont proposés aux utilisateurs dans l'alerte de demande d'autorisation du système lorsqu'une autorisation est demandée pour accéder à des données ou des ressources protégées. ![](https://gblobscdn.gitbook.com/assets%2F-LH00RC4WVf3-6Ou4e0l%2F-Lf1APQHyCHdAvoJSvc\_%2F-Lf1AQw8W2q7BB5-il7r%2Fpermission\_request\_alert.png?alt=media) Si vous avez le code source d'origine, vous pouvez vérifier les autorisations incluses dans le fichier `Info.plist` : * Ouvrez le projet avec Xcode. * Trouvez et ouvrez le fichier `Info.plist` dans l'éditeur par défaut et recherchez les clés commençant par `"Privacy -"`. Vous pouvez passer à la vue pour afficher les valeurs brutes en faisant un clic droit et en sélectionnant "Afficher les clés/valeurs brutes" (de cette façon, par exemple, `"Privacy - Location When In Use Usage Description"` deviendra `NSLocationWhenInUseUsageDescription`). Si vous n'avez que le fichier IPA : * Décompressez le fichier IPA. * Le fichier `Info.plist` se trouve dans `Payload/.app/Info.plist`. * Convertissez-le si nécessaire (par exemple, `plutil -convert xml1 Info.plist`) comme expliqué dans le chapitre "iOS Basic Security Testing", section "The Info.plist File". * Inspectez toutes les clés Info.plist des chaînes de but, qui se terminent généralement par `UsageDescription` : ```markup NSLocationWhenInUseUsageDescription Votre emplacement est utilisé pour fournir des instructions détaillées pour vous rendre à votre destination. ``` ## Fonctionnalités de l'appareil Les fonctionnalités de l'appareil sont utilisées par l'App Store pour s'assurer que seuls les appareils compatibles sont répertoriés et donc autorisés à télécharger l'application. Elles sont spécifiées dans le fichier `Info.plist` de l'application sous la clé [`UIRequiredDeviceCapabilities`](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html#//apple\_ref/doc/plist/info/UIRequiredDeviceCapabilities). ```markup UIRequiredDeviceCapabilities armv7 ``` > En général, vous trouverez la capacité `armv7`, ce qui signifie que l'application est compilée uniquement pour l'ensemble d'instructions armv7, ou s'il s'agit d'une application universelle 32/64 bits. Par exemple, une application peut dépendre entièrement de NFC pour fonctionner (par exemple, une application "Lecteur de tag NFC"). Selon la [Référence de compatibilité des appareils iOS archivée](https://developer.apple.com/library/archive/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/DeviceCompatibilityMatrix/DeviceCompatibilityMatrix.html), NFC n'est disponible qu'à partir de l'iPhone 7 (et iOS 11). Un développeur peut vouloir exclure tous les appareils incompatibles en définissant la capacité de l'appareil `nfc`. ## Attributions > Les attributions sont des paires clé-valeur qui sont signées dans une application et permettent une authentification au-delà des facteurs d'exécution, comme l'ID utilisateur UNIX. Comme les attributions sont signées numériquement, elles ne peuvent pas être modifiées. Les attributions sont largement utilisées par les applications et les démons système pour **effectuer des opérations privilégiées spécifiques qui nécessiteraient sinon que le processus s'exécute en tant que root**. Cela réduit considérablement le potentiel d'escalade de privilèges par une application ou un démon système compromis. Par exemple, si vous souhaitez définir la capacité "Protection des données par défaut", vous devrez aller dans l'onglet **Capacités** de Xcode et activer **Protection des données**. Cela est directement écrit par Xcode dans le fichier `.attributions` en tant qu'attribution `com.apple.developer.default-data-protection` avec la valeur par défaut `NSFileProtectionComplete`. Dans l'IPA, nous pourrions trouver cela dans le `embedded.mobileprovision` comme suit : ```markup Entitlements ... com.apple.developer.default-data-protection NSFileProtectionComplete ``` Pour d'autres fonctionnalités telles que HealthKit, l'utilisateur doit donner son autorisation, il n'est donc pas suffisant d'ajouter les entitlements, des clés et des chaînes spéciales doivent être ajoutées au fichier `Info.plist` de l'application. # Bases d'Objective-C et de Swift **Objective-C** a un **runtime dynamique**, donc lorsqu'un programme Objective-C est exécuté sur iOS, il appelle des bibliothèques dont les **adresses sont résolues à l'exécution** en comparant le nom de la fonction envoyée dans le message avec une liste de tous les noms de fonctions disponibles. Au début, seules les applications créées par Apple s'exécutent sur les iPhones, donc elles avaient **accès à tout** car elles étaient **de confiance**. Cependant, lorsque Apple a **permis** les **applications tierces**, Apple a simplement supprimé les fichiers d'en-tête des fonctions puissantes pour les "cacher" aux développeurs. Cependant, les développeurs ont découvert que les fonctions "sûres" avaient besoin de quelques-unes de ces fonctions non documentées et qu'en créant un **fichier d'en-tête personnalisé avec les noms des fonctions non documentées, il était possible d'invoquer ces fonctions cachées puissantes.** En fait, avant de permettre la publication d'une application, Apple vérifie si l'application appelle l'une de ces fonctions interdites. Ensuite, Swift est apparu. Comme **Swift est lié statiquement** (il ne résout pas l'adresse des fonctions à l'exécution comme Objective-C), il est plus facile de vérifier les appels qu'un programme Swift va faire via une analyse de code statique. # Gestion des appareils À partir de la version iOS 6, il existe une **prise en charge intégrée de la gestion des appareils** avec des contrôles fins qui permettent à une organisation de contrôler les appareils Apple d'entreprise.\ L'inscription peut être **initiée par l'utilisateur installant un agent** afin d'accéder aux applications d'entreprise. Dans ce cas, l'appareil appartient généralement à l'utilisateur.\ Ou l'**entreprise peut indiquer les numéros de série** des appareils achetés ou l'identifiant de commande d'achat et spécifier le profil MDM à installer sur ces appareils. Notez qu'Apple **n'autorise pas l'inscription d'un appareil particulier de cette manière deux fois**. Une fois que le premier profil est supprimé, l'utilisateur doit donner son consentement pour en installer un autre. L'utilisateur peut voir les politiques installées dans _**Réglages**_ --> _**Général**_ --> _**Profils et gestion des appareils**_ Comme ces politiques MDM vérifient et limitent d'autres applications, elles **fonctionnent avec plus de privilèges**.\ Une politique MDM peut **forcer** les **utilisateurs** à avoir un **code d'accès** défini avec une **complexité de mot de passe minimale**.\ Les profils sont liés à l'ID de l'appareil, **signés** et **cryptés** par le serveur MDM et **à l'épreuve de la manipulation**. Ils **ne peuvent pas** être **supprimés** sans **perdre** toutes les **données d'entreprise**.\ Les profils MDM permettent de **supprimer** toutes les **données** en cas de X **tentatives** de **mot de passe** **échouées**. De plus, l'**administrateur** peut **supprimer** à distance l'iPhone à tout moment via l'interface MDM. Les agents MDM **vérifieront** également les **possibles jailbreaks de l'appareil**, car c'est un état très dangereux pour un iPhone.