Liens vers toutes les parties:Partie 1. Accès initial à un appareil mobile (accès initial)Partie 2. Persistance et escaladePartie 3. Obtention de l'accès aux informations d'identification (accès aux informations d'identification)Partie 4. Évasion de la défensePartie 5. Découverte et mouvement latéralLes cybercriminels utilisent des méthodes de contournement des outils de protection pour éviter la détection de leur activité malveillante ou en combinaison avec d'autres techniques d'attaque pour atteindre certains objectifs tactiques en raison de l'atteinte à une protection spécifique. Ainsi, l'évasion de défense peut être considérée comme un ensemble de techniques utilisées par l'ennemi à toutes les étapes de l'attaque.
L'auteur n'est pas responsable des conséquences possibles de l'application des informations énoncées dans l'article, et s'excuse également pour d'éventuelles inexactitudes faites dans certaines formulations et termes. Les informations publiées sont une nouvelle version gratuite du contenu de ATT @ CK Mobile Matrices: Device Access .Plateforme: Android, iOS
Description: les attaquants peuvent essayer d'identifier toutes les applications installées sur l'appareil afin d'identifier la disponibilité de mesures de sécurité susceptibles d'augmenter le risque de détection, ou vice versa - d'identifier les applications qui seront ciblées par une nouvelle attaque.
Les applications Android peuvent utiliser la méthode de classe PackageManager pour répertorier d'autres applications ou un autre objet de ligne de commande pour utiliser la commande pm. Les applications iOS peuvent utiliser des appels d'API privés pour obtenir une liste des applications installées sur l'appareil. Cependant, la distribution d'une application à l'aide d'appels d'API privés via l'AppStore est probablement impossible.
Recommandations de protection: les méthodes de vérification des applications Android doivent inclure des moyens de détecter l'utilisation de la classe PackageManager par les applications pour répertorier d'autres applications à des fins d'analyse supplémentaire. Cependant, cette approche peut ne pas être pratique car de nombreuses applications peuvent appeler les méthodes de la classe PackageManager dans le cadre de leur travail normal. Sur iOS, les méthodes de validation peuvent également rechercher des appels d'API privés, mais il est important de noter qu'une application utilisant des appels d'API privés ne sera probablement pas acceptée dans l'AppStore.
Plateforme: Android, iOS
Description: un adversaire peut utiliser la connaissance des algorithmes de sécurité pour éviter la détection. Par exemple, certains outils de sécurité des appareils mobiles détectent un compromis en identifiant des artefacts spécifiques, tels que le binaire su installé, mais vous pouvez contourner cette vérification en nommant le binaire différemment. Un adversaire peut utiliser un code polymorphe pour éviter la détection par analyse de signature.
Plateforme: Android, iOS
Description: afin d'éviter la détection de code malveillant lors des vérifications dans un environnement d'entreprise ou un magasin d'applications à l'aide de méthodes d'analyse de code statique (éventuellement dynamique), une application malveillante peut télécharger et exécuter du code dynamique (non inclus dans le package d'application) après son installation.
Dans Android, le code dynamique peut inclure du code natif, du code Dalvik ou du code JavaScript qui utilise la fonction JavascriptInterface Android WebView. IOS a également des méthodes pour exécuter du code dynamique chargé après l'installation de l'application.
Recommandations de protection: les technologies de vérification des applications (analyse statique et dynamique) peuvent détecter des signes que l'application charge du nouveau code lors de l'exécution (par exemple, dans Android, elle utilise DexClassLoader, System.load ou WebView JavaScryptInterface, dans iOS, elle utilise JSPatch ou des fonctionnalités similaires). Malheureusement, il ne s'agit que d'une méthode partielle d'atténuation des risques, car les applications identifiées nécessiteront une vérification supplémentaire en raison du fait que ces méthodes sont souvent utilisées par les développeurs sans intention malveillante, et également parce que les applications peuvent utiliser d'autres méthodes, telles que le masquage. Utilisation de méthodes de chargement de code lors de l'exécution.
Plateforme: Android, iOS
Description: un adversaire peut essayer d'installer une configuration dangereuse ou malveillante sur un appareil mobile en utilisant un message de phishing ou un message texte contenant un fichier de configuration en pièce jointe ou un lien Web vers les paramètres de configuration. Lors de la définition des paramètres de configuration, l'utilisateur peut être trompé en utilisant des méthodes d'ingénierie sociale. Par exemple, en définissant une configuration, un certificat indésirable d'une autorité de certification (CA) peut être placé dans le magasin de certificats de confiance de l'appareil, ce qui augmentera la vulnérabilité de l'appareil aux attaques des personnes du milieu.
Sur iOS, les profils de configuration malveillants peuvent contenir des certificats d'autorité de certification (CA) indésirables ou d'autres paramètres non sécurisés, tels que l'adresse d'un proxy ou d'un serveur VPN indésirable pour acheminer le trafic de l'appareil via un système d'attaque ou enregistrer l'appareil cible avec un système de gestion d'appareil mobile (MDM) ennemi.
Recommandations de protection: dans iOS 10.3 et versions ultérieures, une étape supplémentaire est ajoutée qui oblige l'utilisateur à effectuer certaines actions pour installer de nouveaux certificats de CA de confiance. Les applications Android compatibles avec Android 7 et supérieur (API niveau 24), par défaut, ne font confiance qu'aux certificats d'autorité de certification fournis avec le système d'exploitation, et non ajoutés par l'utilisateur ou l'administrateur, ce qui réduit leur vulnérabilité aux attaques de l'homme du milieu.
En général, les paramètres de configuration dangereux ou malveillants ne sont pas définis sans le consentement de l'utilisateur. Les utilisateurs ne doivent pas définir de paramètres de configuration inattendus (certificats CA, profils de configuration iOS, connexions MDM).
Sur Android, un utilisateur peut afficher les certificats d'autorité de certification approuvés via les paramètres de l'appareil pour identifier les certificats suspects. De même, les protections des appareils mobiles peuvent rechercher des anomalies dans les magasins de certificats. Sur iOS, un utilisateur peut afficher les profils de configuration installés via les paramètres de l'appareil et identifier les profils suspects. De même, les systèmes MDM peuvent utiliser l'API iOS MDM pour vérifier les listes de profils installés pour les anomalies.
Plateforme: Android, iOS
Description: Nommez une opportunité d'augmenter les privilèges, un adversaire peut essayer de placer du code malveillant dans le noyau du système d'exploitation ou des composants de la partition de démarrage, où le code ne peut pas être détecté, sera enregistré après le redémarrage de l'appareil et ne pourra pas être supprimé par l'utilisateur. Dans certains cas (par exemple, Samsung Knox), une attaque peut être détectée, mais entraînera le transfert de l'appareil en mode de fonctionnalité limitée.
De nombreux appareils Android offrent la possibilité de déverrouiller le chargeur de démarrage à des fins de développement, mais cette fonctionnalité offre la possibilité de mettre à jour de manière malveillante le noyau ou un autre code de partition de démarrage. Si le chargeur de démarrage n'est toujours pas déverrouillé, il reste alors la possibilité potentielle d'utiliser des vulnérabilités pour mettre à jour le code du noyau.
Recommandations de protection: dans un environnement d'entreprise, organisez l'installation de mises à jour de sécurité, l'introduction de la certification à distance des appareils mobiles (Android SafetyNet, Samsung KNOX TIMA), et empêchez également les appareils qui n'ont pas passé la certification d'accéder aux ressources de l'entreprise. Vérifiez l'état de verrouillage du chargeur de démarrage sur les appareils qui permettent de déverrouiller le chargeur de démarrage (permettant ainsi d'écrire n'importe quel code de système d'exploitation sur l'appareil).
L'API d'attestation Android SafetyNet peut être utilisée pour identifier et répondre à distance aux appareils compromis. Samsung KNOX offre des capacités de certification à distance sur les appareils Android Samsung pris en charge. Les appareils Samsung KNOX incluent un fusible bit irréversible qui fonctionnera si un noyau non KNOX est chargé sur l'appareil. Lorsqu'ils sont déclenchés, les services de conteneur KNOX d'entreprise ne sont pas disponibles sur l'appareil.
Comme décrit dans le Guide de sécurité iOS, les appareils iOS ne peuvent pas démarrer ou autoriser l'activation de l'appareil si des modifications non autorisées sont détectées. De nombreuses applications d'entreprise effectuent leurs propres vérifications pour détecter et répondre aux appareils compromis. Ces contrôles ne sont pas un moyen fiable, mais ils peuvent détecter les principaux signes de compromis.
Plateforme: Android, iOS
Description: si l'adversaire augmente les privilèges, il pourra les utiliser pour placer du code malveillant dans la section système de l'appareil, où le code sera enregistré après le redémarrage du système d'exploitation et ne sera pas facilement accessible pour être supprimé par l'utilisateur. De nombreux appareils Android vous permettent de déverrouiller le chargeur de démarrage à des fins de développement. Cette fonctionnalité peut également être utilisée par un adversaire pour modifier une partition système.
Recommandations de protection: les appareils Android avec prise en charge du démarrage vérifié effectuent une vérification cryptographique de l'intégrité de la partition système. L'API Android SafetyNet peut être utilisée pour identifier les appareils compromis. Samsung KNOX fournit également des capacités de contrôle à distance sur les appareils pris en charge. Les appareils IOS ne démarreront pas ou ne permettront pas l'activation d'un appareil dans lequel des modifications non autorisées sont détectées.
Plateforme: Android
Description: avec les privilèges appropriés, un attaquant peut tenter de placer du code malveillant dans un runtime de confiance (TEE) ou un autre runtime isolé similaire, où le code n'est pas détectable, sera enregistré après le redémarrage de l'appareil et ne pourra pas être supprimé par l'utilisateur. L'exécution de code dans TEE fournira à un adversaire la possibilité de contrôler ou de falsifier le fonctionnement de l'appareil.
Conseils de sécurité: les appareils doivent effectuer des vérifications d'intégrité sur le code qui s'exécute dans TEE au démarrage. iOS ne démarre pas si le code exécuté dans Secure Enclave échoue à la vérification de la signature numérique.
Plateforme: Android, iOS
Description: un développeur d'applications malveillantes peut appliquer des méthodes d'obscurcissement ou de chiffrement du code désobfusculé et déchiffré lors de l'exécution de l'application sur le périphérique cible.
Recommandations de protection: les outils de vérification des applications peuvent avertir de la présence de code obscurci ou chiffré dans les applications. Malheureusement, ces vérifications sont inefficaces, car de nombreuses applications utilisent l'obscurcissement et le chiffrement pour se protéger contre les techniques de modification, telles que le reconditionnement de l'application. Dans certains cas, l'analyse dynamique peut identifier le code obscurci ou chiffré en le détectant au moment de l'exécution en texte clair. Certains outils de vérification des applications utilisent l'analyse de la réputation des développeurs et peuvent avertir des applications potentiellement dangereuses sans réellement analyser le code.