Pourquoi effectuer un audit de sécurité mobile ? Telle est la question qui revient régulièrement lors des échanges avec nos partenaires possédant ce type d’application. En effet, une des réponses communes, c’est que les applications mobiles iOS ou Android sont finalement installées sur un périphérique qu’ils ne gèrent pas.
Cependant, il faut souligner que les applications mobiles et les données qui en découlent sont de la responsabilité du développeur/mainteneur. De plus, elles sont une vitrine pour une entreprise ou une marque. Elles représentent un premier risque pour les terminaux des utilisateurs. En effet, la faille découverte fin 2020 sur WhatsApp en est un exemple. Elle permettait alors l’extraction d’informations utilisateur et des discussions directement depuis le terminal.
C’est une ouverture sur les appareils mobiles des utilisateurs, mais aussi une porte d’entrée sur le système d’information de l’éditeur. Comme nous le verrons après, on rencontre souvent des secrets tiers dans les binaires déployés sur les magasins d’applications. De plus, dans la majorité des cas, les applications communiquent avec des webservices.
Déroulement d’un audit de sécurité mobile
Un audit de sécurité mobile se déroule généralement en 3 phases :
- Premièrement, l’analyse statique
- Ensuite, l’analyse dynamique
- Enfin, l’analyse des flux
Nous verrons ci-dessous l’intérêt de chacune de ces étapes.
1.1 – Analyse statique
La première étape pour les auditeurs/attaquants est d’extraire le binaire de l’application depuis le magasin d’applications. Ils passent par un service tiers, ou en procédant à l’extraction depuis un appareil mobile.
Une fois le binaire obtenu (format IPA ou APK), l’analyse statique peut débuter. Elle consiste à analyser les fichiers présents dans ce binaire et à procéder à une rétro-ingénierie statique. L’auditeur peut ainsi connaître la configuration de l’application (ce qu’elle demande comme permissions sur le téléphone, comment a-t-elle été compilée, les protections possiblement en place, etc.). Cela permet de détecter, ensuite, des secrets éventuellement stockés en clair dans les fichiers, ou découvrir des données de tests ou des URLs. Aussi, s’il n’existe pas de mécanisme d’obfuscation en place, l’auditeur peut analyser le code source de l’application.
1.2 – Analyse dynamique
Cette analyse permet d’étudier l’application en runtime, c’est-à-dire en cours d’exécution dans un ou plusieurs environnements définis (appareil virtualisé ou non, appareil rooté/jailbreaké, différentes versions d’OS). ). L’auditeur va alors analyser les interactions entre l’application et le système d’exploitation et notamment l’utilisation ou non de certaines fonctionnalités natives : coffres forts internes, bases de donnes, caches ou encore authentifications (FaceID ou empreinte).
De plus, l’objectif est de détecter les anomalies liées au stockage de données sensibles de manière non sécurisée ainsi que de repérer des moyens de contournements d’authentification locaux ou des vulnérabilités ouvrant une potentielle porte d’entrée sur le mobile de l’utilisateur.
Cette étape et celle ci-dessous peuvent être réalisées en parallèle, la barrière entre elles étant mince.
1.3 – Analyse des flux
Ensuite l’auditeur va mettre en place un proxy entre l’application mobile et les différents services externes utilisés par cette dernière. Le but étant surtout d’identifier des vulnérabilités sur ces services entrants donc dans le périmètre. Le testeur va employer la méthodologie adaptée aux tests Web ou/et API proposées par l’OWASP. On revient sur un test « classique » où on répertorie des vulnérabilités Web, des injections ou des problèmes de cloisonnement.
Nous proposons de découper les 3 étapes expliquées ci-dessous ainsi :
Les principaux défauts rencontrés par nos équipes lors d’un audit de sécurité mobile
Comme énoncé en introduction, il n’est pas rare pour les auditeurs NBS System de retrouver divers identifiants de connexion ou des secrets quels qu’ils soient (couple login/mot de passe, clés API, clés privées) dans les binaires présents sur les magasins d’applications : ils sont donc accessibles de tous ! Parfois, ils sont utiles pour se connecter à des services tiers comme Google, Algolia, AWS ou à des interfaces d’administration.
Aussi, comme évoqué dans la section précédente, nous rencontrons souvent des défauts de conception et de compilation des binaires. Ils permettent une rétro-ingénierie plus aisée. En effet, nous pouvons notamment lister le manque d’obfuscation, l’absence de drapeaux de compilation ou encore la non-détection d’utilisation d’appareils non sécurisés (rootés ou jailbreakés).
Dans la même catégorie, nous pouvons aussi évoquer le manque de contrôle des communications application/serveur (Certificate Pinning). Cela permet une interception des données simples et donc possiblement des attaques par homme du milieu.
Nous constatons une méconnaissance des systèmes d’exploitation qui déploient les applications. En effet, sans une lecture approfondie des différentes documentations, il n’est pas toujours évident de se rendre compte que le système va cacher certaines données parfois sensibles. Il peut prendre des prises d’écran temporaires pour les rendre rapidement à la vue ou donner une permission pour ouvrir la porte à des vols de données.
Enfin, en dernier exemple, nous pouvons évoquer les problèmes liés aux APIs utilisées que nous retrouvons lors d’audits de plateformes Web. C’est-à-dire les injections, des problèmes liés à l’authentification ou encore des défauts de cloisonnement.
Bilan des analyses des défauts
Ce ne sont pas les seuls défauts mais ils sont suffisamment récurrents pour être évoqués. Toutefois nos consultants étudient d’autre défauts moins courants mais qui peuvent être tout aussi critiques..
En finalité, nos équipes constatent que la sécurité des applications mobiles est délaissée alors qu’elles sont un potentiel risque pour les utilisateurs. Elles peuvent aussi apporter un accès supplémentaire à un attaquant sur le système d’information de la société émettrice. Il ne faut pas oublier que ces applications sont une vitrine pour les sociétés qui les exploitent. Un défaut tant au niveau de la praticité d’utilisation que de la sécurité global peut alors écorner leur image de marque.
Article de Ricardo Matias, consultant sécurité de NBS System
Vous souhaitez bénéficier d’un audit de sécurité mobile ?
Nos équipes sont disponibles pour vous accompagner.
