Comment utiliser le MASVS de l'OWASP pour garantir la sécurité de vos applications

Afin de concevoir une application sécurisée, vous devez faire confiance à la base 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 la fondation elle-même n'est pas sécurisée ?   

R – La résilience est un sujet important dans le MASVS, et certains voient « R » comme une recommandation. À Digital.ai nous pensons que la résilience est la véritable base sécurisée dans un environnement autrement peu sûr. Le niveau « R » est fondamental pour protéger le niveau L1 « Sécurité standard ». Pourquoi? Parce que les mesures de sécurité standard décrites dans L-1 sont trop facilement brisées lorsque les applications sont exécutées dans des environnements non sécurisés. Les environnements non sécurisés 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 communs. En fait, dans une méta-analyse des millions d'instances d'application qui Digital.ai protège, nous avons constaté qu'au cours d'une semaine donnée, plus de la moitié des applications que nous protégeons sont placées dans unsafe environnements. 

Dans le billet de blog suivant, nous discuterons des exigences de résilience et de la manière de les respecter en utilisant outils d'obfuscation de code, de surveillance et RASP. Nous partagerons également des idées et des opinions sur les recommandations L1 - Sécurité standard, leurs vecteurs d'attaque correspondants et les moyens de les atténuer. Enfin, nous discuterons de certains défis qui surviennent lorsque les ingénieurs d'application ne suivent que les recommandations L-1. Nous commencerons par les exigences de niveau supérieur ou de « résilience » discutées dans le MASVS.  

Qu'est-ce que le MASVS ?

Les Mobile Application Security Norme de vérification, ou "MASVS", est une liste compilée de différentes recommandations réparties dans plusieurs 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 : Comprend 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 contient tout ce qui est inclus dans MASVS-L1 ainsi que 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 contre l'ingénierie inverse et la falsification : Protection contre les attaques spécifiques côté client, telles que la falsification, le modding, ou rétro-ingénierie.

Comment répondre aux exigences de résilience  

MSTG-RESILIENCE-1  

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

Digital.ai Sécurité des applications détecte de nombreuses méthodes sophistiquées de détection d'enracinement et de jailbreak. Nous sommes même capables de détecter la falsification du propre code du système d'exploitation. 

MSTG-RESILIENCE-2  

L'application empêche le débogage et/ou détecte et répond à un débogueur attaché. Tous les protocoles de débogage disponibles doivent être couverts.  

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

MSTG-RESILIENCE-3  

L'application détecte et réagit à la falsification des fichiers exécutables et des données critiques dans son propre bac à sable. 

Les bibliothèques de cryptographie Open Source telles que OpenSSL et Mbed-TLS sont faciles à détecter pour les attaquants. Parce que 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épond à la présence d'outils et de cadres d'ingénierie inverse largement utilisés sur l'appareil. 

Digital.ai Application Security détecte la présence de kits d'outils d'instrumentation dynamique, de frameworks et d'outils d'ingénierie inverse tels que FRIDA, FRIDA-gadget et cycript.

MSTG-RESILIENCE-5 

L'application détecte et répond à l'exécution dans un émulateur. 

Digital.ai Application Security peut détecter des é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épond à la 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 sabotage. De plus, nous pouvons détecter les tentatives de déviation de la détection de sabotage. Nous détectons également les éditeurs de mémoire tels que GameGuardian et iGameGod - et nous pouvons détecter les analyses de mémoire lorsque les actes de falsification sont suspendus. 

MSTG-RESILIENCE-7  

L'application implémente plusieurs mécanismes dans chaque catégorie de défense (8.1 à 8.6). A noter que la résilience évolue avec la quantité, la diversité de l'originalité des mécanismes utilisés. 

Digital.ai Application Security les clients choisissent quand et comment implémenter et invoquer un variété de méthodes de détection. Par exemple, chaque fois qu'un événement de falsification a été détecté, soit par un processus d'arrière-plan caché, soit par une simple violation de l'intégrité, le client peut choisir l'événement souhaité. (RÂPE) réponse. Le client pourrait fermer l'application, forcer l'utilisateur final à se réauthentifier à l'aide d'une authentification à deux facteurs ou remettre le paramètre de gravité dans un jeu à zéro, ruinant ainsi le gameplay du tricheur sans laisser aucune trace de la falsification d'origine. code de détection. 

MSTG-RESILIENCE-8  

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

Digital.ai Application Security permet au client de gérer quand et où les protections sont invoquées avec des gestionnaires personnalisés et des planificateurs furtifs. Nous fournissons même une fonction "crash" qui quitte brusquement l'application sans révéler l'origine du code qui a provoqué le crash.

MSTG-RESILIENCE-9  

L'obscurcissement est appliqué aux défenses programmatiques, qui à leur tour empêchent le désobscurcissement via l'analyse dynamique.  

Obfuscation de code est la base originale de notre technologie. Nous détenons 6 brevets liés à l'obscurcissement de code, dont le premier brevet jamais accordé pour l'obscurcissement de code. Digital.ai Application Security fournit une solution d'aplatissement du code qui obscurcit fortement le code. De plus, nos variables et constantes de cryptographie en boîte blanche sont obscurcies et «vivent» en mémoire pendant de courtes périodes de temps, de sorte que le vidage de processus ou les scanners de chiffrement automatiques ne peuvent apporter aucun avantage. Nous fournissons également une protection contre l'obfuscation des chaînes d'exécution ainsi qu'une obfuscation complète des runtimes textuels, tels que Java et Objective-C.   

MSTG-RESILIENCE-11  

Tous les fichiers exécutables et les bibliothèques appartenant à l'application sont soit cryptés au niveau du fichier et/ou les segments de code et de données importants à l'intérieur des exécutables sont cryptés ou compressés. L'analyse statique triviale ne révèle pas de code ou de données importants.  

Nous fournissons différentes solutions de cryptage pour le code et les données. Par exemple, sur Android, Digital.ai Application Security prendre en charge le cryptage DEX et le cryptage de bibliothèque partagée native, associés à notre cryptographie en boîte blanche et à nos fonctionnalités d'anti-débogage et d'instrumentation couvriraient le produit à la fois de manière statique et dynamique, laissant l'attaquant désemparé. 

 MSTG-RESILIENCE-12  

Si l'objectif de l'obscurcissement est de protéger les calculs sensibles, un schéma d'obscurcissement est utilisé qui est à la fois approprié à la tâche et robuste contre les méthodes de désobscurcissement manuelles et automatisées, compte tenu des recherches actuellement publiées. L'efficacité du système d'obscurcissement doit être vérifiée par des tests manuels. Notez que les fonctionnalités d'isolation basées sur le matériel sont préférées à l'obscurcissement dans la mesure du possible. 

Chaque obscurcissement peut éventuellement être vaincu, mais les bons obscurcisseurs ne peuvent pas être désobscurcis automatiquement. Nos techniques d'obscurcissement incluent de nombreuses protections actives contre les désobfuscateurs et les émulateurs et sont testés par rapport à toutes les solutions disponibles publiquement, y compris les décompilateurs JEB.

MSTG-RESILIENCE-13

En tant que défense en profondeur, outre le renforcement solide des parties communicantes, le chiffrement de la charge utile au niveau de l'application peut être appliqué pour empêcher davantage l'écoute clandestine.  

Pour espionner les communications d'un attaquant, il existe 3 méthodes principales :  

1. Effectuer une attaque Man in the Middle (MITM) (par exemple, suppression de l'épinglage de certificat) 
2. Altération des fonctions de cryptographie
3. Altération de la fonction réseau 

Notre Application Security détecte tout type de falsification, y compris la falsification du propre code du système d'exploitation. Notre produit Clé et protection des données ne peut pas être détecté automatiquement à l'aide d'outils accessibles au public. 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 connus pour être nécessaires.  

En tant qu'ingénieurs logiciels, nous voulons que notre code soit aussi simple et efficace que possible. Cependant, du point de vue de la sécurité, la suppression du code inutile pourrait augmenter votre surface d'attaque. Avec les applications mobiles, le code lean peut être une mauvaise chose. Les petits composants identifiables sont un jackpot pour les attaquants. L'obscurcissement du code est la première ligne de défense contre l'ingénierie inverse statique et le codage d'une manière simple et logique facilite malheureusement la vie des attaquants.

MSTG-ARCH-10  

La sécurité est abordée dans toutes les parties 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é est vraiment une question de sensibilisation, et elle vous amène toujours aux endroits auxquels vous vous attendiez le moins. Digital.ai Application Security protège votre application à la fois comme une boîte noire à ne pas altérer tout en vous offrant des capacités stratégiques pour vous appuyer sur des environnements défaillants.

MSTG-STOCKAGE-1  

Les installations de stockage des informations d'identification du système doivent être utilisées pour stocker des données sensibles, telles que les PII, les informations d'identification de l'utilisateur, ou des clés cryptographiques.  

Idéalement, les installations d'identification du système sont le seul moyen fiable de stocker des données sensibles. Mais lorsque le système d'exploitation a été altéré, vos installations de stockage peuvent ne pas être fiables. Vous ne devriez pas compter aveuglément sur ces magasins sécurisés pour stocker des secrets. Compte tenu de nombreuses techniques différentes pour identifier l'enracinement et JB, l'émulation, etc. - et compte tenu des actions personnalisées par menace - un attaquant pourrait se retrouver aux prises avec la cible pendant le déploiement de la prochaine version, ayant des mécanismes de protection totalement différents, frustrant ainsi l'attaquant. 

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 cryptographie en boîte blanche propose une gestion automatique de la clé des sessions, et son évacuation. Outre la cryptographie, Digital.ai Application Security pourrait également surveiller les accès mémoire non autorisés de tout le système d'exploitation, permettant 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 de cryptographie présentent de nombreux pièges potentiels, et il faut être un expert sur le terrain afin d'implémenter de tels algorithmes avec la bonne prudence à l'esprit. Heureusement, Digital.ai Application Security propose de nombreux algorithmes cryptographiques différents auxquels vous pouvez faire confiance et utiliser immédiatement. Il existe certains problèmes avec les bibliothèques de cryptographie connues et éprouvées. Certaines bibliothèques telles que OpenSSL, Mbed-TLS et celles fournies par les systèmes d'exploitation Android et iOS possèdent des signatures binaires identifiables, permettant aux attaquants d'identifier les zones sensibles du code et même d'automatiser certains processus, comme le retrait des certificats. Notre anti-falsification La solution protège contre les scénarios de falsification dans lesquels le code ciblé utilise de telles bibliothèques publiques, tout en offrant également une solution de cryptographie entièrement intégrée, protégée et cachée à l'intérieur du code qui empêche les attaquants de visualiser les traces de notre solution cryptographique. 

MSTG-PLATEFORME-1  

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

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

MSTG-CODE-1  

L'application est signée et provisionné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 les correctifs en mémoire.

Conclusions et autres pistes de réflexion

Le MASVS est un véritable document rédigé par des bénévoles et indispensable aux éditeurs de logiciels de sécurité mobile, à leurs prospects et à leurs clients. Nous espérons que le texte ci-dessus fournira à nos lecteurs un guide des recommandations dans les sections L1 et R du document. Ce qui suit sont quelques commentaires sur certaines des positions prises par le MASVS dans le "Forward", en particulier dans les sections qui font la distinction entre les "protections de sécurité" et les "contrôles de sécurité" qui, selon nous, méritent une discussion plus approfondie. 

Comme évoqué dans l'introduction, les exigences L1 spécifiées par MASVS constituent une base pour application security et en particulier la sécurité en ce qui concerne la vie privée. Nous pensons que la base identifiée par le MASVS peut essentiellement être ébranlée par les acteurs de la menace qui utilisent quelques émulateurs, débogueurs et kits d'outils d'instrumentation dynamique couramment disponibles et fréquemment utilisés. Par exemple, lorsque le MASVS "Transférer" indique : "Les protections logicielles ne sont pas inutiles, mais elles peuvent finalement ê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 codeurs s'appuient sur le système d'exploitation pour la sécurité et suivent toutes les exigences L-1 à la lettre, les exigences L-1 ne fourniront pas de fonctionnalités de sécurité de base si le système d'exploitation sous-jacent est cassé (c'est-à-dire jailbreaké ou rooté ). Dans ce cas, c'est le contraire qui est vrai - l'utilisation de protections logicielles telles que la détection de sabotage comme indiqué dans la section "Résilience" est le seul chemin fiable vers la sécurité. Pourquoi croyons-nous que c'est le cas? Prenez, par exemple, votre Keystore.  Si votre Keystore est entièrement exposé, le bac à sable de votre application l'est également. Dans ce cas, l'application et ses fichiers pourraient être falsifiés, reconditionnés et instrumentés, ce qui pourrait automatiser certains processus, tels que le retrait de certificat et l'extraction de ressources. De plus, il y a des cas où L-1 ne protège pas adéquatement la vie privée.  Les logiciels malveillants des appareils mobiles, par exemple, peuvent casser le système d'exploitation mobile et permettre aux attaquants d'écouter facilement la messagerie instantanée ou les applications VOIP en accrochant des API stratégiques ou des cadres publics grâce à l'identification de leurs signatures binaires.

Toujours dans le Forward, le MASVS affirme que "La sécurité mobile est une question de protection des données".  C'est souvent vrai, mais pas toujours. Lorsque vous traitez des informations sensibles, comme des jetons de courte durée, vous devez vous assurer que ces informations sont inaccessibles. La sécurité va au-delà de la confidentialité - elle est souvent associée à la continuité des activités et aux revenus. Les jeux, par exemple, où de nombreuses transactions dans le jeu ont lieu, peuvent n'affecter que le côté client. De plus, de nombreux événements de jeu obligent le serveur à faire confiance aux entrées de l'utilisateur pour des raisons de latence. Par exemple, les tirs dans un jeu FPS impliquent de nombreuses optimisations en raison de la fréquence inhérente de cet événement spécifique - généralement un événement par balle. 

La sécurité côté client est un jeu du chat et de la souris en cours, lorsque les développeurs/codeurs d'applications fournissent suffisamment de protections, l'attaquant passera à une cible différente par frustration. En plus de cela, la publication de mises à jour fréquentes du client avec une obfuscation polymorphe rend la recherche continue des applications actuelles sans valeur, ce qui frustre encore plus les attaquants.

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