Header Ads Widget

Ticker

6/recent/ticker-posts

Cómo los fanáticos de Pokémon Go los piratearon a todos: y cómo prevenir una ingeniería inversa similar

Todo desarrollador espera tener una enorme base de usuarios poblada por grandes cantidades de usuarios mensuales. La gente que usa una aplicación en todo su potencial en miles, si no cientos de miles, es un sueño hecho realidad. Desafortunadamente para los servicios de API , con una mayor exposición se produce un marcado aumento de la vulnerabilidad .

La clave de este tema es el concepto de ingeniería inversa ; el proceso de separar una función en sus características básicas y descubrir cómo usarlas para otros fines. Si bien estas discusiones son a menudo teóricas, limitadas a experimentos mentales y permutaciones de otros éxitos y fracasos, esta discusión se basa en un ejemplo reciente del mundo real: Pokémon Go .

Ahora que el polvo se ha asentado, vamos a discutir el lanzamiento de Pokémon Go, el proceso y el efecto de la ingeniería inversa que soportó, y algunas lecciones aprendidas que pueden usarse para prevenir problemas similares en otros ecosistemas.


Esta publicación se inspiró en la charla de David Stewart en la Cumbre de la Plataforma 2016

Fanboy Rising

"Las personas que estaban jugando con la API ... No eran hacktivistas, en realidad eran entusiastas de los juegos que sabían de programación, no son realmente malos".

Pokémon Go fue un gran éxito instantáneo, algo que no es difícil de creer dada la fama de la marca Pokémon. Si bien el juego finalmente alcanzaría un máximo de 45 millones de usuarios simultáneos, comenzaron a surgir problemas incluso durante la semana de lanzamiento inicial. Por ejemplo, las primeras versiones de Pokémon Go tenían muy poca seguridad para algunas funciones básicas, como la geolocalización . Los jugadores se enteraron de esto e inmediatamente lo usaron para su propio beneficio.

Con la ingeniería inversa del servicio de geolocalización y la entrega de datos geográficos falsos , los jugadores pudieron "controlar" a su personaje en el juego, ignorando la premisa básica de la aplicación de capturar Pokémon en las inmediaciones del jugador y, en cambio, permitir a los jugadores viajar por el mundo, incubar huevos en minutos en lugar de horas.

Además, los jugadores pudieron aplicar ingeniería inversa a la forma en que la aplicación manejaba la Pokedex , revelando todos los Pokémon actuales y sus ubicaciones de generación (y específicamente qué Pokémon estaban bloqueados en regiones específicas).

Esto fue impulsado en gran medida por los fanáticos, por supuesto: muchos fanáticos se sintieron enojados por la falta de claridad sobre cómo funcionaban ciertas funciones, como el servicio de Proximidad Pokémon y cuán preciso era en realidad, y decidieron averiguarlo por sí mismos. Utilizaron ataques simples de hombre en el medio , interceptando la comunicación de la aplicación, y comenzaron su trabajo de excavar a través de las funciones de la aplicación.

El hecho de que los servidores no estuvieran preparados para manejar volúmenes tan grandes de usuarios también fue un problema: los problemas iniciales al unirse a los servidores y los tiempos de carga lentos resultantes y la falta de datos precisos provocaron el descontento bastante temprano en el ciclo de vida.

Muy pronto, los piratas informáticos comenzaron a utilizar la automatización en su proceso de ingeniería inversa, pasando de las pruebas individuales a las pruebas de comando masivas . Esto alertó a Niantic (además de la cobertura mediática de las fallas de seguridad), quien respondió rápidamente.

Su respuesta fue específica y estaba dirigida a estos fanáticos que realizaban ingeniería inversa: en primer lugar, Niantic implementó la fijación de certificados en un intento de terminar con los ataques del hombre en el medio, y luego deshabilitó aún más la funcionalidad de Proximidad Pokémon en un intento de romper las aplicaciones modificadas que usaban la función de formas no deseadas.

El daño de muchas maneras ya estaba hecho. Debido a lo que los jugadores aprendieron de su ingeniería inversa antes de que se lanzara el parche, la fijación de certificados se rompió casi de inmediato y se restauró la función de proximidad, una función que muchos jugadores estaban enojados por perder.

Leer más: API de la Guerra Mundial: Entender al enemigo

Esta funcionalidad no solo se restauró, de hecho, se amplió. Las aplicaciones y los sitios web comenzaron a aparecer utilizando la función para mostrar las ubicaciones GPS exactas de los Pokémon cercanos, negando gran parte del propósito de las aplicaciones como plataforma social y aprovechando la generación de ingresos publicitarios.

Luego, Nitantic respondió con un parche adicional que implementaba el cifrado "desconocido6", que admitía la autenticación de suma de comprobación para garantizar que las solicitudes de la aplicación fueran legítimas y procedieran de un cliente conocido. Una vez más, sin embargo, los fanáticos usaron la información recopilada en la ingeniería inversa inicial para exponer la API y averiguar cómo se manejó el cifrado del lado del cliente; debido a esto, el nuevo cifrado se rompió en cuatro días , evitando la protección de suma de comprobación.

Niantic respondió con una solución urgente cuando se rompió la suma de comprobación, implementando comprobaciones de raíz y requiriendo finalizaciones de Captcha. Siguieron este parche con una ronda de amenazas legales contra conocidos ingenieros de la comunidad.

Si bien la aplicación es mucho más segura ahora, los efectos de las numerosas rondas de ingeniería inversa fueron impactantes. Niantic perdió la imagen de marca , en gran parte porque muchos fanáticos vieron sus acciones como contrarias a su disfrute, lo que muchos sintieron que era injusto para Niantic, ya que la aplicación fue diseñada para usarse de cierta manera, y las únicas personas afectadas fueron las que la usaron de manera no autorizada. .

Por supuesto, esto solo provocó más desacuerdos y más daño a la marca.

Luego está, por supuesto, la pérdida de la felicidad del jugador. La experiencia del usuario es clave para la felicidad y el éxito a largo plazo de una aplicación, y perder la buena voluntad de la base de jugadores, ya sea justificada o no, nunca es algo bueno.

Finalmente, Niantic perdió ingresos debido a los flujos de ingresos redirigidos de las implementaciones de terceros y al esfuerzo y costo de ingeniería no planificados para mitigar el problema en cuestión.

Conozca a su audiencia: 4 preguntas que los proveedores de API deben hacer a sus usuarios

4 lecciones importantes aprendidas

Entonces, con eso en mente, ¿qué podemos deducir de la situación que enfrenta Niantic?

En primer lugar, está el hecho de que la comunicación es una moneda increíblemente importante y vital en el mundo del desarrollo móvil. Gran parte de la ingeniería inversa inicial fue en respuesta a una falta de claridad percibida. Si los sistemas se hubieran explicado o elaborado, la piratería inicial podría haber sido mucho más limitada en alcance o propósito.

En segundo lugar, está el hecho de que Niantic no planificó el éxito . Debido al gran volumen de usuarios desatados en Pokémon Go, ciertas funciones no funcionaron como se esperaba. El equilibrio del servidor a menudo resultaba en una carga lenta y la funcionalidad de proximidad no siempre era precisa.

En tercer lugar, estaba el problema de la actualización continua en formato de revisión a un problema conocido. Cuando Niantic actualizó sus enfoques de seguridad, estaban actualizando partes ya expuestas y, debido a que reutilizaron ciertos datos y metodologías, sus nuevas funciones se rompieron fácilmente.

En cuarto lugar, Niantic cometió lo que muchos consideran un pecado capital: enojaron a su base de usuarios. Si bien el control sobre una aplicación es increíblemente importante, al sofocar la exploración inicial y no informar directamente a los usuarios sobre la funcionalidad, alienaron a algunos usuarios y amargaron a otros. Esto llevó a las acciones que tanto les perjudicaron.

Finalmente, Niantic sufrió por tener demasiados vectores de ataque y no tuvo la oportunidad de responder adecuadamente antes de que otro problema estuviera al frente. Esto mermó gravemente la eficacia de las soluciones elegidas y generó nuevos problemas con cada solución.

Soluciones

Afortunadamente, existen algunas soluciones a estos problemas. Si bien puede haber mucha discusión sobre si Niantic merecía o era responsable de los problemas que enfrentaron (este autor cree que no lo fueron), los problemas que enfrentaron se pueden utilizar como la base de nuevos pasos y procedimientos para un desarrollador que presenta una aplicación. en el espacio móvil.

Comunicación

La comunicación es vital, no se puede enfatizar lo suficiente. Si bien no se debe compartir cierta cantidad de información, Niantic podría haber dejado más claro cómo funcionaban ciertas funciones. Esta gama de comunicación podría haber sido tan formal como la creación de un foro, la creación de un sitio wiki o incluso la publicación de una guía completa en su sitio. Por el contrario, podría haber sido algo tan simple como una declaración oficial en Twitter.

Lo que realmente importa es el aspecto de la comunicación. Afirmar que los datos geográficos tenían problemas de precisión en la función de proximidad debido a la sobrecarga, si ese fuera realmente el problema, habría contribuido en gran medida a convencer a muchos de los que realizaron ingeniería inversa para que dejen la aplicación en paz.

Lo mismo ocurre con las actualizaciones de respuesta. Si Niantic se hubiera comunicado directamente con los puntos de venta de tecnología y los fanáticos, indicando cuáles eran los problemas, por qué implementaron una nueva función de seguridad y cuáles son sus planes, podrían haber implementado sus funciones de seguridad y mitigar los temores de que las funciones por las que la gente luchaba. volver de hecho volvería, y de una manera legítima.

Gran parte de esto fue, por supuesto, que los fanáticos se negaron a escuchar: estos datos estaban disponibles de una forma u otra, pero podrían haber sido, y en el futuro deberían ser, compartidos de una manera más completa y profética.

Planifique para un éxito increíble

"El hecho es que la mayoría de las empresas no planifican el éxito, no están preparadas para el éxito".

Niantic no estaba preparado en muchos sentidos para el éxito que tendría Pokémon Go, y ¿quién podía culparlos? Los números iniciales se dispararon más allá de las expectativas y entraron en el ámbito elevado de la viralidad, y permanecieron allí durante semanas.

La gran cantidad de solicitudes se volvió difícil de manejar, lo que provocó problemas en la comunidad para la carga y la estabilidad del servidor. Esto causó enojo, pero también hizo que el sistema estuviera mucho más expuesto a fallas de memoria y otros ataques similares.

El mejor enfoque aquí es planificar un éxito increíble. Tome sus sueños más salvajes de éxito, luego triplíquelos : ese es el estándar de oro para el que debe desarrollar. Código en instanciación. Suscríbase a las prácticas de virtualización para poner en marcha nuevos servidores donde se necesita equilibrio de carga. Implementar un filtrado volumétrico adecuado.

Lo más importante es implementar correctamente el cifrado y la autenticación desde el principio y ofuscar la API: cuantos más usuarios obtenga, mejor será la aplicación, pero inevitablemente más vulnerable.

Pokémon Go no es un incidente aislado: API de la Guerra Mundial: ciberataques a escala internacional

Actualización, no revisión

Hotfixing es una tirita, y una tirita solo es buena para heridas pequeñas y temporales. Cuando se descubrieron agujeros tan grandes en la seguridad, el primer paso que tomó Niantic debería haber sido el último paso que dieron en la implementación de funciones de seguridad para erradicar el uso ilícito.

En su lugar, se vieron obligados a utilizar hotfixing . Las revisiones no son solo una actualización a medias, a menudo son solo una solución temporal y agregan esfuerzo adicional al desarrollador y tiempo que se puede invertir mejor en simplemente notificar a los usuarios sobre el problema de seguridad y desarrollar una actualización integral y receptiva.

Si bien se podría argumentar a favor de tapar un agujero peligroso rápidamente antes de esperar una actualización completa, las revisiones pueden introducir problemas adicionales (como lo hicieron en este caso), provocando un bucle de retroalimentación de revisión tras revisión.

Mejor aún, evite estas actualizaciones simplemente utilizando la solución adecuada para empezar, al igual que con la planificación para el éxito, planifique para el fracaso. Mire su peor escenario de ataque, triplíquelo y prepárese para el ataque. Si te preparas para una guerra con 1000 guerreros, y solo 200 oponentes aparecen en el campo de batalla, ganarás el 100% del tiempo. Trate las API de la misma manera. Prepárate para lo peor, espera lo mejor.

Haz que los fans, fans

“Si atrapas a la gente y la molestas […] pueden volverse en tu contra. Y cuando se vuelven contra ti, pueden causar un daño grave ".

Las personas que usan su aplicación lo hacen porque ven valor. Ya sea que ese valor sea en forma de entretenimiento o al unirse al flujo de ingresos, los usuarios están usando su aplicación con un propósito. Cuando Niantic actualizó su aplicación para evitar abusos, alienó a muchos usuarios que sentían que los estaban tratando injustamente.

Se podrían argumentar que este sentimiento no estaba justificado, pero el simple hecho es que lo sintieron, y por eso, los esfuerzos de ingeniería inversa se duplicaron simplemente para "pegarle a Niantic".

Haz que los fans, fans. Escúchalos. Extiende una mano. En lugar de amenazar con emprender acciones legales contra los fanáticos de la ingeniería inversa, hable con ellos sobre por qué lo están haciendo, cómo lo están haciendo y qué se puede hacer para detenerlo. Interactúe con los usuarios como iguales y no los mantenga a oscuras.

Tu mayor enemigo es un amigo de una sola vez, y tu mejor amigo puede ser un enemigo de una sola vez. Utilice su habilidad a su favor y vea cuál es su razonamiento. Si las características de proximidad se hubieran refinado y discutido con la base de fanáticos, mucho de lo que estamos hablando aquí hoy podría nunca haber sucedido.

Reducir la superficie de ataque

Finalmente, y quizás lo más importante, reduzca su superficie de ataque . La aplicación Pokémon Go estaba plagada de vías a través de las cuales realizar ingeniería inversa, lo que llevó a que cada solución posterior se rompiera casi de inmediato. Al exponer tanto a tantos, Niantic se preparó injustamente para luchar desde el principio.

Los desarrolladores deben facilitar este proceso para ellos mismos: no reducir la superficie de ataque mediante servidores de equilibrio de carga, ofuscar el código y ocultar los sistemas es simplemente hacer la batalla más difícil para los ingenieros y desarrolladores que tendrán que responder.

Esto casi no hace falta decirlo: reducir, reducir, reducir. Cualquiera que haya conducido una motocicleta puede decirle que no se sienta perfectamente derecho mientras conduce por la carretera, ya que su cuerpo genera demasiada resistencia. En cambio, se estrecha y reduce su marco.

Lo mismo ocurre aquí: reduce su superficie de ataque y estará mejor para ello.

Conclusión

Es lamentable que el espacio móvil se enfrente a este tipo de problemas con tanta frecuencia, pero el hecho es que los problemas están aquí y no van a desaparecer. Al adherirse a estos principios básicos, los desarrolladores pueden salir ilesos de la mayoría de los lanzamientos, con optimismo en su apoyo a largo plazo.

El filósofo, ensayista y poeta George Santayana dijo una vez que "aquellos que no pueden recordar el pasado están condenados a repetirlo". Independientemente de que los problemas que enfrentó Niantic fueran justificados o justos, podemos usar sus experiencias para aprender y perfeccionar y evitar que vuelva a suceder.

Recursos externos

  • Estado actual de la API de PokemonGO  (hilo de Reddit)
  • La actualización de Pokémon Go toma medidas enérgicas contra los piratas informáticos (Inquisitr)
  • La próxima actualización de Pokémon GO finalmente bloquea a los tramposos (Slash Gear)

 

Publicar un comentario

0 Comentarios