Pentest mobile
Nous testons votre application Android comme le ferait quelqu'un qui l'a installée, décompilée, et qui cherche à contourner ce que vous croyez protégé côté téléphone.
Une application mobile s'exécute sur un appareil que vous ne maîtrisez pas. Tout contrôle laissé au téléphone peut être désactivé : ce qui compte, c'est ce que votre serveur accepte encore.
Android
Application et service distant testés ensemble
API incluse
Le serveur est testé avec l'application
4 à 8 j
Durée typique pour une application métier
Ce que l'application laisse fuir, et ce que le serveur accepte
Les référentiels que nous suivons
Le test ne dépend pas de l'inspiration du jour : il suit des méthodes publiques et reconnues, que vos équipes et vos clients peuvent vérifier.
Le référentiel de sécurité des applications mobiles : stockage, communication, authentification, résistance à la rétro-ingénierie.
Le guide de test associé, qui détaille les vérifications à mener sur Android, du binaire jusqu'à l'API.
Pour la partie serveur : les failles propres aux API que l'application consomme.
La notation des failles trouvées, complétée par la criticité réelle dans votre contexte.
L'application est entre les mains de l'attaquant, le serveur reste votre seule défense
Une application installée est un fichier que n'importe qui peut ouvrir, lire et modifier. Nous travaillons donc dans les deux sens : ce que l'application révèle, et ce que le serveur laisse faire.
Ce que nous faisons
Nous décompilons l'application, nous lisons ce qu'elle stocke sur le téléphone, puis nous interceptons ses échanges avec le serveur pour modifier les requêtes et observer les réponses.
Ce que vous en retirez
Un rapport à deux niveaux : une vue d'ensemble du risque pour la direction, et le détail technique pour vos équipes. Concrètement, la liste des secrets qui traînent dans le binaire ou dans le téléphone, celle des contrôles que votre serveur croyait délégués à l'application, et la remédiation associée à chacun.
Pourquoi c'est important
Un contrôle fait uniquement côté application (un prix, un droit d'accès, une vérification d'identité) se désactive. Si le serveur ne le refait pas, la faille est accessible à quiconque sait utiliser un proxy.
Un build ouvert pour aller au cœur
Le certificate pinning, la détection de root et l'obfuscation servent à ralentir celui qui analyse l'application. Ils peuvent aussi nous ralentir, sans rien dire de la solidité du serveur. Nous commençons donc sur le build de production, et ne demandons un build ouvert que si ces protections nous bloquent réellement.
Ce que nous demandons, le cas échéant
Si nous restons bloqués, et avec votre accord : en plus du build de production, un build de test sans certificate pinning ni détection de root. Ce n'est pas obligatoire, et selon les cas nous nous en passons.
Pourquoi un build ouvert
Le build de production sert à vérifier que ces protections existent et qu'elles tiennent. Le build ouvert sert à tester ce qu'il y a derrière : l'API, les droits d'accès, la validation côté serveur. C'est le cœur du sujet, et il doit être testé même quand une protection se trouve devant, sans quoi plusieurs jours passent à contourner vos propres protections.
Ce que dit le rapport
Si le pinning et la détection de root ont résisté, c'est écrit noir sur blanc, de même que ce que ce blocage nous a empêché de tester. Les failles trouvées derrière restent des failles : un attaquant motivé finit toujours par passer ces protections.
Boîte noire, boîte grise ou boîte blanche
Ces trois mots décrivent ce que vous nous donnez avant de commencer. Le choix change ce que le test couvre, et le temps qu'il demande.
Boîte noire
Nous démarrons sans rien : ni compte, ni documentation, ni schéma. C'est la position exacte d'un attaquant extérieur, donc le scénario le plus réaliste. En contrepartie, une partie du temps passe à chercher ce que vous auriez pu nous dire en deux minutes, et certaines zones ne sont jamais atteintes.
Boîte grise
Nous démarrons comme en boîte noire, avec quelques informations en réserve : un compte de test, la liste des domaines, un schéma réseau. Elles ne sortent que si nous bloquons ou si une piste mérite d'être creusée plus vite.
Boîte blanche
Vous donnez tout : un compte pour chaque rôle, la documentation, parfois le code source. La couverture est maximale et aucune fonction n'est oubliée, mais le test s'éloigne des conditions réelles d'une attaque.
Nous recommandons la boîte grise. On commence à l'aveugle, et l'information ne sort qu'au moment où elle évite de perdre une journée. Chaque information reçue en cours de mission est notée dans le rapport, avec le moment où elle nous a été donnée : vous savez ainsi ce qui a été trouvé seul et ce qui l'a été avec un coup de pouce.
Quatre phases, de la signature au rapport
Cadrage
Build de test, comptes, appareils cibles et versions d'Android concernées.
Reconnaissance
Analyse statique du binaire, cartographie des écrans et des appels réseau.
Exploitation
Interception du trafic, manipulation des requêtes, contournement des protections locales.
Rapport & restitution
Rapport avec captures et requêtes rejouables, puis restitution avec l'équipe de développement.
Questions sur cette prestation
+Faut-il nous fournir le code source ?
Non, ce n'est pas nécessaire : un build de test suffit. Si vous le fournissez, la couverture est meilleure et certains constats sont trouvés plus vite.
+Testez-vous les applications iOS ?
Non, nous testons Android. Pour une application présente sur les deux plateformes, la partie serveur est commune : elle est testée avec l'application Android, et les constats la concernant valent aussi pour iOS.
+Le build sans protections n'est-il pas risqué ?
Il ne quitte pas nos appareils de test et il est supprimé en fin de mission, comme le reste des données de la mission. C'est la même précaution que pour un compte de test.
Les durées, délais et repères indiqués sont des ordres de grandeur pour une TPE ou PME ; ils sont confirmés dans le devis.