Decenas de millones de personas están explorando el nuevo mundo de Pokémon Go. Sin embargo, resulta que muchos de esos usuarios no son personas, sino agentes automatizados o bots. Los bots que juegan no son un fenómeno nuevo, pero Pokémon Go ofrece nuevos casos de uso para ellos. Estos bots han empezado a estropear la diversión de todos al saturar los servidores de Pokémon Go con tráfico automatizado. Pokémon Go es un caso de estudio perfecto para entender cómo funcionan los ataques y las defensas automatizados en las API móviles. En Shape nos enfrentamos a este tipo de ataques a diario, así que hemos querido analizar más de cerca lo ocurrido con los ataques a la API de Pokémon Go.
Ataque a la API de Pokémon Go
Niantic publicó recientemente una entrada de blog en la que detallaba los problemas que estaban causando los bots al generar tráfico automatizado, lo que llegó a obstaculizar su lanzamiento en Latinoamérica. El gráfico incluido en la publicación muestra una caída significativa del tráfico de consultas espaciales desde que Niantic implementó medidas contra la automatización el 03/08 a las 13:00 PT. Al parecer, el tráfico automatizado era aproximadamente el doble que el generado por jugadores humanos reales. No es de extrañar que los servidores de Pokémon Go hayan estado tan sobrecargados en las últimas semanas.

Figura 1. El tráfico de consultas espaciales se redujo en más de un 50 % desde que Niantic empezó a bloquear los scrapers. Fuente: Publicación del blog de Niantic
Conoce los bots de Pokémon
Hay dos tipos de bots de Pokémon. El primer tipo automatiza el juego normal y suele ser un infractor habitual en otras aplicaciones de juegos, ya que automatiza actividades como desplazarse y capturar Pokémon. Algunos ejemplos de estos bots son MyGoBot y PokemonGo-Bot. Sin embargo, Pokémon Go ha propiciado el desarrollo de un nuevo tipo de bot, denominado rastreador o mapeador, que proporciona la ubicación de los Pokémon. Estos bots hacen posibles servicios de mapas de Pokémon Go como Pokevision y Go Radar.
Cómo funciona un bot de Pokémon Go
Un bot de API móvil es un programa que imita la comunicación entre una aplicación móvil y sus servidores backend, en este caso, los servidores de Niantic. El bot simplemente comunica a los servidores qué acciones se realizan y procesa su respuesta.
La figura 2 muestra una captura de pantalla de un mapa de Pokémon Go que señala los Pokémon cercanos en un radio de tres pasos desde una ubicación determinada. Para conseguirlo, los creadores de bots suelen seguir estos pasos:
- Aplicar ingeniería inversa al protocolo de comunicación entre la aplicación móvil y el servidor backend. El creador del bot juega, captura las comunicaciones entre la aplicación y su servidor y descifra el formato del protocolo.
- Escribir un programa que realice una serie de solicitudes «legítimas» a los servidores backend para ejecutar acciones. En este caso, obtener la ubicación de Pokémon cercanos consiste en una única solicitud con unas coordenadas GPS específicas, sin tener que desplazarse realmente hasta el lugar físico. El reto para el bot es eludir la detección del servidor y parecer un ser humano real.
- Proporcionar funciones relacionadas, como la integración con Google Maps, o incluir una función de mapas propia del bot para el usuario.

Figura 2. Captura de pantalla de un mapa de Pokémon Go
Ataques y defensas de aplicaciones móviles
Tomando la aplicación Pokémon Go como ejemplo, veamos cómo se vulnera una aplicación móvil mediante ingeniería inversa para desvelar sus secretos. Dado que los atacantes explotaron principalmente la aplicación de Pokémon Go para Android, centrémonos en las técnicas para vulnerar y proteger aplicaciones Android.
Ingeniería inversa del protocolo
La aplicación Pokémon Go y los servidores backend se comunican mediante ProtoBuf a través de SSL. ProtoBuf define el formato de los datos transferidos por la red. Por ejemplo, este es un fragmento de la definición de ProtoBuf para las estadísticas del jugador:

Pokémon Go fue sometido a ingeniería inversa y publicado en internet por POGOProtos en tan solo dos semanas. ¿Cómo fue posible hacerlo tan rápido? Al principio, Niantic no utilizaba fijación de certificados.
La fijación de certificados es un método habitual para protegerse contra ataques de intermediario (Man-in-the-Middle). En pocas palabras, una aplicación móvil solo confía en los certificados de servidor integrados en la propia aplicación. Sin la protección que ofrece la fijación de certificados, un atacante puede configurar fácilmente un proxy como Mitmproxy o Fiddler e instalar en su teléfono un certificado creado por él. A continuación, puede configurar el teléfono para dirigir el tráfico a través del proxy e interceptar el tráfico entre la aplicación Pokémon Go y los servidores de Niantic. De hecho, existe una herramienta proxy específica para Pokémon Go que facilita este proceso, llamada pokemon-go-mitm.
El 31 de julio, Niantic introdujo un cambio importante tanto en su servidor como en su aplicación Pokémon Go. Pokémon Go 0.31.0 se lanzó con protección mediante fijación de certificados. Por desgracia, el secreto ya había salido a la luz y el protocolo de comunicación ya estaba disponible públicamente en GitHub. Además, implementar correctamente la fijación de certificados no siempre es fácil. En las secciones posteriores, abordaremos algunas técnicas que los atacantes suelen utilizar para eludirla.
Análisis estático del APK
El paquete de aplicaciones de Android (APK) es el formato de archivo de paquete que utiliza Android para instalar aplicaciones móviles. Las aplicaciones de Android se escriben principalmente en Java, y el código Java se compila en formato dex y se integra en un archivo APK. Además, las aplicaciones de Android también pueden invocar bibliotecas compartidas escritas en código nativo (NDK de Android).
Es bien sabido que los archivos dex se pueden desensamblar fácilmente a lenguajes SMALI mediante herramientas como Baksmali. A continuación, herramientas como dex2jar y jd-gui permiten descompilar aún más el archivo dex y convertirlo en código Java fácil de leer. Mediante estas técnicas, los atacantes descompilaron la aplicación Pokémon Go para Android (versiones 0.29.0 y 0.31.0) y la convirtieron en código Java. El código de ejemplo que se muestra a continuación implementa la fijación de certificados de la clase com.nianticlabs.nia.network.NianticTrustManager.

Cuando se expone el código fuente de una aplicación, la ingeniería inversa se convierte en algo trivial. Pokemon Go Xposed utilizó menos de 100 líneas de código Java para engañar a la aplicación Pokémon Go y hacerle creer que el certificado de MITMProxy era el certificado auténtico de Niantic.
¿Cómo lo consiguió Pokemon Go Xposed? Muy fácilmente. La herramienta simplemente intercepta la llamada a la función checkServerTrusted mencionada en el fragmento de código anterior. El hook cambia el primer parámetro de la función, chain, por el valor del certificado de Niantic. Esto significa que, independientemente del certificado no autorizado que utilice el proxy, se engaña a la aplicación Pokémon Go para que confíe en él.
Existen muchas herramientas que pueden ayudar a dificultar el desensamblado y el análisis estático por parte de los atacantes. ProGuard y DexGuard son herramientas que aplican técnicas de ofuscación al código Java y a los archivos dex. La ofuscación dificulta la lectura del código, incluso después de descompilarlo. Otro enfoque consiste en utilizar empaquetadores de Android para cifrar el archivo classes.dex original de las aplicaciones Android. El archivo dex cifrado se descifra en la memoria durante la ejecución, lo que hace que el análisis estático resulte extremadamente difícil, cuando no imposible, para la mayoría de los atacantes. El uso de una biblioteca nativa es otra forma de aumentar considerablemente la dificultad de aplicar ingeniería inversa a la aplicación.
Ingeniería inversa de la biblioteca nativa
El juego del gato y el ratón más interesante entre los pokemongodev hackers y Niantic giró en torno al campo denominado «Unknown6», que se incluía en la firma enviada en la solicitud al mapa para obtener los Pokémon cercanos a una ubicación. «Unknown6» es uno de los campos no identificados del protobuf obtenido mediante ingeniería inversa. Al principio, no importaba qué valor se asignara a Unknown6; los servidores de Niantic simplemente lo aceptaban. A partir de las 13:00 (hora del Pacífico) del 03/08, todos los bots de Pokémon Go dejaron repentinamente de encontrar Pokémon, lo que acabó provocando la importante caída de consultas que se muestra en la Figura 1.
Los hackers se dieron cuenta entonces de la importancia del campo «Unknown6» en el protocolo y, en un principio, sospecharon que Unknown6 era algún tipo de resumen o HMAC para validar la integridad de la solicitud. Esto despertó un enorme interés en la comunidad de pokemongodev y rápidamente se formó un equipo «Unknown6» para intentar descifrar el misterioso campo. El canal de Discord se hizo privado debido al gran interés de programadores y personas sin conocimientos de programación, pero un canal de actualizaciones en directo mantuvo a todo el mundo al tanto de los avances del intento de descifrado. Tras 3 días y 5 horas, la tarde del 06/08, el equipo Unknown6 se declaró vencedor y publicó una versión actualizada de la API de Pokémon Go que volvía a ser capaz de obtener los Pokémon cercanos.
Aunque el informe técnico con los detalles del hackeo aún no se ha publicado, en los foros y en el canal de actualizaciones en directo se mencionaron muchas herramientas y tecnologías relevantes. IDA-Pro de Hex-Rays es una herramienta profesional capaz de desensamblar el código ARM de una biblioteca nativa, y el nuevo descompilador de Hex-Rays puede descompilar un archivo de código binario y convertirlo a un formato similar a C. Estas herramientas permiten a los atacantes realizar análisis dinámicos y depurar la aplicación móvil y sus bibliotecas en tiempo de ejecución. Por supuesto, incluso con herramientas tan potentes, aplicar ingeniería inversa a un programa binario sigue siendo extremadamente difícil. Aunque no se haya aplicado ninguna ofuscación intencionada, el código desensamblado o descompilado ya resulta difícil de entender y suele tener un tamaño enorme. Como ejemplo del trabajo complejo e impredecible que fue necesario realizar, el canal de actualizaciones en directo y una entrevista posterior explicaron que la función de cifrado de «Unknown6» se identificó en cuestión de horas, pero que el equipo dedicó mucho más tiempo a analizar otro campo llamado «Unknown22», que resultó no estar relacionado con Unknown6.
Como resultado, la ofuscación sigue ofreciendo muchas ventajas prácticas para proteger las bibliotecas nativas. Un alto nivel de ofuscación en un archivo binario puede aumentar en varios órdenes de magnitud la dificultad de aplicar ingeniería inversa. Sin embargo, como demuestran los numerosos casos en los que se han vulnerado con éxito códigos de serie de Windows y de aplicaciones para Windows, los crackers de aplicaciones móviles con suficiente motivación suelen lograr su objetivo.
Protección del lado del servidor
Las defensas del lado del servidor funcionan de una forma completamente distinta a las del lado del cliente. Estas son algunas de las técnicas utilizadas para proteger la API móvil de Pokémon Go.
Limitación de solicitudes
La limitación de la tasa de solicitudes es un método habitual para intentar detener o, al menos, ralentizar el tráfico automatizado. Al principio, los escáneres de Pokémon podían enviar decenas de solicitudes por segundo, escanear decenas de celdas y encontrar todos los Pokémon.
El 31/07, Niantic añadió medidas de protección para limitar la frecuencia de solicitudes. Si una cuenta enviaba varias solicitudes de mapas en un intervalo de unos 5 segundos, los servidores de Niantic solo aceptaban la primera y descartaban las demás. Los atacantes reaccionaron a estos límites de frecuencia de las siguientes maneras: a) Añadiendo un retraso de 5 segundos entre las solicitudes de mapas de sus programas de escaneo. b) Utilizando varias cuentas y varios hilos para eludir el límite de frecuencia.
En el caso de Pokémon Go, el uso de la limitación de frecuencia no hizo sino abrir otro frente para los ataques automatizados: la creación automatizada de cuentas. Pronto descubrieron que, aunque la limitación de frecuencia es una buena técnica básica para controlar la automatización de scrapers demasiado agresivos o atacantes principiantes, no impide que adversarios avanzados consigan enviar solicitudes automatizadas.
Bloqueo de IP
El bloqueo de direcciones IP es una técnica tradicional que utilizan los cortafuegos de red estándar o los cortafuegos de aplicaciones web (WAF) para descartar solicitudes procedentes de direcciones IP sospechosas. Existen numerosas bases de datos que hacen un seguimiento de la reputación de las direcciones IP, y los cortafuegos y WAF pueden consultar periódicamente esta información.
En general, el bloqueo basado en direcciones IP es arriesgado e ineficaz. Bloquear indiscriminadamente una dirección IP con un gran volumen de tráfico puede acabar bloqueando el NAT de una universidad o empresa. Por otro lado, muchos bots o escáneres de Pokémon pueden utilizar direcciones IP dinámicas residenciales. Estas direcciones IP se comparten entre los clientes de los proveedores de servicios de Internet, por lo que bloquear una dirección IP durante mucho tiempo puede impedir el acceso a jugadores legítimos.
Los servicios de alojamiento como Amazon Web Services (AWS) y Digital Ocean también permiten a los atacantes obtener máquinas virtuales y direcciones IP nuevas. Cuando utilizan tarjetas de crédito robadas, pueden incluso conseguir estos recursos gratis. Sin embargo, los usuarios legítimos nunca utilizan servicios de alojamiento para navegar por Internet o jugar, por lo que bloquear las direcciones IP de estos servicios es una medida de defensa segura y habitual en los servidores. Según esta publicación del foro, Niantic podría decidir bloquear las direcciones IP de AWS.
Análisis del comportamiento
El análisis del comportamiento suele ser la última línea de defensa frente a atacantes avanzados capaces de eludir otras medidas de protección. Los bots se comportan de forma muy distinta a los humanos. Por ejemplo, una persona real no puede jugar las 24 horas del día, los 7 días de la semana, ni capturar 5 Pokémon en un segundo. Aunque el análisis del comportamiento parece un enfoque prometedor, crear un sistema de detección preciso capaz de gestionar un volumen de datos tan enorme como el de Pokémon Go no es tarea fácil.
Niantic acaba de implementar un bloqueo temporal para los tramposos que usan la suplantación de GPS para «teletransportarse» (es decir, desplazarse de repente a una velocidad imposible). Probablemente se optó por un «bloqueo temporal» debido a los falsos positivos: hay familias que comparten cuentas y las lecturas del GPS pueden ser imprecisas, lo que hace que algunos usos legítimos parezcan propios de bots.
Alrededor del 12 de agosto de 2016, Niantic publicó una nota en su sitio web, en la que señaló que infringir sus términos de servicio podría conllevar el bloqueo permanente de una cuenta de Pokémon Go. También se revelaron de forma extraoficial varias reglas de bloqueo dirigidas contra los bots. Por ejemplo, la regla por captura excesiva de Pokémon bloquea las cuentas que capturan más de mil Pokémon en un solo día. Además, Niantic anima a los jugadores legítimos a denunciar a los tramposos o a los jugadores con conductas inapropiadas.
Según nuestra experiencia, la detección basada en modelos de comportamiento puede ser sumamente eficaz, pero a menudo resulta inviable desarrollarla internamente por motivos técnicos o económicos. Como señaló Niantic en una publicación de su blog: «Abordar este problema también tiene un coste de oportunidad. Los desarrolladores tienen que dedicar tiempo a controlar este problema en lugar de crear nuevas funciones». El problema principal es que desarrollar tecnología para defenderse de adversarios persistentes y con amplios conocimientos técnicos, equipados con redes de bots y otras herramientas diseñadas para eludir las defensas habituales, requiere numerosas competencias altamente especializadas y un enorme esfuerzo de desarrollo.
La partida no ha terminado
Mientras Pokémon Go siga contando con el cariño de los jugadores, la batalla entre los creadores de bots y Niantic también continuará. Defenderse del tráfico automatizado supone un reto no solo para el sector de los videojuegos, sino para todos los sectores. Se están produciendo actividades similares de ataque y defensa en aplicaciones bancarias, de aerolíneas y de comercios minoristas, donde hay muchísimo más en juego que perder unos cuantos Snorlax. Los bots y las herramientas de ataque relacionadas no son ningún juego para las empresas cuando sus clientes y usuarios no pueden acceder a los servicios debido al tráfico automatizado no deseado.
Sobre el autor
Artículos relacionados del blog

Cree servicios públicos seguros, resilientes y preparados para la IA con F5 y AWS
Descubre cómo las organizaciones del sector público pueden modernizar de forma segura sus aplicaciones y soluciones de IA, al tiempo que gestionan los sistemas heredados, el cumplimiento normativo y el riesgo operativo.
Protección de los sistemas de IA: por qué la seguridad debe avanzar al ritmo de la innovación
Desde acelerar avances revolucionarios en medicina y educación hasta transformar la vida cotidiana, la IA está cambiando nuestra forma de vivir y trabajar. Pero también ofrece grandes oportunidades a los ciberdelincuentes.
Avanzar hacia la optimización digital tras la transformación
Descubre estrategias de optimización digital para garantizar políticas de seguridad coherentes, impulsar la madurez de la transformación digital y superar los retos de la transformación.
Proyecto de código abierto destacado: mayor observabilidad con F5 Cloud Logger iApp
En el punto de mira del código abierto: cómo aumentar la observabilidad. Lee el blog de F5 para descubrir cómo exportar fácilmente la telemetría de BIG-IP a plataformas modernas de análisis en la nube.
El estado de la entrega de aplicaciones en 2018: la transformación digital impulsa la automatización y la multinube pese a las preocupaciones de seguridad
Descubre las principales conclusiones del cuarto informe anual de F5 sobre el estado de la entrega de aplicaciones.
Estado de la entrega de aplicaciones en 2017: automatización, API y DevOps
Descubre el informe sobre el estado de la entrega de aplicaciones de 2017. Lee el blog retrospectivo de F5 sobre los inicios del auge de las redes declarativas y los flujos de DevOps.