L’une des techniques les plus employées par les prestidigitateurs consiste à attirer notre attention sur l ‘une de leurs mains tout en effectuant une manipulation rapide avec l’autre. J’ai repensé à ce tour de passe-passe en lisant récemment des rapports concernant une vulnérabilité de l’application mobile de la compagnie United Airlines. Il semble que tout le monde avait les yeux fixés sur l’« application mobile » alors qu’en réalité la faille se situe au niveau du serveur applicatif Web. Du reste, il serait même possible d’exploiter ce serveur sans avoir à passer du tout par l’application mobile. Par conséquent, avant de nous étendre sur la nature et les effets de cette vulnérabilité, la conclusion est que la plupart (sinon la totalité) des rapports sur les failles des applications mobiles révèlent en fait une vulnérabilité du serveur applicatif.
Une vulnérabilité peut être exploitée au moyen d’un outil aussi simple qu’un navigateur web. La plupart de ces failles sont pourtant faciles à éviter et à colmater avec les mêmes outils qui servent à corriger toutes les vulnérabilités et les attaques applicatives web (c’est-à-dire des firewalls applicatifs web). L’abondance de ces vulnérabilités en lien avec les applications mobiles n’est pas une coïncidence et s’explique par deux raisons :
- l’idée fausse des programmeurs selon laquelle une fonctionnalité vulnérable du serveur n’est accessible qu’à travers une application mobile ;
- la conviction que le manque de visibilité est synonyme de sécurité, à savoir qu’il est trop compliqué pour les auteurs des attaques de comprendre les interactions de l’application mobile avec le serveur.
Venons-en à présent à l’histoire de l’application mobile United Airlines.
Cette application comprend une fonction permettant de s’enregistrer depuis son mobile. Dans le cadre de cette opération, l’utilisateur peut entrer un code MileagePlus pour accéder aux informations de son compte et à d’autres détails personnels.
Il est facile pour quiconque possédant les compétences adéquates d’installer un logiciel espion sur le réseau ou un proxy interactif (Burp, par exemple) afin d’intercepter les communications entre l’application mobile et le serveur applicatif. Ces communications (comme on pourrait s’y attendre) reposent sur le protocole HTTP et utilisent une API web dédiée.
L’API s’appuie sur le seul paramètre « ActivateInput », correspondant au code MileagePlus indiqué par l’utilisateur. Ce code se compose de 2 lettres suivies de 6 chiffres, par exemple « AB123456 ». A titre de comparaison, la même opération effectuée via le site web standard d’United Airlines exige la saisie d’un code PIN ou d’un mot de passe en plus du code MileagePlus.
Cette menue différence est due, comme je le disais plus haut, à la foi dans la sécurité par l’invisibilité et la non-compréhension de la nature des communications entre un mobile et un serveur.
Au total, la structure du code MileagePlus autorise 676 000 000 combinaisons distinctes. Etant donné que les informations personnelles ne deviennent accessibles que 24 heures avant le décollage, une attaque paraît difficile à perpétrer. Pourtant, à l’aide de la même technique d’inspection du trafic, il est apparu – ce problème a été corrigé entre-temps – qu’un code valide peut être distingué à tout moment d’un code qui l’est pas (voir les copies d’écran ci-dessous). Par conséquent, un pirate peut commencer par recenser tous les membres actifs (et ainsi diviser par dix la taille de la liste initiale) puis bombarder l’API de requêtes par cycles de 24 heures, en retirant celles qui aboutissent.
Message d’erreur en cas de code MileagePlus valide : « Impossible d’effectuer la procédure d’enregistrement »
Message d’erreur en cas de code MileagePlus invalide : : « Aucune réservation n’a été trouvée »
Nous retrouvons ici un nouvel exemple de l’idée fausse des programmeurs évoquée plus haut. L’API Web n’intègre en effet aucun dispositif de contrôle pour prévenir les attaques de type « force brute ». C’est pourquoi, même si cette forme d’attaque nécessite de la patience pour ne pas se transformer en attaque DDoS, elle est parfaitement réalisable.
Quels enseignements tirer de ce piratage ?
- Ce qui, pour un œil non averti, peut passer pour une vulnérabilité de l’application mobile n’est autre qu’une faille côté serveur.
- S’agissant d’une faille du serveur, celle-ci doit être traitée sur le serveur.
- Pour réussir, l’attaque doit être menée automatiquement par un robot.
- Il existe plusieurs moyens permettant de neutraliser les attaques robotisées, par exemple le filtrage des adresses IP malveillantes d’après leur réputation, le bridage du débit ou encore une classification complète des types de clients.
- Les serveurs doivent faire appel à une solution de sécurité externe, telle qu’un firewall applicatif web, capable d’identifier et de bloquer les attaques robotisées.