mirror of https://github.com/carlospolop/hacktricks synced 2025-02-16 22:18:27 +00:00

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

2024-07-19 05:23:41 +00:00

14 KiB

Raw Blame History

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Séparation des privilèges et Sandbox

Dans iOS, une distinction de privilège existe entre les applications accessibles par l'utilisateur et les processus centraux du système. Les applications s'exécutent sous l'identité utilisateur mobile, tandis que les processus système cruciaux fonctionnent en tant que root. Cette séparation est renforcée par un mécanisme de sandbox, qui impose des limitations strictes sur les actions que les applications peuvent entreprendre. Par exemple, même si les applications partagent la même identité utilisateur, elles sont interdites d'accéder ou de modifier les données des autres.

Les applications sont installées dans un répertoire spécifique (private/var/mobile/Applications/{random ID}) et ont un accès en lecture restreint à certaines zones et fonctionnalités du système, telles que les SMS et les appels téléphoniques. L'accès aux zones protégées déclenche une demande de permission de l'utilisateur.

Protection des données

iOS offre aux développeurs les API de Protection des Données, construites sur le Secure Enclave Processor (SEP) — un coprocesseur dédié aux opérations cryptographiques et à la gestion des clés. Le SEP garantit l'intégrité de la protection des données via une clé unique spécifique à l'appareil, l'UID de l'appareil, intégrée en son sein.

Lors de la création d'un fichier, une clé de chiffrement AES unique de 256 bits est générée, chiffrant le contenu du fichier. Cette clé de chiffrement, accompagnée d'un ID de classe, est ensuite chiffrée à l'aide d'une clé de classe et stockée dans les métadonnées du fichier. Le déchiffrement d'un fichier implique d'utiliser la clé du système pour accéder aux métadonnées, de récupérer la clé de classe avec l'ID de classe, puis de déchiffrer la clé de chiffrement unique du fichier.

iOS définit quatre classes de protection pour la sécurité des données, qui déterminent quand et comment les données peuvent être accessibles :

Protection Complète (NSFileProtectionComplete) : Les données sont inaccessibles jusqu'à ce que l'appareil soit déverrouillé à l'aide du code d'accès de l'utilisateur.
Protégé Sauf Ouvert (NSFileProtectionCompleteUnlessOpen) : Permet l'accès au fichier même après que l'appareil soit verrouillé, à condition que le fichier ait été ouvert lorsque l'appareil a été déverrouillé.
Protégé Jusqu'à la Première Authentification Utilisateur (NSFileProtectionCompleteUntilFirstUserAuthentication) : Les données sont accessibles après le premier déverrouillage de l'utilisateur après le démarrage, restant accessibles même si l'appareil est à nouveau verrouillé.
Aucune Protection (NSFileProtectionNone) : Les données ne sont protégées que par l'UID de l'appareil, facilitant l'effacement rapide des données à distance.

Le chiffrement de toutes les classes, sauf pour NSFileProtectionNone, implique une clé dérivée à la fois de l'UID de l'appareil et du code d'accès de l'utilisateur, garantissant que le déchiffrement n'est possible que sur l'appareil avec le bon code d'accès. À partir d'iOS 7, la classe de protection par défaut est "Protégé Jusqu'à la Première Authentification Utilisateur".

Les développeurs peuvent utiliser FileDP, un outil pour inspecter la classe de protection des données des fichiers sur un iPhone.

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

Le Trousseau

Dans iOS, un Trousseau sert de conteneur chiffré sécurisé pour stocker des informations sensibles, accessibles uniquement par l'application qui les a stockées ou celles explicitement autorisées. Ce chiffrement est renforcé par un mot de passe unique généré par iOS, qui lui-même est chiffré avec AES. Ce processus de chiffrement utilise une fonction PBKDF2, combinant le code d'accès de l'utilisateur avec un sel dérivé de l'UID de l'appareil, un composant auquel seul le chipset de l'enclave sécurisée peut accéder. Par conséquent, même si le code d'accès de l'utilisateur est connu, le contenu du Trousseau reste inaccessible sur tout appareil autre que celui où il a été initialement chiffré.

La gestion et l'accès aux données du Trousseau sont gérés par le démon securityd, basé sur des droits d'application spécifiques comme Keychain-access-groups et application-identifier.

Opérations de l'API Trousseau

L'API Trousseau, détaillée dans la documentation des services Trousseau d'Apple, fournit des fonctions essentielles pour la gestion du stockage sécurisé :

SecItemAdd : Ajoute un nouvel élément au Trousseau.
SecItemUpdate : Met à jour un élément existant dans le Trousseau.
SecItemCopyMatching : Récupère un élément du Trousseau.
SecItemDelete : Supprime un élément du Trousseau.

La force brute du mot de passe du Trousseau implique soit d'attaquer directement la clé chiffrée, soit d'essayer de deviner le code d'accès sur l'appareil lui-même, ce qui est considérablement entravé par l'application d'un délai entre les tentatives échouées par l'enclave sécurisée.

Configuration de la Protection des Données des Éléments du Trousseau

Les niveaux de protection des données pour les éléments du Trousseau sont définis à l'aide de l'attribut kSecAttrAccessible lors de la création ou de la mise à jour de l'élément. Ces niveaux, comme spécifié par Apple, déterminent quand et comment les éléments du Trousseau sont accessibles :

kSecAttrAccessibleAlways : Accessible à tout moment, indépendamment de l'état de verrouillage de l'appareil.
kSecAttrAccessibleAlwaysThisDeviceOnly : Toujours accessible, mais non inclus dans les sauvegardes.
kSecAttrAccessibleAfterFirstUnlock : Accessible après le premier déverrouillage après un redémarrage.
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly : Même que ci-dessus, mais non transférable à de nouveaux appareils.
kSecAttrAccessibleWhenUnlocked : Accessible uniquement lorsque l'appareil est déverrouillé.
kSecAttrAccessibleWhenUnlockedThisDeviceOnly : Accessible lorsqu'il est déverrouillé, non inclus dans les sauvegardes.
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly : Nécessite le code d'accès de l'appareil, non inclus dans les sauvegardes.

AccessControlFlags affinent encore les méthodes d'accès, permettant l'authentification biométrique ou l'utilisation du code d'accès.

Avertissement sur les Appareils Jailbreakés

{% hint style="warning" %} Sur les appareils jailbreakés, les protections du Trousseau sont compromises, posant un risque de sécurité significatif. {% endhint %}

Persistance des Données du Trousseau

Contrairement aux données spécifiques à l'application supprimées lors de la désinstallation de l'application, les données du Trousseau persistent sur l'appareil. Cette caractéristique pourrait permettre aux nouveaux propriétaires d'un appareil d'occasion d'accéder aux données d'application de l'ancien propriétaire simplement en réinstallant les applications. Il est conseillé aux développeurs de nettoyer proactivement les données du Trousseau lors de l'installation de l'application ou lors de la déconnexion pour atténuer ce risque. Voici un exemple de code Swift démontrant comment effacer les données du Trousseau lors du premier lancement de l'application :

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
}

Capacités de l'Application

Dans le domaine du développement d'applications, sandboxing joue un rôle crucial dans l'amélioration de la sécurité. Ce processus garantit que chaque application fonctionne dans son propre répertoire personnel unique, empêchant ainsi l'accès aux fichiers système ou aux données appartenant à d'autres applications. L'application de ces restrictions est effectuée par le biais de politiques de sandbox, qui font partie du Trusted BSD (MAC) Mandatory Access Control Framework.

Les développeurs ont la possibilité de configurer certaines capacités ou autorisations pour leurs applications, telles que Data Protection ou Keychain Sharing. Ces autorisations sont appliquées immédiatement après l'installation de l'application. Néanmoins, pour accéder à certaines ressources protégées, l'application doit obtenir le consentement explicite de l'utilisateur au moment de la première tentative. Cela se fait par l'utilisation de purpose strings ou usage description strings, qui sont présentées aux utilisateurs dans une alerte de demande d'autorisation.

Pour ceux ayant accès au code source, la vérification des autorisations incluses dans le fichier Info.plist peut être effectuée en :

Ouvrant le projet dans Xcode.
Localisant et ouvrant le fichier Info.plist.
Cherchant des clés préfixées par "Privacy -", avec l'option de visualiser les clés/valeurs brutes pour plus de clarté.

Lorsqu'il s'agit d'un fichier IPA, les étapes suivantes peuvent être suivies :

Décompresser l'IPA.
Localiser le fichier Info.plist dans Payload/<appname>.app/.
Convertir le fichier au format XML si nécessaire, pour une inspection plus facile.

Par exemple, les purpose strings dans le fichier Info.plist pourraient ressembler à ceci :

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

Capacités de l'appareil

Le fichier Info.plist d'une application spécifie les capacités de l'appareil qui aident l'App Store à filtrer les applications pour la compatibilité des appareils. Celles-ci sont définies sous la clé UIRequiredDeviceCapabilities. Par exemple :

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

Cet exemple indique que l'application est compatible avec l'ensemble d'instructions armv7. Les développeurs peuvent également spécifier des capacités comme nfc pour s'assurer que leur application n'est disponible que sur des appareils prenant en charge NFC.

Droits

Les droits sont un autre aspect critique du développement d'applications iOS, servant de paires clé-valeur qui accordent aux applications la permission d'effectuer certaines opérations au-delà des vérifications d'exécution. Par exemple, activer la protection des données dans une application implique d'ajouter un droit spécifique dans le projet Xcode, qui est ensuite reflété dans le fichier de droits de l'application ou le fichier de provisionnement mobile intégré pour les IPA.

Références