Des dizaines de millions de personnes explorent le nouveau monde de Pokémon Go. Or, il s’avère qu’un grand nombre de ces utilisateurs ne sont pas du tout des personnes, mais des agents automatisés, ou bots. Les bots capables de jouer ne sont pas un phénomène nouveau, mais Pokémon Go leur offre de nouveaux cas d’utilisation. Ces bots ont commencé à gâcher le plaisir de tous en submergeant les serveurs de Pokémon Go de trafic automatisé. Pokémon Go constitue un cas d’étude idéal pour comprendre le fonctionnement des attaques et des défenses automatisées visant les API mobiles. Chez Shape, nous sommes confrontés chaque jour à ce type d’attaques ; nous avons donc décidé d’examiner de plus près ce qui s’est passé lors des attaques contre l’API de Pokémon Go.
Attaque de l’API de Pokémon Go
Niantic a récemment publié un article de blog détaillant les problèmes causés par les bots en générant du trafic automatisé, ce qui a même entravé le lancement du jeu en Amérique latine. Le graphique inclus dans l’article montre une baisse significative du trafic lié aux requêtes spatiales depuis que Niantic a déployé des mesures contre l’automatisation le 3 août à 13 h, heure du Pacifique. Le trafic automatisé semble avoir été environ deux fois supérieur à celui généré par de vrais joueurs. Il n’est donc pas étonnant que les serveurs de Pokémon Go aient été fortement surchargés ces dernières semaines.

Figure 1. Le trafic des requêtes spatiales a chuté de plus de 50 % depuis que Niantic a commencé à bloquer les robots d’extraction. Source : Article de blog de Niantic
À la découverte des bots Pokémon
Il existe deux types de bots Pokémon. Le premier automatise les actions habituelles du jeu et sévit fréquemment dans d’autres applications de jeu, en automatisant des activités telles que les déplacements et la capture de Pokémon. Parmi ces bots figurent MyGoBot et PokemonGo-Bot. Mais Pokémon Go a suscité le développement d’un nouveau type de bot, appelé Tracker ou Mapper, qui indique l’emplacement des Pokémon. Ces bots alimentent des services de cartographie pour Pokémon Go tels que Pokevision et Go Radar.
Comment fonctionne un bot Pokémon Go
Un bot d’API mobile est un programme qui reproduit les échanges entre une application mobile et ses serveurs backend — dans ce cas, ceux de Niantic. Le bot indique simplement aux serveurs les actions effectuées et traite leur réponse.
La figure 2 présente une capture d’écran d’une carte Pokémon Go indiquant les Pokémon à proximité, dans un rayon de 3 pas autour d’un emplacement donné. Pour parvenir à ce résultat, les créateurs de bots suivent généralement les étapes suivantes :
- Rétroconcevoir le protocole de communication entre l’application mobile et le serveur back-end. Le créateur du bot joue au jeu, intercepte les échanges entre l’application et son serveur, puis déchiffre le format du protocole.
- Écrire un programme qui envoie une série de requêtes « légitimes » aux serveurs back-end afin d’effectuer des actions. Dans ce cas, obtenir la position des Pokémon à proximité ne nécessite qu’une seule requête avec des coordonnées GPS ciblées, sans avoir à se rendre réellement sur place. Pour le bot, le défi consiste à contourner les mécanismes de détection du serveur et à se faire passer pour un véritable humain.
- Proposer des fonctionnalités connexes, telles que l’intégration à Google Maps, ou inclure la propre fonctionnalité de cartographie du bot à destination de l’utilisateur.

Figure 2. Capture d’écran d’une carte Pokémon Go
Piratage et protection des applications mobiles
En prenant l’application Pokémon Go comme exemple, examinons comment une application mobile peut être piratée par rétro-ingénierie afin d’en révéler les secrets. Puisque les attaquants ont principalement exploité l’application Android de Pokémon Go, concentrons-nous sur le piratage des applications Android et les moyens de s’en protéger.
Rétro-ingénierie du protocole
L’application Pokémon Go et les serveurs backend communiquent via ProtoBuf sur SSL. ProtoBuf définit le format des données transférées sur le réseau. Par exemple, voici un extrait de la définition ProtoBuf des statistiques du joueur :

Pokémon Go a été rétroconçu et publié en ligne par POGOProtos en seulement deux semaines. Comment cela a-t-il pu se faire aussi rapidement ? Au départ, Niantic n’utilisait pas l’épinglage de certificat.
L’épinglage de certificat est une méthode couramment utilisée pour se protéger contre les attaques de l’homme du milieu. En bref, une application mobile n’accorde sa confiance qu’aux certificats de serveur intégrés à l’application elle-même. Sans la protection offerte par l’épinglage de certificat, une personne malveillante peut facilement configurer un proxy tel que Mitmproxy ou Fiddler, puis installer sur son téléphone le certificat qu’elle a créé. Elle peut ensuite configurer son téléphone pour acheminer le trafic via le proxy et intercepter les échanges entre l’application Pokémon Go et les serveurs de Niantic. Il existe d’ailleurs un outil proxy spécialement conçu pour Pokémon Go qui facilite cette opération, appelé pokemon-go-mitm.
Le 31 juillet, Niantic a apporté une modification majeure à la fois à son serveur et à son application Pokémon Go. La version 0.31.0 de Pokémon Go a été publiée avec une protection par épinglage de certificat. Malheureusement, le mal était déjà fait et le protocole de communication était déjà accessible au public sur GitHub. De plus, il n’est pas toujours facile de mettre correctement en œuvre l’épinglage de certificat. Dans les sections suivantes, nous aborderons certaines techniques couramment utilisées par les attaquants pour contourner l’épinglage de certificat.
Analyse statique de l’APK
Le paquet d’application Android (APK) est le format de fichier de paquet utilisé par Android pour installer des applications mobiles. Les applications Android sont principalement écrites en Java, et le code Java est compilé au format dex puis intégré dans un fichier APK. En outre, les applications Android peuvent également faire appel à des bibliothèques partagées écrites en code natif (NDK Android).
Les fichiers dex sont connus pour pouvoir être facilement désassemblés en langage SMALI à l’aide d’outils tels que Baksmali. Des outils tels que dex2jar et jd-gui permettent ensuite de décompiler davantage le fichier dex en code Java, qui est facile à lire. Grâce à ces techniques, des attaquants ont décompilé l’application Android Pokémon Go (versions 0.29.0 et 0.31.0) en code Java. L’exemple de code ci-dessous met en œuvre l’épinglage de certificat à partir de la classe com.nianticlabs.nia.network.NianticTrustManager.

Lorsque le code source d’une application est exposé, la rétro-ingénierie devient un jeu d’enfant. Pokemon Go Xposed a utilisé moins de 100 lignes de code Java pour faire croire à l’application Pokémon Go que le certificat de MITMProxy était le certificat authentique de Niantic.
Comment Pokemon Go Xposed y est-il parvenu ? Très facilement. L’outil intercepte simplement l’appel à la fonction checkServerTrusted mentionnée dans l’extrait de code ci-dessus. Le hook remplace le premier paramètre de la fonction, chain, par la valeur du certificat de Niantic. Ainsi, quel que soit le certificat non autorisé utilisé par le proxy, l’application Pokémon Go est amenée à faire confiance à ce certificat.
Il existe de nombreux outils permettant de compliquer le désassemblage et l’analyse statique par des attaquants. ProGuard et DexGuard sont des outils qui appliquent des techniques d’obfuscation au code Java et aux fichiers dex. L’obfuscation rend le code difficile à lire, même après décompilation. Une autre approche consiste à utiliser des packers Android pour chiffrer le fichier classes.dex d’origine des applications Android. Le fichier dex chiffré est déchiffré en mémoire lors de l’exécution, ce qui rend l’analyse statique extrêmement difficile, voire impossible, pour la plupart des attaquants. L’utilisation d’une bibliothèque native est un autre moyen d’accroître considérablement la difficulté de rétro-ingénierie de l’application.
Rétro-ingénierie de la bibliothèque native
Le jeu du chat et de la souris le plus intéressant entre les hackers de pokemongodev et Niantic concernait le champ nommé « Unknown6 », qui figurait dans la signature envoyée avec la requête cartographique permettant d’obtenir les Pokémon à proximité d’un emplacement. « Unknown6 » est l’un des champs non identifiés du protobuf rétroconçu. Au départ, la valeur attribuée à Unknown6 importait peu : les serveurs de Niantic l’acceptaient tout simplement. À partir de 13 h (heure du Pacifique) le 03/08, tous les bots Pokémon Go ont soudainement cessé de trouver des Pokémon, ce qui a fini par entraîner la baisse importante du nombre de requêtes illustrée dans la figure 1.
Les hackers ont alors pris conscience de l’importance du champ « Unknown6 » dans le protocole et ont d’abord supposé qu’Unknown6 était une sorte d’empreinte ou de HMAC permettant de vérifier l’intégrité de la requête. Cela a suscité un immense intérêt au sein de la communauté pokemongodev et une équipe « Unknown6 » a rapidement été constituée pour tenter de percer le mystère de ce champ. Le canal Discord est devenu privé en raison du vif intérêt manifesté par les développeurs comme par les non-programmeurs, mais un canal de suivi en direct a permis à tout le monde de suivre l’avancement des efforts de décryptage. Après 3 jours et 5 heures, dans l’après-midi du 6 août, l’équipe Unknown6 a revendiqué la victoire en publiant une version mise à jour de l’API Pokémon Go qui permettait de nouveau de récupérer les Pokémon à proximité.
Bien que le compte rendu technique détaillant le piratage n’ait pas encore été publié, de nombreux outils et technologies pertinents ont été mentionnés sur les forums et dans le fil d’actualité en direct. IDA-Pro de Hex-Rays est un outil professionnel capable de désassembler le code ARM d’une bibliothèque native, tandis que le nouveau décompilateur Hex-Rays peut décompiler un fichier de code binaire dans un format proche du C. Ces outils permettent aux attaquants d’effectuer une analyse dynamique en déboguant l’application mobile et ses bibliothèques lors de leur exécution. Bien entendu, même avec des outils aussi puissants, la rétro-ingénierie d’un programme binaire reste extrêmement difficile. Même sans aucune obfuscation intentionnelle, le code désassemblé ou décompilé est déjà difficile à comprendre, et son volume est souvent considérable. Pour illustrer la complexité et l’imprévisibilité du travail nécessaire, le fil d’actualité en direct et une interview ultérieure ont expliqué que la fonction de chiffrement d’« Unknown6 » avait été identifiée en quelques heures, mais que l’équipe avait consacré beaucoup plus de temps à analyser un autre champ nommé « Unknown22 », qui s’est finalement révélé sans rapport avec Unknown6.
Par conséquent, l’obfuscation présente encore de nombreux avantages pratiques pour protéger les bibliothèques natives. Un niveau élevé d’obfuscation dans un fichier binaire peut accroître de plusieurs ordres de grandeur la difficulté de la rétro-ingénierie. Toutefois, comme l’illustrent les nombreux contournements réussis de clés de série pour Windows et ses applications, les pirates d’applications mobiles motivés parviennent souvent à leurs fins.
Protection côté serveur
Les mécanismes de défense côté serveur fonctionnent de manière totalement différente de ceux côté client. Voici quelques-unes des techniques utilisées pour protéger l’API mobile de Pokémon Go.
Limitation du débit
La limitation du débit est une méthode couramment utilisée pour tenter de bloquer, ou du moins de ralentir, le trafic automatisé. À leurs débuts, les scanners Pokémon pouvaient envoyer des dizaines de requêtes par seconde, analyser des dizaines de cellules et trouver tous les Pokémon.
Le 31/07, Niantic a mis en place des protections limitant le débit des requêtes. Si un même compte envoyait plusieurs requêtes de carte en l’espace d’environ 5 secondes, les serveurs de Niantic n’acceptaient que la première et rejetaient les autres. Les attaquants ont réagi à ces limitations en : a) ajoutant un délai de 5 secondes entre les requêtes de carte de leurs programmes d’analyse ; b) utilisant plusieurs comptes et plusieurs threads pour contourner la limitation de débit.
Dans le cas de Pokémon Go, l’utilisation de la limitation du débit n’a fait qu’ouvrir un nouveau front aux attaques automatisées : la création automatisée de comptes. Les attaquants ont rapidement découvert que, si la limitation du débit constitue une bonne technique de base pour maîtriser l’automatisation provenant de robots d’indexation trop agressifs ou d’attaquants novices, elle n’empêche pas les adversaires expérimentés de faire passer des requêtes automatisées.
Blocage des adresses IP
Le blocage d’adresses IP est une technique traditionnelle utilisée par les pare-feu réseau classiques ou les pare-feu d’applications web (WAF) pour rejeter les requêtes provenant d’adresses IP suspectes. De nombreuses bases de données suivent la réputation des adresses IP, et les pare-feu et WAF peuvent consulter périodiquement ces informations.
En règle générale, le blocage basé sur l’adresse IP est risqué et inefficace. Bloquer aveuglément une adresse IP générant un volume de trafic important peut conduire à bloquer le NAT d’une université ou d’une entreprise. Par ailleurs, de nombreux bots ou scanners Pokémon peuvent utiliser des adresses IP dynamiques résidentielles. Ces adresses IP étant partagées entre les clients des fournisseurs d’accès à Internet, le blocage prolongé d’une adresse IP risque d’empêcher des joueurs légitimes d’accéder au service.
Les services d’hébergement tels qu’Amazon Web Services (AWS) et Digital Ocean permettent également aux attaquants d’obtenir des machines virtuelles ainsi que de nouvelles adresses IP. Lorsqu’ils utilisent des cartes bancaires volées, ils peuvent même obtenir ces ressources gratuitement. Cependant, les utilisateurs légitimes n’utilisent jamais de services d’hébergement pour naviguer sur le Web ou jouer à des jeux. Bloquer les adresses IP de ces services constitue donc une mesure de défense sûre et couramment appliquée côté serveur. D’après ce message publié sur le forum , Niantic pourrait décider de bloquer les adresses IP d’AWS.
Analyse comportementale
L’analyse comportementale constitue généralement la dernière ligne de défense contre les attaquants chevronnés capables de contourner les autres dispositifs de sécurité. Les bots ont des comportements très différents de ceux des humains. Par exemple, une personne réelle ne peut pas jouer 24 h/24 et 7 j/7, ni attraper 5 Pokémon en une seconde. Bien que l’analyse comportementale semble être une approche prometteuse, concevoir un système de détection précis capable de traiter un volume de données aussi considérable que celui de Pokémon Go n’est pas une tâche facile.
Niantic vient de mettre en place un bannissement temporaire pour les tricheurs qui falsifient leur position GPS afin de se « téléporter » (c’est-à-dire de se déplacer soudainement à une vitesse impossible). Il s’agissait probablement d’un « bannissement temporaire » en raison des faux positifs : certaines familles partagent des comptes et les données GPS peuvent être imprécises, ce qui peut faire passer certains usages légitimes pour des comportements de bots.
Aux alentours du 12 août 2016, Niantic a publié une note sur son site web, indiquant que toute violation de ses conditions d’utilisation pouvait entraîner le bannissement définitif d’un compte Pokémon Go. Plusieurs règles de bannissement visant les bots ont également été dévoilées officieusement. Par exemple, la règle relative à la capture excessive de Pokémon entraîne le bannissement des comptes qui capturent plus de mille Pokémon en une seule journée. En outre, Niantic encourage les joueurs respectueux des règles à signaler les tricheurs ou les joueurs au comportement inapproprié.
D’après notre expérience, la détection fondée sur la modélisation comportementale peut être extrêmement efficace, mais il est souvent techniquement ou économiquement impossible de la développer en interne. Comme l’a indiqué Niantic dans un article de blog : « La gestion de ce problème a également un coût d’opportunité. Les développeurs doivent consacrer du temps à le maîtriser plutôt qu’à créer de nouvelles fonctionnalités. » Le problème majeur est que la mise au point d’une technologie capable de contrer des adversaires déterminés et techniquement compétents, disposant de botnets et d’autres outils conçus pour contourner les défenses classiques, exige de nombreuses compétences très spécialisées ainsi qu’un effort de développement considérable.
La partie n’est pas terminée
Tant que Pokémon Go continuera d’être apprécié des joueurs, le jeu du chat et de la souris entre les créateurs de bots et Niantic se poursuivra lui aussi. Se défendre contre le trafic automatisé représente un défi non seulement pour le secteur du jeu vidéo, mais aussi pour tous les autres secteurs. Des attaques et des mesures de défense similaires ont lieu dans les applications bancaires, aériennes et commerciales, où les enjeux sont sans commune mesure avec la perte de quelques Ronflex. Pour les entreprises, les bots et les outils d’attaque associés n’ont rien d’un jeu lorsque leurs clients et utilisateurs ne peuvent plus accéder aux services en raison d’un trafic automatisé indésirable.
À propos de l’auteur
Articles de blog associés

F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.