Afin de concevoir une application sécuriséeVous devez faire confiance à l'infrastructure sur laquelle l'application est construite. Qu'il s'agisse d'une application et de son système d'exploitation, d'un micrologiciel et de son matériel, ou d'une page web dans un navigateur, que se passe-t-il lorsque cette infrastructure n'est pas sécurisée ?   

R – La résilience est un sujet important dans le MASVS, et certains considèrent le « R » comme une recommandation. Digital.ai Nous pensons que la résilience constitue le véritable fondement de la sécurité dans un environnement par ailleurs vulnérable. Le niveau « R » est essentiel à la protection du niveau de sécurité standard L1. Pourquoi ? Parce que les mesures de sécurité standard décrites au niveau L1 sont trop facilement contournées lorsque les applications sont exécutées dans des environnements non sécurisés. Ces environnements incluent les appareils mobiles jailbreakés ou rootés, les émulateurs, et même les appareils infectés par des logiciels malveillants. Tous ces environnements sont courants. En effet, une méta-analyse portant sur des millions d'instances d'applications… Digital.ai En matière de protection, nous avons constaté que chaque semaine, plus de la moitié des applications que nous protégeons sont mises en danger.safe environnements. 

Dans le prochain article de blog, nous aborderons les exigences en matière de résilience et la manière de les satisfaire grâce à outils d'obfuscation de code, de surveillance et RASPNous partagerons également des analyses et des points de vue sur les recommandations de sécurité de niveau 1 (L1), leurs vecteurs d'attaque correspondants et les moyens de les atténuer. Enfin, nous aborderons les difficultés rencontrées lorsque les ingénieurs applicatifs se contentent de suivre les recommandations L1. Nous commencerons par les exigences de haut niveau, ou exigences de « résilience », décrites dans le MASVS.  

Qu'est-ce que MASVS ?

Le Mobile Application Security Norme de vérificationMASVS, ou « MASVS », est une liste compilée de différentes recommandations couvrant de multiples domaines tels que la mise en réseau, le stockage, l’intégrité, etc. Ces recommandations sont classées en 3 modèles principaux : 

• MASVS-L1 – Sécurité standard : Elle intègre les meilleures pratiques de sécurité, telles que la qualité du code, la gestion des données sensibles et l'interaction avec l'environnement mobile. 
• MASVS-L2 – Défense en profondeur : Ce modèle comprend tout ce qui est inclus dans MASVS-L1, plus des recommandations supplémentaires basées sur le modèle de menace pour des secteurs tels que la banque et la santé qui traitent des données particulièrement sensibles. 
• MASVS-R – Résilience face à la rétro-ingénierie et à la falsification : Protection contre les attaques spécifiques côté client, telles que la falsification et le modding, ou par rétro-ingénierie.

Comment satisfaire aux exigences de résilience  

MSTG-RESILIENCE-1  

L'application détecte la présence d'un appareil rooté ou jailbreaké et réagit en alertant l'utilisateur ou en fermant l'application. 

Digital.ai Sécurité des applications Il détecte de nombreuses méthodes sophistiquées de rootage et de jailbreak. Il est même capable de détecter des altérations au sein même du code du système d'exploitation. 

MSTG-RESILIENCE-2  

L'application empêche le débogage et/ou détecte et réagit à la connexion d'un débogueur. Tous les protocoles de débogage disponibles doivent être pris en charge.  

Digital.ai App Security offre une protection complète contre les débogueurs. 

MSTG-RESILIENCE-3  

L'application détecte et réagit à toute altération des fichiers exécutables et des données critiques au sein de son propre environnement isolé. 

Les bibliothèques de cryptographie open source telles qu'OpenSSL et Mbed-TLS sont faciles à détecter pour les attaquants. Nos protections offrent un arsenal de cryptographie en boîte blanche algorithmes utilisant une implémentation propriétaire, Digital.ai Les clients peuvent mettre en œuvre efficacement des contrôles d'intégrité sans laisser de traces identifiables par les attaquants. 

MSTG-RESILIENCE-4  

L'application détecte et réagit à la présence d'outils et de frameworks de rétro-ingénierie largement utilisés sur l'appareil. 

Digital.ai Application Security détecte la présence de boîtes à outils d'instrumentation dynamique, de frameworks et d'outils de rétro-ingénierie tels que FRIDA, FRIDA-gadget et cycript.

MSTG-RESILIENCE-5 

L'application détecte et réagit à son exécution dans un émulateur. 

Digital.ai Application Security peut détecter les émulateurs tels que QEMU en testant le processeur sur lequel l'application protégée est exécutée. 

MSTG-RESILIENCE-6  

L'application détecte et réagit aux tentatives de falsification du code et des données dans son propre espace mémoire. 

Digital.ai Application Security détecte et permet aux clients de créer des réponses personnalisées aux événements de falsificationDe plus, nous pouvons détecter les tentatives de contournement de la détection de falsification. Nous détectons également les éditeurs de mémoire tels que GameGuardian et iGameGod, et nous pouvons détecter les analyses de mémoire même lorsque les tentatives de falsification sont suspendues. 

MSTG-RESILIENCE-7  

L'application met en œuvre plusieurs mécanismes dans chaque catégorie de défense (8.1 à 8.6). Il est à noter que la résilience est proportionnelle au nombre, à la diversité et à l'originalité des mécanismes utilisés. 

Digital.ai Application Security les clients choisissent quand et comment mettre en œuvre et invoquer un diverses méthodes de détectionPar exemple, lorsqu'une tentative de falsification est détectée, que ce soit par un processus en arrière-plan caché ou par une violation manifeste de l'intégrité, le client peut choisir l'option souhaitée. (RÂPE) En cas de réponse, le client pourrait fermer l'application, obliger l'utilisateur final à se réauthentifier à l'aide de l'authentification à deux facteurs, ou encore désactiver la gravité dans un jeu, ruinant ainsi la partie du tricheur sans laisser de traces du code de détection de falsification d'origine. 

MSTG-RESILIENCE-8  

Les mécanismes de détection déclenchent des réponses de différents types, notamment des réponses retardées et furtives.  

Digital.ai Application Security Permet au client de gérer le déclenchement des protections grâce à des gestionnaires personnalisés et des planificateurs discrets. Nous fournissons même une fonction de plantage qui interrompt brutalement l'application sans révéler l'origine du code ayant provoqué le plantage.

MSTG-RESILIENCE-9  

L'obfuscation est appliquée aux défenses programmatiques, ce qui, à son tour, entrave la désobfuscation par analyse dynamique.  

Obfuscation de code Il s'agit du fondement même de notre technologie. Nous détenons six brevets liés à l'obfuscation de code, dont le tout premier brevet jamais accordé dans ce domaine. Digital.ai Application Security Nous proposons une solution d'aplatissement de code qui obscurcit fortement le code. De plus, nos variables et constantes cryptographiques en boîte blanche sont obscurcies et « résident » en mémoire pendant de courtes périodes, empêchant ainsi toute exploitation par le vidage de processus ou les scanners cryptographiques automatiques. Nous assurons également une protection contre l'obscurcissement des chaînes de caractères à l'exécution, ainsi qu'un obscurcissement complet pour les environnements d'exécution textuels tels que Java et Objective-C.   

MSTG-RESILIENCE-11  

Tous les fichiers exécutables et les bibliothèques de l'application sont chiffrés au niveau du fichier et/ou les segments de code et de données importants contenus dans les exécutables sont chiffrés ou compressés. Une analyse statique simple ne révèle aucun code ni donnée importants.  

Nous proposons différentes solutions de chiffrement pour le code et les données. Par exemple, sur Android, Digital.ai Application Security La prise en charge du chiffrement DEX et du chiffrement de bibliothèque partagée native, associée à notre cryptographie en boîte blanche et à nos fonctionnalités anti-débogage et d'instrumentation, couvrirait le produit de manière statique et dynamique, laissant l'attaquant dans l'ignorance. 

 MSTG-RESILIENCE-12  

Si l'objectif de l'obfuscation est de protéger des calculs sensibles, on utilise un schéma d'obfuscation adapté à la tâche et robuste face aux méthodes de désobfuscation manuelles et automatisées, en tenant compte des recherches publiées. L'efficacité de ce schéma doit être vérifiée par des tests manuels. Il est à noter que les mécanismes d'isolation matériels sont préférables à l'obfuscation chaque fois que cela est possible. 

Toute technique d'obfuscation peut être finalement déjouée, mais les bons systèmes d'obfuscation ne peuvent pas être désobfusqués automatiquement. Nos techniques d'obscurcissement Ils comprennent de nombreuses protections actives contre les désobfuscateurs et les émulateurs et sont testés contre toutes les solutions disponibles publiquement, y compris les décompilateurs JEB.

MSTG-RESLIENCE-13

En guise de défense en profondeur, outre le renforcement conséquent des systèmes des parties communicantes, le chiffrement des données au niveau applicatif peut être appliqué pour entraver davantage l'écoute clandestine.  

Pour intercepter des communications, un attaquant dispose de 3 méthodes principales :  

1. Effectuer une attaque de type « homme du milieu » (MITM) (par exemple, en supprimant l’épinglage de certificats). 
2. Altération des fonctions de cryptographie
3. Altération de la fonction réseau 

Notre Application Security Notre solution détecte toute tentative de falsification, y compris celle du code du système d'exploitation. Notre produit de protection des clés et des données est indétectable par les outils publics. Ensemble, ces deux solutions empêchent les trois méthodes décrites ci-dessus.  

Exigences L1

MSTG-ARCH-1 

Tous les composants de l'application sont identifiés et leur nécessité est avérée.  

En tant qu'ingénieurs logiciels, nous souhaitons que notre code soit aussi concis et efficace que possible. Cependant, du point de vue de la sécurité, supprimer le code inutile peut accroître la surface d'attaque. Dans le cas des applications mobiles, un code trop concis peut s'avérer contre-productif. Les petits composants identifiables représentent une aubaine pour les attaquants. L'obfuscation du code constitue la première ligne de défense contre la rétro-ingénierie statique, et coder de manière concise et logique facilite malheureusement la tâche des attaquants.

MSTG-ARCH-10  

La sécurité est prise en compte à toutes les étapes du cycle de vie du développement logiciel. Il est très facile de cocher une case et de passer à la suivante.  

La sécurité, c'est avant tout une question de vigilance, et elle vous amène toujours là où vous vous y attendez le moins. Digital.ai Application Security protège votre application à la fois comme une boîte noire inviolable et vous offre des capacités stratégiques vous permettant de vous appuyer sur des environnements défaillants.

MSTG-STOCKAGE-1  

Des systèmes de stockage d'identifiants système doivent être utilisés pour stocker les données sensibles, telles que les informations personnelles identifiables (IPI) et les identifiants des utilisateurs., ou des clés cryptographiques.  

Idéalement, les systèmes d'identification système constituent le seul moyen fiable de stocker des données sensibles. Cependant, en cas de compromission du système d'exploitation, ces systèmes de stockage peuvent s'avérer non fiables. Il est donc déconseillé de se fier aveuglément à ces solutions de stockage sécurisées pour conserver des informations confidentielles. Face à la multitude de techniques permettant d'identifier le rootage, le jailbreak, l'émulation, etc., et compte tenu des actions personnalisées mises en œuvre pour chaque menace, un attaquant pourrait se retrouver en difficulté lors du déploiement d'une nouvelle version dotée de mécanismes de protection totalement différents, ce qui risquerait de le déstabiliser. 

MSTG-STOCKAGE-10  

L'application ne conserve pas les données sensibles en mémoire plus longtemps que nécessaire, et la mémoire est explicitement effacée après utilisation.  

Notre solution de cryptographie en boîte blanche offre une gestion automatique des clés de session et de leur évacuation. Outre la cryptographie, Digital.ai Application Security Il pourrait également surveiller les accès mémoire non autorisés provenant de l'ensemble du système d'exploitation, permettant ainsi au client de réagir avec une logique personnalisée. 

MSTG-CRYPTO-2  

L'application utilise des implémentations éprouvées de primitives cryptographiques. 

Les implémentations cryptographiques comportent de nombreux pièges potentiels, et il est indispensable d'être un expert du domaine pour implémenter de tels algorithmes avec la prudence requise. Heureusement, Digital.ai Application Security Notre solution propose de nombreux algorithmes cryptographiques fiables et prêts à l'emploi. Cependant, certaines bibliothèques cryptographiques éprouvées présentent des failles. Par exemple, OpenSSL, Mbed-TLS et celles fournies par les systèmes d'exploitation Android et iOS possèdent des signatures binaires identifiables, permettant aux attaquants de cibler les zones sensibles du code et même d'automatiser certains processus, comme le déverrouillage de certificats. anti-falsification Cette solution protège contre les scénarios de falsification où le code ciblé utilise de telles bibliothèques publiques, tout en offrant une solution de cryptographie entièrement intégrée, protégée et cachée au sein du code, empêchant ainsi les attaquants de voir des traces de notre solution cryptographique. 

MSTG-PLATEFORME-1  

L'application ne demande que le minimum d'autorisations nécessaires. 

Notre technologie offre de nombreuses fonctionnalités de sécurité sans nécessiter d'autorisation spéciale.

MSTG-CODE-1  

L'application est signée et approvisionnée avec un certificat valide, dont la clé privée est correctement protégée. 

Outre les mécanismes d'intégrité propres au système d'exploitation, Digital.ai Application Security fournit des techniques de détection et de protection contre le reconditionnement et la modification en mémoire.

Conclusions et pistes de réflexion

Le MASVS est un document de référence, rédigé par des bénévoles, indispensable aux fournisseurs de solutions de sécurité logicielle mobile, à leurs prospects et à leurs clients. Nous espérons que le texte ci-dessus permettra à nos lecteurs de mieux comprendre les recommandations des sections L1 et R du document. Vous trouverez ci-dessous quelques commentaires sur certaines positions adoptées par le MASVS dans la partie « Avant-propos », notamment dans les sections qui établissent une distinction entre « protections de sécurité » et « contrôles de sécurité », et qui méritent, selon nous, d'être approfondies. 

Comme indiqué dans l'introduction, les exigences de couche 1 spécifiées par MASVS constituent le fondement de la sécurité des applications, et en particulier de la sécurité liée à la protection de la vie privée. Nous pensons que ce fondement, identifié par MASVS, peut être considérablement ébranlé par des acteurs malveillants utilisant des émulateurs, des débogueurs et des outils d'instrumentation dynamique courants et fréquemment utilisés. Par exemple, lorsque la section « Forward » de MASVS indique : « Les protections logicielles ne sont pas inutiles, mais elles peuvent être contournées ; elles ne doivent donc jamais être utilisées en remplacement des contrôles de sécurité. » Nous rétorquons que même si les développeurs s'appuient sur le système d'exploitation pour la sécurité et respectent scrupuleusement toutes les exigences de niveau 1, ces dernières ne garantiront pas une sécurité de base si le système d'exploitation sous-jacent est compromis (c'est-à-dire jailbreaké ou rooté). Dans ce cas, c'est l'inverse qui est vrai : l'utilisation de protections logicielles telles que la détection de falsification, décrite dans la section « Résilience », est la seule voie fiable vers une sécurité optimale. Pourquoi pensons-nous cela ? Prenons l'exemple de votre Keystore.  Si votre Keystore est entièrement exposé, le sandbox de votre application l'est également. Dans ce cas, l'application et ses fichiers pourraient être altérés, reconditionnés et instrumentés, ce qui permettrait d'automatiser certains processus, comme le désépinglage de certificats et l'extraction de ressources. De plus, il existe des cas où le protocole L1 ne protège pas suffisamment la confidentialité.  Par exemple, les logiciels malveillants ciblant les appareils mobiles peuvent compromettre le système d'exploitation mobile et permettre aux attaquants d'écouter en douce les conversations des applications de messagerie instantanée ou de VoIP en exploitant des API stratégiques ou des frameworks publics grâce à l'identification de leurs signatures binaires.

Dans le Forward, le MASVS affirme également que « La sécurité mobile, c'est avant tout la protection des données. ».  C'est souvent vrai, mais pas toujours. Lorsque vous manipulez des informations sensibles, comme des jetons éphémères, vous devez vous assurer de leur inaccessibilité. La sécurité ne se limite pas à la confidentialité ; elle est souvent liée à la continuité des activités et aux revenus. Dans les jeux, par exemple, où de nombreuses transactions ont lieu, la sécurité peut n'affecter que le client. De plus, de nombreux événements de jeu obligent le serveur à se fier aux entrées de l'utilisateur pour des raisons de latence. Par exemple, les tirs dans un FPS nécessitent de nombreuses optimisations en raison de la fréquence inhérente de cet événement – ​​généralement un tir par balle. 

La sécurité côté client est un jeu du chat et de la souris permanent : lorsque les développeurs d'applications mettent en place des protections suffisantes, les attaquants, frustrés, se tournent vers une autre cible. De plus, la publication fréquente de mises à jour client intégrant une obfuscation polymorphe rend vaine toute recherche sur les applications existantes, ce qui frustre encore davantage les attaquants.

Pour plus d'informations sur Digital.ai Application Securitycliquez ici.