Header Ads Widget

Ticker

6/recent/ticker-posts

Compras en la aplicación de ingeniería inversa dentro de las API de juegos móviles

 

ingeniería-inversa-en-compras-de-aplicaciones-dentro-de-juegos-móviles-apis-nordic-apis-sandoval

Hackear es un término increíblemente incomprendido. Los medios de comunicación han retratado la práctica en uno de dos extremos: o un hacker es un "antihéroe" misterioso y encapuchado que lucha contra el gran mal de la corporatocracia , o un héroe de la contracultura estereotipadamente caprichoso que grita "piratea el planeta" .

El hecho es que la piratería se realiza generalmente con un solo propósito: la auto recompensa , generalmente impulsada por la observación de vulnerabilidades obvias . Ya sea que esto signifique que un sistema está roto para robar números de tarjetas de crédito o simplemente para desarrollar una herramienta que un desarrollador aún tiene que desarrollar internamente, la piratería generalmente se enfoca en la recompensa personal.

Hoy vamos a analizar una de las industrias más pirateadas del mundo: los juegos monetizados para dispositivos móviles . Analizaremos las vulnerabilidades comunes inherentes a estos sistemas, cómo generalmente se piratean y cómo evitar que esto ocurra y que interrumpa el flujo de ingresos de un desarrollador.

Definición de piratería

Lo primero es lo primero: tenemos que definir la piratería. Los primeros piratas informáticos se denominaron así por sus habilidades para "hackear" una máquina o dispositivo. Uno de los piratas informáticos preeminentes de la primera comunidad centrada en los teléfonos, los "phreakers", fue John Draper, más conocido por su apodo de "Capitán Crunch". El apodo era apropiado: tenía la capacidad de usar un silbato obtenido de una caja de cereal Captain Crunch para emitir tonos que romperían la red de AT&T. En un caso, [afirmó conectarse a través de tableros de interruptores telefónicos en países como Japón, Rusia e Inglaterra. Después de la ruta, llamaba a un teléfono público junto a él, y cuando sonaba, hablaba por teléfono, esperando unos segundos antes de escucharse a sí mismo débilmente en el primer auricular .

Aunque la piratería tomó un giro decididamente más oscuro a medida que las tarjetas de crédito y la banca se incorporaron a la tecnología, la mayoría de los piratas informáticos modernos no son maliciosos. Tenga en cuenta que a lo largo de este artículo, cuando hacemos referencia a un pirata informático, es a quien nos referimos: el chico de dieciséis o diecisiete años al que no le gusta el modelo "freemium" de los juegos móviles, que solo quiere algunos cientos de juegos falsos. moneda o engañar a un cronometrador que restringe su progresión.

Sin embargo, con eso en mente, debemos dejar una cosa clara: las API nórdicas no aprueban la piratería , y esta pieza no debe considerarse una guía para la piratería o una inspiración en ella. Al exponer estos métodos, esperamos dar a los desarrolladores de API una mirada a la mentalidad de un pirata informático de API en el espacio de los juegos y las vulnerabilidades que normalmente buscan.

Vulnerabilidades de los juegos: juegos estáticos frente a juegos móviles

¿Qué hace que los juegos móviles sean tan pirateados? ¿Qué hace que sea tan atractivo de romper y tan fácil de eludir? Para entender eso, primero debemos entender la diferencia entre juegos estáticos y móviles.

Cuando decimos juegos estáticos , lo que realmente queremos decir es juegos "domésticos". Esto podría incluir una consola, una PC o incluso un gabinete de juegos en un bar o pizzería. Por lo general, estos dispositivos son difíciles de piratear y, por lo tanto, no resultan muy atractivos para el pirata informático medio. Las consolas están diseñadas para no permitir la elusión de los sistemas anti-trampa o para que el software casero se ejecute de forma nativa, y los juegos de arcade suelen estar en cajas grandes y voluminosas, bloqueadas para el público en general.

Las PC son una historia un poco diferente, ya que estos dispositivos permiten un pirateo bastante fácil para los usuarios expertos, pero requieren un nivel muy alto de conocimiento y capacidad para sortear la ofuscación, el código propietario, etc. Por esta razón, la piratería es muy popular en la PC, aunque los lanzamientos pirateados a menudo se retrasan bastante.

Sin embargo, todas estas situaciones de juego estático tienen una cosa en común: todas manejan el procesamiento internamente . Piense en Metal Gear Solid , Kerbal Space Program o incluso en juegos más antiguos como Tetris . Con muy pocas excepciones (típicamente en juegos multijugador), los juegos en entornos estáticos llevarán a cabo el procesamiento de datos, entrega de video, mecánica, etc. de forma nativa en el sistema en el que está instalado. Esto significa que los hacks, nuevamente con muy pocas excepciones, generalmente permanecen dentro del sistema con el que se originaron.

Los juegos móviles son una historia completamente diferente. Los juegos móviles, por su propia naturaleza, están diseñados para funcionar en plataformas ligeras. Aunque los dispositivos móviles se han vuelto mucho más poderosos que nunca, el hecho es que el procesamiento, las escalas de puntuación e incluso las mecánicas del juego a menudo se envían desde el dispositivo a un servidor externo, donde los datos se procesan, reempaqueta y entregan. para manipulación en el dispositivo.

Esto expone una falla de seguridad masiva que no es inherente al mundo de los juegos estáticos. Salvo la funcionalidad multijugador, todas las mecánicas, sistemas de progresión, etc. de los juegos estáticos se pueden manejar normalmente fuera de línea. Si bien los juegos móviles aún se pueden jugar sin conexión (como en el caso de un juego como Fallout Shelter ), muchos juegos (incluidos Clash of Clans y Candy Crush ) dependen de la funcionalidad en línea para la mayor parte de su juego.

En resumen, los datos deben salir del dispositivo a través de una API, ingresar a un servidor, salir de ese servidor nuevamente y regresar al dispositivo. Este intercambio crea tres vulnerabilidades únicas que pueden conducir a la piratería y la ruptura efectivas de los esquemas de monetización de API.

También relacionado: la API de su aplicación de iPhone NO es privada

Vulnerabilidad móvil n. ° 1: dispositivos y llamadas

El primero de estos pasos es cuando los datos salen del teléfono por primera vez. Esto representa posiblemente el área más grande de piratería en la industria de los juegos móviles y, con mucho, el enfoque más fácil: piratería mediante modificación de código o inyección de código.

Veamos un escenario. Se acaba de lanzar un nuevo juego, llamado API Quest . En este juego, construyes fortalezas para defenderte de las amenazas de seguridad y vistes a tus caballeros con una armadura especial de mithril diseñada para resistir cualquier ataque .

¿La frotada? Crear estas defensas y armar a tus caballeros requiere dinero en la aplicación que solo puede ser recolectado por generadores automáticos, que otorgan fondos cada cinco minutos. Por el contrario, esta moneda se puede comprar, estableciendo un flujo de moneda de suscripción activa.

Un jugador perspicaz mira el código del juego y se da cuenta de algo interesante: el jugador está definido y los fondos recibidos son generados por una llamada URI que envía una solicitud a un servidor para un aviso de temporizador. Esto podría estructurarse como tal:

player class.id { role:player}

Esta información se guarda en el dispositivo y luego se envía a un receptor remoto a través de un URI para solicitar el estado del temporizador:

GET http://apiquest.com/statuscounter/{role}

Esta solicitud utiliza una API patentada que utiliza los datos del sistema en el dispositivo para generar la sustitución de roles. Cuando el rol se sustituye por "jugador", la solicitud se envía a un servidor, que utiliza un equilibrador de carga para distribuir el tráfico y luego verifica un temporizador en el servidor.

Desafortunadamente, esta información se basa en el dispositivo. El jugador se da cuenta de esto y edita el código del juego para reflejar su rol como "devuser", y se da cuenta de que la API también usa una verificación similar para verificar el estado del usuario:

GET http://apiquest.com/userstatus/verify

Luego editan el dispositivo para rechazar una llamada al servicio de verificación, que falla sin una copia de seguridad. Al editar el código del juego, el usuario se ha configurado como devuser, con acceso a un temporizador de un segundo en el que se basan todos sus equipos y generadores.

Aquí, tenemos dos vulnerabilidades: la ofuscación del código y la integridad de la llamada. Debido a que el código no estaba oculto y, por lo tanto, no estaba oculto, el usuario pudo ver exactamente cómo el URI utilizó el código del juego para generar información de verificación para el temporizador remoto y pudo cambiarlo para romper el sistema. Además, debido a que el dispositivo no tenía verificación de integridad de llamadas, se envió una llamada desde un dispositivo de confianza firmado, en el que el servidor confiaba implícitamente.

La respuesta es simple: ofusque su código y verifique todas las llamadas que salen de un dispositivo. El desarrollador implementa un verificador de llamadas en el juego, que verificará todos los datos que salen de la aplicación para asegurarse de que no se esté inyectando o modificando nada. Ofuscan aún más el código.

Vulnerabilidad móvil n. ° 2: integridad del servidor

Ha salido un nuevo parche, rompiendo el engaño del jugador. Enojado, el hacker examina el dispositivo y nota que el código ahora está ofuscado y que los métodos anteriores han cambiado.

Sabiendo que la culpa es de una llamada URI mal formada, el hacker decide probar el servidor. Las llamadas URI ahora son verificadas por el juego antes de ser enviadas por el dispositivo, anulando su ataque original. Sin embargo, notan que el servidor que atacaron tenía una dirección IP frontal y un esquema de nombre: http://apiquest.com/.

Al probar el sistema desde una PC, envían una solicitud de URI al servidor y descubren que se acepta, pero se rechazan por ser un "dispositivo no registrado". Luego, el jugador usa su dispositivo, encuentra la dirección IP del dispositivo en su subred privada y la agrega a la llamada original al enrutarla a través del dispositivo.

Ahora, pueden enviar una solicitud bajo la dirección del dispositivo sin pasar primero por el juego, evitando las restricciones en el dispositivo por completo.

Aquí, una tercera vulnerabilidad: aunque el juego en sí mismo verificó las llamadas URI y el servidor ahora estaba diseñado para resistir llamadas mal formadas, las llamadas recién descubiertas podrían enviarse independientemente de la aplicación . La seguridad deficiente del servidor resultó en la piratería efectiva del URI, lo que viola el servidor. Aunque el teléfono fue reforzado, el servidor no.

La respuesta aquí también es simple: implemente restricciones de URI a nivel de servidor y rechace el tráfico entrante que no coincida con el protocolo administrado por su sistema de verificación de dispositivos.

Consulte también: Cómo controlar la identidad del usuario dentro de microservicios

Vulnerabilidad móvil n. ° 3: respuesta del servidor

El jugador se da cuenta de que su truco ya no funciona. El servidor ahora tiene restricciones adicionales y requiere lo siguiente para una solicitud efectiva:

GET http://apiquest.com/statuscounter/{role}
User-Agent: AndroidMobile
Accept-Language: en-us

Esto ahora establece una conexión desde un agente conocido, limitado a dispositivos móviles.

Han probado todo el tráfico saliente, pero nada es efectivo. Se dan cuenta de que las llamadas que regresan están en texto sin formato y completamente no confusas. Cuando el servidor responde, responde con un conjunto de códigos:

reward-user:10g
timer-reset:120s

Esto recompensa 10 de oro y restablece el temporizador local a 120 segundos, que es el tiempo entre llamadas URI. Sabiendo esto, el jugador interviene cuando el tráfico llega a través de su enrutador, capturando el paquete y terminándolo. Luego ajustan este paquete, cambiando los datos para leer en su lugar:

reward-user:99999999999g
timer-reset:9999999999s

Monetización de las API de juegos de monedas de las API nórdicas

Esta llamada les da un oro casi infinito y obliga a las llamadas URI a dejar de funcionar de manera efectiva (debido a que el valor de verificación del temporizador se cambió de 120 segundos a 9999999999 segundos), lo que significa que cualquier sistema de verificación de estado o anti-trampas, como se muestra arriba, lo haría. deje de funcionar correctamente.

La solución aquí es la más fácil de todas: no use respuestas simples . En lugar de recompensar una cantidad generada fuera del dispositivo, establezca la cantidad en el dispositivo y, en su lugar, ate el temporizador al reloj interno y al reloj del servidor, que ambos deben estar de acuerdo antes de liberar oro. Esto tiene el beneficio adicional de no permitir exploits de día cero que pueden usar este problema en seguridad para lanzar ataques masivamente coordinados, enfrentando su propia aplicación contra sus propios servidores.

Funcionalmente, todos estos problemas se pueden solucionar correctamente con dos simples pasos: ofuscar el código y las llamadas y cifrar la conexión entre el dispositivo y el servidor.

Conclusión

En el mundo de las API, sea cual sea el estilo de arquitectura que elija y el lenguaje en el que diseñe , la seguridad siempre tendrá que ser un enfoque amplio y específico. Los teléfonos Android, iOS y Windows deben tratarse como lo que son: dispositivos potentes que pueden rivalizar incluso con los mejores diseños de seguridad.

Sin embargo, con una ofuscación inteligente y una preparación contra los escollos comunes, estas amenazas pueden evitarse en gran medida. Para capturar a un hacker, debes pensar como un hacker. Considere su solicitud de la misma manera que lo haría con una cuenta bancaria o una casa, y pregúntese: "¿Es esto tan seguro como podría ser?" Es mejor averiguarlo ahora que dejar que alguien te lo cuente más tarde a través de sus tortuosas acciones.

Publicar un comentario

0 Comentarios