Vulnérabilités des applications mobiles

L'une des missions du CIRT de l'ANTIC est la certification des plates-formes électroniques du cyberespace camerounais. La certification de la plate électronique d'une entreprise permettra de garantir que celle-ci ne présente aucune faille ou danger pour les différents acteurs du cyberespace camerounais. Les ingénieurs experts du CIRT procèdent à des évaluations de la logique applicative et métiers des applications web et mobiles.

Nous présentons dans le tableau ci-dessous, les vulnérabilités les plus rencontrées dans les tests d'évaluations. Nous n'avons pas classé ces vulnérabilités en termes de gravité, d'impact ou de prévalence, car ces vulnérabilités peuvent poser problème à une entreprise en termes de perte de données, de partage d'informations privées ou d'autres domaines pouvant être exploités par les hackers

VulnérabilitéObservation
1App is DebuggableL'application est compilée avec le mode de débogage activé. Un acteur malveillant avec accès physique à un périphérique sur lequel le débogage USB est activé peut joindre un débogueur au processus de l'application pendant l'exécution. C'est dangereux car il pourrait exposer des données sensibles, activer l'inverse ingénierie, et permettre l'exécution de code arbitraire.

Solutions proposées :
1. Vérifiez que tout le code de test n'est pas inclus dans la version de production finale de l'application;
2. Examinez tous les points de terminaison API auxquels l'application mobile accède pour vérifier que ces points de terminaison sont bien documentés et accessibles au public;
3. Examinez toutes les instructions de journal pour vous assurer que rien de trop descriptif sur le backend n'est en cours d'écriture dans les journaux.
2Accesses External StorageL'application accède au répertoire de stockage externe sur la carte SD. Le stockage externe est accessible par n'importe quelle application sur un appareil avec l’autorisation READ/WRITE_EXTERNAL_STORAGE. Il est donc recommandé de ne pas stocker des informations sensibles dans le stockage externe. L’accès au stockage externe se trouve dans les méthodes et classes suivantes :
nl.xservices.plugins.SocialSharing.getDownloadDir()

Solutions proposées :
Pour le stockage local, utiliser la fonction suivante proposée par les librairies Android pour forcer le Chiffrement dans les magasins de fichiers locaux «setStorageEncryption». Pour le stockage sur carte SD, une certaine sécurité peut être obtenue via la bibliothèque «javax.crypto». Vous avez quelques options, mais il est facile de chiffrer toutes les données en texte brut avec un mot de passe principal et AES 128.
Assurez-vous que les propriétés de préférences partagées ne sont pas MODE_WORLD_READABLE, sauf si elles sont explicitement requises pour le partage d'informations entre les applications.
Évitez de vous fier exclusivement aux clés de chiffrement ou de déchiffrement codées en dur lorsque vous stockez des informations sensibles.
Envisagez de fournir une couche de chiffrement supplémentaire au-delà des mécanismes de chiffrement par défaut fournis par le système d'exploitation.
3Contains Native CodeL'application charge les bibliothèques de code natives. Le code natif n'a pas les mêmes protections de sécurité que Java, et est vulnérable aux débordements de mémoires, utilisation après des erreurs gratuites et erreurs ponctuelles. le code peut également être chargé à partir de sources non fiables, telles qu'un répertoire partagé ou le réseau.

Solutions proposées :
En général, les problèmes de qualité de code peuvent être évités en procédant comme suit:
Maintenir des modèles de codage cohérents sur lesquels tous les membres de l'organisation sont d'accord.
Ecrire un code facile à lire et bien documenté;
Via l'automatisation, identifiez les dépassements de mémoire et les pertes de mémoire grâce à l'utilisation d'outils d'analyse statique tiers; et Prioriser la résolution des dépassements de mémoire et des fuites de mémoire par rapport aux autres problèmes de «qualité de code».
4Insecure Pseudo-random Number GenerationL'application utilise un générateur de nombres pseudo-aléatoires qui renvoie une séquence de nombres prévisible qui ne convient pas à des fins de sécurité. Les classes java.util.Random et java.lang.Math ne doivent pas être utilisé pour générer des nombres aléatoires pour une utilisation sécurisée. Des générateurs de nombres pseudo-aléatoires non sécurisés se trouvent dans les méthodes suivantes:
com.adobe.phonegap.notification.LocalNotifications.showNotification(JSONArray)
L'application imprime les informations de journalisation dans le journal du système. Alors que les applications enregistrer souvent des informations à des fins de débogage, cela devrait généralement être supprimé avant la mise en production d’une application. Des informations sensibles, telles que des clés ou des jetons d’authentification, ne devrait jamais être écrit dans le journal du système.

Solutions proposées :
Utilisez les classes java.util.Random et java.lang.Math pour écrire des nouveaux algorithmes plus sécurisés permettant la génération des nombres aléatoires. Appliquer des normes cryptographiques qui résisteront à l'épreuve du temps pendant au moins 10 ans;
5Logs InformationL'application imprime les informations de journalisation dans le journal du système. Alors que les applications enregistrer souvent des informations à des fins de débogage, cela devrait généralement être supprimé avant la mise en production d’une application. Des informations sensibles, telles que des clés ou des jetons d’authentification, ne devrait jamais être écrit dans le journal du système.

Solutions proposées :
Rassurez-vous que aucune informations sensibles ne sont écrit dans les journaux.
6Source Code is not ObfuscatedL'application ne masque pas la majorité de son code en renommant les classes, champs, méthodes et variables. Cela permet à un adversaire ou un concurrent de décompiler l'application en source quasi originale. Il est recommandé de masquer le code de l’application à l’aide d’un outil tels que ProGuard pour rendre plus difficile l'ingénierie inverse.

Solutions proposées :
Afin d'éviter une rétro-ingénierie efficace, vous devez utiliser un outil d'obscurcissement. Il existe de nombreux obfuscateurs de qualité commerciale et gratuits sur le marché. À l'inverse, il existe de nombreux désobfuscateurs différents sur le marché. Pour mesurer l'efficacité de n'importe quel outil de masquage que vous choisissez, essayez de désobfusquer le code en utilisant des outils tels que IDA Pro et Hopper.
Un bon obfuscateur aura les capacités suivantes :
Limitez les segments de code / méthodes à masquer;
Ajuster le degré d'obfuscation pour équilibrer l'impact sur la performance;
Obfusquez les tables de codes ainsi que les méthodes
7Uses MD5 Hashing AlgorithmL'application utilise l'algorithme de hachage MD5 faible. L’ l'algorithme MD5 est dangereux s'il est utilisé pour des données sensibles car il vulnérable aux attaques de collision.

Solutions proposées :
Utilisez l’algorithme de hachage SHA-256
8Weak RSA Modulus Length of App Signing CertificateL'application est signée avec une clé 1024 bits et peut être vulnérable. Un attaquant en possession de la clé de signature privée d'une application serait en mesure designer des mises à jour d'applications malveillantes.

Solutions proposées :
Utilisez une clé d’au moins 2048 bits de longueur.
9Binary ProtectionInsufficient Jailbreak / Root Detection. Rooting ou jailbreaking un appareil contourne les schémas de protection et de cryptage des données sur le système. Lorsqu'un périphérique a été compromis, toute forme de code malveillant peut s'exécuter sur le périphérique, ce qui peut modifier considérablement les comportements prévus de la logique de l'application. Les outils de récupération et d'analyse de données fonctionnent généralement sur des périphériques rootés.

Solutions proposées :
En ce qui concerne la sécurité, il est préférable de ne pas exécuter l'application sur des périphériques rootés ou jailbreakés, ou de faire au moins une certaine forme de détection root / jailbreak. Détecter si un périphérique a été compromis ajoute une couche supplémentaire d'application des règles et d'atténuation des risques pour protéger les données de l'application contre toute exposition.
10Insufficient Transport Layer ProtectionLes applications échouent souvent à chiffrer le trafic réseau lorsque cela est nécessaire pour protéger les communications sensibles. Le chiffrement (généralement TLS) doit être utilisé pour toutes les connexions authentifiées, en particulier les pages Web accessibles via Internet. Les connexions dorsales doivent également être cryptées ou risquer d'exposer un jeton d'authentification ou de session à des acteurs malveillants sur le même réseau que l'hôte de l'application. Ces connexions dorsales peuvent représenter une probabilité d'exploitation inférieure à celle d'une connexion via Internet externe; Toutefois, leur impact en cas d'exploitation peut encore compromettre les comptes utilisateur ou pire. Le chiffrement doit être utilisé chaque fois que des données sensibles, telles que des informations de carte de crédit ou de santé, sont transmises. Les applications qui utilisent le texte en clair ou qui sont forcées de quitter un mode de chiffrement peuvent être malmenées par des attaquants.

Solutions proposées :
Assurez-vous que l'application dispose d'une contrainte de sécurité qui définit une garantie de transport sécurisé basée sur la confidentialité et l'intégrité. Cela garantira que toutes les données sont envoyées de manière à garantir qu'elles ne peuvent être observées ou modifiées pendant la transmission. Si TLS doit être arrêté sur un équilibreur de charge, un pare-feu d'application Web ou un autre hôte en ligne, il doit rechiffrer les données en transit vers le ou les hôtes cibles..
11Information Leakage – Server VersionLes informations sur le serveur sont présentes dans la réponse. La fuite d'informations est une faiblesse de l'application lorsqu'une application révèle des données sensibles, telles que des détails techniques sur l'application Web, l'environnement ou des données spécifiques à l'utilisateur. Un attaquant peut utiliser des données sensibles pour exploiter l'application cible, son réseau d'hébergement ou ses utilisateurs; les fuites de données sensibles devraient être limitées ou évitées chaque fois que possible. Les fuites d'informations, dans leur forme la plus courante, résultent d'une ou plusieurs des conditions suivantes: Incapacité à supprimer les commentaires HTML / Script contenant des informations sensibles, des configurations d'application ou de serveur incorrectes ou des réponses différentes aux données valides ou non valides .

Solutions proposées :
Supprimez les informations inutiles des réponses du serveur qui pourraient donner à un attaquant des informations supplémentaires sur votre réseau.
12Information LeakageDonnées sensibles: à titre d'information, cette version est similaire à la version du serveur, mais concerne davantage de fuites au sein de l'application, de l'application vers l'application, etc..

Solutions proposées :
Les fuites d'informations se répartissent généralement en deux catégories: globalement ou spécifiques aux ressources. Les vulnérabilités basées sur les fuites d'informations globales sont souvent liées à des messages d'erreur verbeux ou à des divulgations de la version du serveur / de l'application. Ces fuites peuvent souvent être résolues par un paramètre de configuration. Les problèmes de fuite d'informations spécifiques aux ressources sont liés à la divulgation des commentaires des développeurs, des fichiers ou des informations personnelles sensibles. Les fuites spécifiques aux ressources nécessitent souvent une atténuation directe à chaque fois qu'elles surviennent.
13Insufficient Authorization/AuthenticationUne autorisation insuffisante est générée lorsqu'une application n'effectue pas de vérifications d'autorisation adéquates pour s'assurer que l'utilisateur exécute une fonction ou accède aux données conformément à la stratégie de sécurité. Les procédures d'autorisation doivent appliquer ce qu'un utilisateur, un service ou une application est autorisé à faire. Lorsqu'un utilisateur est authentifié sur un site Web, cela ne signifie pas nécessairement que l'utilisateur doit avoir un accès complet à tous les contenus et fonctionnalités.

Solutions proposées :
Appliquez un schéma de cadre d'autorisation éprouvé qui met l'accent sur les fichiers de configuration basés sur des règles plutôt que sur des contrôles d'authentification / autorisation codés en dur, dans la mesure du possible.
14Cryptography – Improper Certificate ValidationCette application ne valide pas les certificats SSL / TLS ou utilise un système de validation de certificat SSL / TLS qui ne vérifie pas correctement qu'un fournisseur approuvé a émis le certificat. Le client doit être configuré pour supprimer la connexion si le certificat ne peut pas être vérifié ou n'est pas fourni. Toute donnée échangée sur une connexion où le certificat n'a pas été validé correctement pourrait être exposée à un accès ou à une modification non autorisée.

Solutions proposées :
Assurez-vous que la validation des certificats de votre application est configurée pour vérifier correctement qu'un certificat est fourni et à partir d'une source approuvée, telle qu'une autorité de certification fiable. Ou bien, codez les dernières normes de transparence des certificats approuvées par l'IETF ou le forum CA / B.
15Brute Force – User EnumerationIl existe de nombreuses manières pour un attaquant de déterminer si un utilisateur existe dans le système; une attaque par force brute est une méthode permettant de déterminer une valeur inconnue en utilisant un processus automatisé pour essayer un grand nombre de valeurs possibles. L'attaque profite du fait que l'entropie des valeurs est inférieure à celle perçue. Par exemple, alors qu'un mot de passe alphanumérique à 8 caractères peut avoir 2 800 milliards de valeurs possibles, de nombreuses personnes sélectionnent leurs mots de passe dans un sous-ensemble beaucoup plus petit composé de termes et de termes communs. Si les messages d'erreur changent lorsque le nom d'utilisateur et / ou le mot de passe ne sont pas correctement envoyés, un attaquant peut déterminer l'existence d'un nom d'utilisateur / une adresse électronique valide en fonction des différences entre les messages d'erreur. Si l'ID utilisateur est généré de manière prévisible, (XXX102017, XXX112017, etc.), un attaquant peut énumérer la liste des utilisateurs en incrémentant l'ID utilisateur.

Solutions proposées :
La vulnérabilité d'énumération d'utilisateur se produit généralement dans les fonctionnalités suivantes: connexion, enregistrement ou mot de passe oublié. L'application ne doit pas révéler si un nom d'utilisateur est valide. La réponse à une entrée valide et non valide dans l'un ou l'autre des champs doit être complètement identique. Par exemple, au lieu de «Désolé, votre mot de passe n'est pas valide», une réponse appropriée pourrait indiquer: «Désolé, votre nom d'utilisateur ou votre mot de passe est incorrect. Veuillez réessayer."
16Insufficient Session ExpirationAprès qu'un utilisateur se soit déconnecté d'une application, les identificateurs utilisés pendant la session sont censés être invalidés. Si le serveur ne parvient pas à invalider les identificateurs de session, les autres utilisateurs peuvent utiliser ces identificateurs pour usurper l'identité de cet utilisateur et effectuer des actions en son nom.

Solutions proposées :
Tout d'abord, il est recommandé de s'assurer qu'un bouton de déconnexion est implémenté dans l'application. et deuxièmement, lorsque l'utilisateur clique sur ce bouton, sa session est correctement invalidée.
17Information Leakage – Application CacheLes données sensibles peuvent être divulguées à partir des caches d'application, via le code de l'application principale ou via des structures tierces. Les appareils mobiles représentent un défi unique en ce qui concerne le stockage sécurisé des données. Les appareils peuvent être facilement perdus ou volés. De nombreux utilisateurs ne verrouillent pas leurs appareils. Les données mises en cache peuvent être visualisées par un attaquant qui effectue des analyses de données sur le périphérique physique.

Solutions proposées :
Assurez-vous que les données sensibles ne fuient pas accidentellement dans le cache. Les développeurs peuvent l’empêcher en créant un modèle de menace pour le système d’exploitation, la structure et la plate-forme pour vérifier et gérer le traitement des URL pendant la mise en cache, la mise en cache du clavier, la copie ou le collage, et données analytiques envoyées au serveur ou à une autre application.
18Binary Protection – Insufficient Code ObfuscationPour mieux protéger les applications Java/Android contre la rétroingénierie, plusieurs outils ont été développés pour brouiller ou masquer le code. Google a inclus l'un des outils les plus populaires, ProGuard, dans le SDK Android. L'outil ProGuard réduit, optimise et masque votre code en supprimant le code inutilisé et en renommant les classes, les champs et les méthodes avec des noms sémantiquement obscurs. Le résultat est un fichier .apk de plus petite taille, plus difficile à désobfusquer.

Solutions proposées :
ProGuard est intégré au système de génération Android, vous n'avez donc pas à l'invoquer manuellement. ProGuard s'exécute uniquement lorsque vous générez votre application en mode de publication. Vous n'avez donc pas à gérer le code obscur lorsque vous créez votre application en mode débogage. Avoir ProGuard en execution est complètement facultatif, mais fortement recommandé et peut aider votre sécurité sur ces systèmes.