Application mobile: Mobile DevSecOps est la voie vers la sécurité mobile

Points clés à retenir

  • Les applications s vivent et fonctionnent dans des environnements non fiables, mais elles contiennent des données précieuses et tout ce dont elles ont besoin pour fonctionner est inclus dans l’application ou facile à dériver.
  • La grande majorité des applications s sont très faciles à compromettre car a) elles manquent de fonctionnalités de de base ou b) la est implémentée de manière superficielle et donc facile à contourner à l’aide d’outils disponibles gratuitement et de techniques de rétro-ingénierie de base.
  • Afin de sécuriser les applications s, une défense de multicouche et complète est requise, comprenant généralement les éléments suivants, où chacune des protections ci-dessous complète et renforce les autres :
    • Application Shielding/RASP : Protège contre les attaques dynamiques, le débogage malveillant, la falsification, l’émulation, etc.
    • Obfuscation du code – Rend le code ou la logique de l’application difficile à comprendre
    • Cryptage des données Protège les données stockées ou utilisées par l’application, y compris les données dans le bac à sable de l’application, ainsi que dans les chaînes, les préférences et de nombreux autres endroits où les données sont stockées dans le code.
    • Communication sécurisée – Protège les données en transit et protège la chaîne de confiance de l’application
    • Prévention du jailbreak/rooting – Protège les applications contre la compromission de l’environnement dans lequel l’application s’exécute.
  • La grande majorité des solutions/outils de des applications s nécessitent que les développeurs d’applications s effectuent une quantité importante de travail de manuel ou de modifications du code source. Ces outils incluent : des SDK s, des bibliothèques de open source, des compilateurs ou des obfuscateurs spécialisés ou des solutions spécifiques à un langage de programmation.
  • Aucune de ces solutions de ne s’intègre dans la manière dont les applications s sont construites aujourd’hui, qui sont rapides, continues et automatisées.
  • Afin de briser ce cycle de mauvaise des applications, la des applications s doit être automatisée, rapide, continue et itérative, ainsi que garantie et auditable. En d’autres termes, la des applications s doit évoluer pour s’adapter à la façon dont les développeurs créent des applications et non l’inverse.

Dans mon entreprise, nous analysons souvent les applications s à la demande de nos clients (entreprises du Fortune 500) pour les aider à évaluer leurs failles de via des tests d’intrusion en boîte noire. Ce que nos chercheurs en trouvent est assez troublant. Presque toutes les applications sur lesquelles nous effectuons des évaluations de peuvent être compromises dans les 15 minutes en raison d’un manque de bonnes pratiques de de base.

Ce n’est pas que les développeurs d’applications s ne mettent en œuvre aucune mesure de – certains essaient. Mais l’état de la des applications s n’est toujours pas solide, et vous n’avez pas à me croire sur parole. Le Verizon Security Index 2021 montre que 76% des personnes interrogées ont déclaré avoir cédé à la pression et sacrifié la d’une manière ou d’une autre. Et ce manque de est évident dans la facilité avec laquelle les applications peuvent être compromises.

Nous constatons les mêmes lacunes de base dans chaque application Android et iOS que nous testons. Nous trouvons que la des applications s est totalement absente ou implémentée de manière superficielle (et donc facilement contournée). Dans les deux cas, cela laisse les applications vulnérables aux compromis sans trop de temps ni d’efforts, en utilisant des techniques de rétro-ingénierie de base et des outils open source disponibles gratuitement.

Dans cet article, je vais discuter de certaines des lacunes de les plus courantes que nous rencontrons et expliquer les risques potentiels pour les consommateurs s, les développeurs d’applications et les marques.

Cryptage insuffisant et manque de protection des données

L’un des plus gros problèmes que nous trouvons est un manque général de cryptage des données. Le cryptage des données est l’une des méthodes les plus importantes pour protéger les données sensibles stockées ou utilisées par l’application ou les utilisateurs. Les problèmes courants que nous trouvons dans nos tests vont de l’échec du chiffrement des chaînes, des ressources, des valeurs par défaut, des préférences et d’autres données sensibles stockées dans le code. Ou si le cryptage est utilisé, nous trouvons souvent des implémentations incohérentes ou incomplètes, l’utilisation d’algorithmes non sécurisés ou obsolètes, des suites de chiffrement faibles, la dérivation et la signature de clés, ou des valeurs codées en dur stockées dans l’application. Toute combinaison de ces éléments peut laisser des données sensibles exposées ou stockées de manière non sécurisée dans l’application, tout en facilitant la compromission, la falsification ou la modification malveillante de l’application.

Communications non sécurisées

Un autre sujet de préoccupation est que la plupart des applications s ne protègent pas suffisamment les données en transit lorsqu’elles circulent sur un réseau. Il existe de nombreuses façons de compromettre une session , entraînant une fuite ou un vol de données. Les meilleures pratiques de base en matière de des applications s, telles que le Top 10 de l’OWASP, appellent à la protection des sessions s en utilisant un cryptage fort des données en transit, en sécurisant les communications API et en garantissant l’authenticité et la validité de la chaîne de confiance numérique (CA et certificats numériques) , Juste pour en nommer quelques-uns. Nous trouvons que le modèle de de la plupart des applications est insuffisant dans ces domaines.

Parfois, les déficiences prennent la forme d’API mal implémentées qui exposent plus d’informations que nécessaire dans les appels d’API, ou l’utilisation d’une transmission non sécurisée (SSL vs TLS). D’autres fois, nous constatons que les applications ne parviennent pas à inspecter les certificats proposés par un serveur, ou que les certificats peuvent être facilement falsifiés, échangés ou autrement manipulés. Dans chaque cas, les données sont vulnérables lorsqu’elles traversent le réseau.

L’échec du chiffrement des données de bout en bout ou les faiblesses du modèle de chiffrement exposent les applications aux menaces suivantes :

  • Piratage de session ou redirection vers des proxys, des points de terminaison, des sites Web ou des serveurs malveillants
  • Vol de données, vol d’identifiants, collecte de noms d’utilisateur/mots de passe
  • Récolter des clés API pour accéder à des serveurs sensibles, infiltrer le backend ou mener des attaques de bourrage d’informations d’identification
  • Attaques de l’homme du milieu (MitM), usurpation d’identité
  • Phishing, diffusion de logiciels malveillants

Défaut d’empêcher l’ingénierie inverse et la falsification

Le prochain domaine d’exposition majeur est que la plupart des applications s manquent de protection et d’obscurcissement des applications – deux des moyens les plus importants de protéger l’application et le code source contre la rétro-ingénierie malveillante et la falsification.

Le code non obscurci permet aux attaquants de comprendre facilement le fonctionnement d’une application en lisant simplement le code source. Ils utilisent ces informations pour lancer des attaques contre des applications ou pour voler des données utilisateur. Voici quelques exemples de scénarios d’attaque sur la façon dont cela est fait :

  • Utilisez des désassembleurs comme Hopper, IDA-Pro ou Ghidra pour analyser le code iOS et modifier les valeurs d’une application stockées en mémoire.
  • Recherchez des chaînes dans le code source des applications Android ou iOS pour localiser les données utilisateur sensibles stockées non cryptées dans strings.xml dans les applications Android ou CFStrings, NSUserDefaults dans les applications iOS. De telles pratiques peuvent être utilisées pour voler/récolter des données ainsi que pour comprendre comment les données sont partagées ou externalisées avec des systèmes critiques en aval.
  • Analysez le manifeste Android pour comprendre les autorisations, les intentions de l’application, la façon dont l’application partage des données avec d’autres applications ou pour en savoir plus sur la façon dont l’application est signée. Ces informations aident les cybercriminels à créer des logiciels malveillants qui abusent, imitent ou usurpent l’identité des fonctionnalités courantes des applications ou des systèmes d’exploitation. Ils peuvent également créer des clones ou des contrefaçons en abusant des méthodes de signature de code.
  • Analysez les fichiers DEX pour localiser, comprendre ou compromettre les classes d’applications ou les workflows de grande valeur. Dans les applications Android, les fichiers DEX sont des classes Java exécutables dans le flux de contrôle (logique) de l’application. Par exemple, les pirates peuvent analyser le flux de contrôle d’une application pour comprendre la logique métier d’un système de traitement des paiements en traçant les appels de méthode ou de fonction dans le code source d’une classe d’application qui gère les paiements intégrés.
  • Les pirates informatiques attachent régulièrement des débogueurs aux applications dans le but de comprendre comment l’application exécute certaines fonctions, ou pour planter l’application volontairement à un moment donné afin d’analyser les vidages sur incident ou les traces de pile.

L’obscurcissement du code est l’une des principales méthodes pour empêcher l’analyse de code statique. L’obscurcissement est la pratique consistant à masquer le code source et la logique de l’application pour empêcher les attaquants de comprendre la signification, l’intention ou la fonction du code source, y compris la façon dont il exécute les instructions ou la logique. L’obscurcissement, associé au blindage des applications, est considéré comme deux des « premières lignes de défense » les plus importantes contre l’inversion malveillante (à la fois statique et dynamique).

Il existe de nombreuses techniques pour brouiller le code, et une solution complète nécessite la mise en œuvre de plusieurs techniques qui se complètent et se renforcent (afin que les protections ne puissent pas être contournées ou contournées).

Une solution d’obscurcissement robuste nécessite la protection du code et des bibliothèques natifs et non natifs, y compris le chiffrement des chaînes et des ressources, le chiffrement des préférences de l’application et des valeurs par défaut de l’utilisateur. En outre, il est également important d’obscurcir les flux de contrôle d’une application et de protéger le code exécutable (logique d’application, fichiers DEX), y compris des techniques aussi diverses que l’insertion de code factice, le remplacement des cibles d’appel de fonction, l’insertion de chemins arbitraires dans le flux ou la création de l’arborescence des fonctions. sembler rompu aux attaquants en cachant le chemin du code d’origine dans un emplacement crypté. Et enfin, il est toujours recommandé de supprimer les informations de débogage, afin que les pirates ne puissent pas passer au crible les traces de la pile et comprendre facilement le comportement de l’application.

Du côté dynamique, il est important de se protéger contre le débogage malveillant, la falsification, les émulateurs/simulateurs, toute autre analyse ou modification indésirable d’une application pendant son exécution.

Absence de Jailbreak/Prévention de l’enracinement

Un autre domaine de faiblesse des applications s est le manque de protection contre l’exécution dans des environnements dangereux.

Les pirates exécutent souvent des applications sur des appareils jailbreakés/enracinés, car cela leur permet d’élever les privilèges d’administrateur ou de modifier des fichiers système de bas niveau, tous utilisés pour compromettre l’application ou les données ou prendre le contrôle de l’application ou de l’environnement. Le jailbreak/rooting permet aux pirates d’attaquer plus facilement les applications s et de faire beaucoup plus de dégâts ou d’utiliser des outils/fonctionnalités plus puissants pour compromettre l’application.

Par exemple, ils peuvent contourner ou désactiver la défense existante d’une application (par exemple, désactiver l’anti-falsification ou désactiver les SDK de défense contre les menaces). Ou ils peuvent modifier les signaux entrant ou sortant de l’application, changer le chemin d’exécution du code, ou même supprimer le code ou le remplacer par leur propre implémentation malveillante.

Des outils avancés de jailbreak et de masquage de racine tels que Checkra1n (iOS) et Magisk (Android) sont généralement utilisés pour contourner les techniques de détection, masquer le fait que le système d’exploitation a été compromis et élever/gérer les privilèges root pour les logiciels malveillants ou d’autres applications malveillantes.

Il est essentiel que les applications s disposent de protections intégrées contre ces techniques, méthodes et outils. Et les protections doivent être mises en œuvre à plusieurs couches dans le code et fonctionner de concert avec d’autres fonctionnalités du modèle de de l’application (afin qu’elles ne puissent pas être contournées facilement).

Manque de protection contre l’instrumentation dynamique et l’injection de code

Enfin, au sommet de la chaîne alimentaire des pirates se trouvent des cadres d’instrumentation dynamiques très puissants comme Frida, que les cybercriminels utilisent pour se connecter à des applications, découvrir et s’attacher à des processus en cours, injecter ou modifier le code ou la mémoire d’une application pendant l’exécution, ou modifier le comportement d’une application. en utilisant des techniques telles que l’accrochage de fonction ou le swizzling de méthode.

Les mauvais acteurs utilisent ces techniques pour une pléthore d’actions malveillantes, telles que la prise de contrôle de compte, la compromission de sites de commerce électronique ou l’infiltration du backend d’une application à l’aide d’une combinaison de chevaux de Troie, de click-bots, de RAT, de botnets et d’autres formes de logiciels malveillants conçus pour abuser des fonctionnalités légitimes d’une application ou d’un système d’exploitation, se faire passer pour des applications ou des entités de confiance et inciter les utilisateurs s à effectuer des actions nuisibles par inadvertance.

Pourquoi les approches de traditionnelles ne fonctionnent pas dans les applications s

Pour parvenir à une défense multicouche, les meilleures pratiques de minimales sont le blindage des applications, l’anti-falsification, l’obscurcissement du code, le cryptage des données (y compris les chaînes, les ressources, les préférences), la prévention du jailbreak/rooting et la prévention de l’homme du milieu. (comme l’épinglage de certificat ou la validation de certificat). Il existe des SDK commerciaux et des bibliothèques tierces disponibles pour les développeurs qui souhaitent adopter une approche DIY. Mais fondamentalement, ces approches nécessitent souvent un travail de important et introduisent des cadres supplémentaires ou des dépendances et des incompatibilités de langage de programmation.

Permettez-moi de faire valoir mon point en utilisant le cryptage comme exemple. Supposons que vous vouliez implémenter le cryptage des données à l’aide de bibliothèques ou de SDK tiers. Il existe des dépendances de structure de données : différents types de données ont des sensibilités variables à la latence. L’endroit où vous stockez les données limitera également vos choix sur le modèle de cryptage que vous utilisez. La fréquence à laquelle les données doivent être consultées et par quoi/qui/quand les données doivent être disponibles est également un défi.

Ensuite, il y a le modèle de chiffrement lui-même : quel algorithme convient à vos données ? Comment valider les exigences de ou les caractéristiques de performance de l’algorithme pour vos divers types de données ? Ensuite, il y a les dépendances du langage de programmation : les bibliothèques de chiffrement Android ou les SDK pour Java peuvent ne pas fonctionner pour Kotlin. Il y a la couche native C ou C++, qui nécessiterait encore une autre implémentation.

Sous iOS, même accord. Vous pouvez visiter StackOverflow et constater qu’un cryptokit commun pour Swift ne fonctionnera pas pour Objective C.

Les applications non natives sont un jeu de balle totalement différent car vous avez affaire à des technologies Web telles que JavaScript, HTML5, CSS et des frameworks non natifs tels que React Native, Cordova, Flutter ou Xamarin qui ne fonctionneront pas immédiatement (ou pas du tout ) avec des SDK ou des bibliothèques conçues pour les langues natives.

Enfin, il y a la gestion des clés. Comment dérivez-vous les clés, quelle force de clé devez-vous utiliser et, surtout, où stockez-vous les clés de chiffrement ?

Et je pourrais continuer pendant des jours. Sans oublier que chacune des décisions ci-dessus peut avoir un impact considérable sur les performances, la convivialité et la de l’application, dont vous ne saurez jamais l’étendue tant que vous n’aurez pas fait le  !

Et ce n’est qu’une fonction de : le cryptage ! Pour mettre en œuvre une défense multicouche à l’aide de SDK ou de bibliothèques tierces, il faudrait de nombreux SDK (au moins deux ou plus pour couvrir chacune des catégories que j’ai décrites ci-dessus). Chaque SDK pourrait être son propre projet de , nécessitant un codage manuel, des ressources spécialisées, un travail de par essais et erreurs. Chaque SDK introduirait son propre framework et ses propres dépendances de langage de programmation, qui peuvent en fait entrer en conflit les uns avec les autres.

Alors, comment les développeurs s peuvent-ils résoudre ce problème apparemment insoluble ? La réponse réside dans l’automatisation de la des applications s.

Le problème : la des applications s traditionnelles ne convient pas à

Bien qu’il existe de nombreuses raisons pour lesquelles les applications ne sont pas aussi sécurisées qu’elles devraient l’être, la racine du problème réside dans la manière dont les applications s sont développées, publiées et mises à jour dans une organisation moderne.

Les fossés entre la et s’étendent à travers les cultures organisationnelles, les workflows, les ensembles d’outils et les produits. En termes simples, Dev et Ops opèrent dans un monde où tout est dynamique, automatisé, , intégré, itératif et continu. Le monde traditionnel de la des applications s est à l’opposé : statique (définir et oublier), manuel (codage ligne par ligne), monolithique. Vous ne pouvez pas prendre un processus manuel laborieux ( traditionnelle, approches basées sur le SDK) et essayer de bricoler un cadre de défense complet et multicouche par cadre, ligne par ligne, SDK par SDK, plugin par plugin. Un processus monolithique manuel ne s’intégrera jamais dans un modèle de livraison , peu importe comment essayer de le découper.

La véritable promesse de réside dans la rapide des applications s (RMAS), fournie en tant qu’élément fondamental d’un processus de publication , où la est intégrée au processus à chaque phase du cycle de vie et où les fonctionnalités de ou le modèle de peut être fourni et évolué de manière atomique, itérative et dynamique – d’une manière qui correspond aux caractéristiques spécifiques et uniques de l’application elle-même. En d’autres termes, le modèle de s’adapte à l’application (et non l’inverse).

La voie à suivre pour la des applications s est l’automatisation, ce qui a rendu possible en premier lieu. En appliquant l’IA et le ML, l’industrie peut créer des implémentations de automatisées qui permettront véritablement , permettant aux développeurs, aux opérateurs et aux professionnels de la de fournir des applications sécurisées à temps dans un cycle de vie et de publication d’applications , rapide et itératif ! C’est ce que j’appelle Security Release Management.

A propos de l’auteur

Application mobile: Mobile DevSecOps est la voie vers la sécurité mobileAlain Bavosa est vice-président des produits de chez Appdome, où il aide les clients à identifier et à combler les lacunes de dans leurs applications Android et iOS. Avant de rejoindre Appdome, Alan était vice-président des produits chez Palerra, une société d’automatisation de la dans le cloud acquise par Oracle, et responsable mondial des produits chez ArcSight, une société SEIM et de gestion des journaux qui a ensuite été acquise par HP.

.

# # #est #voie #vers # #