hacktricks/mobile-pentesting/ios-pentesting/ios-basics.md

☁️ 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 La famille PEASS, notre collection d'NFTs exclusifs.

• 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 dépôt hacktricks et au dépôt 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.

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 :

• 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

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 via une extension de noyau.

Certaines fonctionnalités/autorisations 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.

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/<nom de l'application>.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 :

    <plist version="1.0">
    <dict>
        <key>NSLocationWhenInUseUsageDescription</key>
        <string>Votre emplacement est utilisé pour fournir des instructions détaillées pour vous rendre à votre destination.</string>
  

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.

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

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, 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 <nomdelapp>.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 :

<key>Entitlements</key>
<dict>
    ...
    <key>com.apple.developer.default-data-protection</key>
    <string>NSFileProtectionComplete</string>
</dict>

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.