Frikipandi – Web de Tecnología – Lo más Friki de la red. Web de Tecnología con las noticias más frikis de Internet. Noticias de gadgets, Hardware, Software, móviles e Internet. Frikipandi 
Tres vulnerabilidades de Fortnite exponen los datos personales y de tarjetas de crédito de los jugadores.
Jugados en un mundo virtual, los jugadores de «Fortnite», el juego enormemente popular del desarrollador de juegos Epic Games, tienen la tarea de probar su resistencia mientras luchan por las herramientas y las armas que los mantendrán seguros y al «último hombre en pie».
Sin embargo, en las últimas semanas, la compañía de ciberseguridad Check Point ha descubierto tres nuevas vulnerabilidades en el registro de cuentas del videojuego Fortnite que han dejado expuestos los datos personales y de tarjetas de crédito de los jugadores.
A través de estas vulnerabilidades, los ciberatacantes podían hacerse con el control de las cuentas de usuarios de Fortnite, con la posibilidad de hacer compras de objetos del juego con la moneda virtual V-Buck, como ha alertado Check Point a través de un comunicado.
Este problema también afecta a la privacidad, ya que el ciberdelincuente podría escuchar las conversaciones dentro de Fortnite accediendo al sonido grabado por el micrófono de los usuarios durante el juego, así como a la información personal almacenada en las cuentas.
Check Point Research informó a Epic Games de esta vulnerabilidad y se implementó una solución de manera responsable, asegurando que sus millones de jugadores puedan continuar su juego en un entorno seguro.
Estas nuevas vulnerabilidades podrían haber sido explotadas sin que el jugador introduzca ningún dato de acceso. Para ello, se aprovecha la infraestructura web de Epic Games y el sistema de autenticación basado en ‘tokens’.
Los mecanismos de la web del videojuego, junto con los sistemas de acceso unificado Single Sign-On (SSO) como Facebook, Google y Xbox, han podido utilizarse para robar las credenciales de acceso del usuario y hacerse con la cuenta de la víctima si esta hace clic en un enlace de ‘phishing’, según Check Point.
Una vez que se hace clic, el ‘token’ de autenticación de Fortnite del usuario puede ser capturado sin que el usuario tenga que introducir ninguna credencial. La vulnerabilidad se originó por los defectos encontrados en dos de los subdominios de Epic Games que eran susceptibles a una redirección maliciosa.
La compañía de ciberseguridad ha informado a Epic Games, la desarrolladora de Fortnite, acerca de las vulnerabilidades de su videojuego, que suma cerca de 80 millones de jugadores a nivel global. En la actualidad, el problema ya se ha solucionado, según Check Point.
Os dejamos a continuación su explicación técnica. Tres vulnerabilidades de Fortnite. Check Point las ha explicado una vez resueltas.
Detalles técnicos
Se encontró que Epic Games tiene varios subdominios antiguos, como ‘ http://ut2004stats.epicgames.com ‘. Es en este lugar donde comienza nuestra historia.
Inyección SQL
El subdominio, ‘ http://ut2004stats.epicgames.com ‘, nos llevó a una interesante solicitud GET con la siguiente ruta: «/serverstats.php?server=[some server code]».
¿Qué pasaría, preguntamos, si se agregara un signo a la solicitud?
Bueno, la respuesta fue: «Error en la base de datos del servidor»!
Este fue sin duda un gran avance, ya que nos dimos cuenta de que esto podría tener el potencial de una inyección SQL (en esta etapa, asumimos que estamos tratando con la base de datos MYSQL).
La investigación reveló que había un producto WAF, que trabajaba con listas negras en lugar de listas blancas con las que primero tendríamos que tratar. Como resultado, una de las limitaciones que se nos impuso fue la imposibilidad de consultar varias tablas del sistema (como las tablas de “esquema de información”).
Pero, ¿y si pudiéramos usar las variables del sistema (@@)? De hecho, ¡parecía que alguien se había olvidado de su existencia ya que funcionaba mejor de lo que jamás hubiéramos deseado!
if ((SUBSTR (consulta, desde, longitud) = CHAR ([char_number])), verdadero, falso)
Luego de una búsqueda en Google, encontramos que “37514065” es un código de servidor válido. Con esto en mente, realizamos la siguiente consulta para ver qué respuesta obtendríamos:
La respuesta: 4014 bytes, lo que significa que este carácter no aparece en la consulta. Una respuesta con 12609 bytes, por otro lado, habría significado que el carácter aparece en el resultado de la consulta.
Por ejemplo: if ((SUBSTR (@@ version, 1,1) = CHAR (52)), 37514065,0) devuelve con 4014 bytes:
Solicitud:
Figura 1: La consulta inicial de inyección SQL.
Respuesta:
Figura 2: La respuesta de 4014 bytes de la consulta SQL inicial.
Por supuesto, si la consulta ‘if ((SUBSTR (@@ version, 1,1) = CHAR (53)), 37514065,0)’ respondiera con 12609 bytes, entonces sabríamos que se estaba utilizando la versión 5 de MySQL .
Figura 3: La segunda consulta de inyección SQL.
Figura 4: La respuesta de 12609 bytes de nuestra consulta SQL.
De esta manera, los datos que conseguimos obtener serían muy útiles para las etapas posteriores de nuestra investigación.
Secuencias de comandos entre sitios (XSS )
A medida que avanzábamos en nuestra investigación, encontramos que el subdominio ‘ http://ut2004stats.epicgames.com ‘ contenía una página web llamada «mapas». Supusimos que esta página web se utiliza para presentar estadísticas de torneos ordenadas por nombre / id del mapa.
Cuando busca vulnerabilidades de XSS, tanto las reflejadas como las almacenadas, está claro que debe buscar un reflejo de su entrada en la página, y esto es exactamente lo que encontramos en el componente de búsqueda. De hecho, otra característica de esta página es la barra de búsqueda que actuaría como punto de inyección para la vulnerabilidad XSS.
Ejemplo:
Este fue nuestro segundo gran avance, ya que quedó claro que teníamos un XSS en «ut2004stats.epicgames.com». Al ser un subdominio del dominio principal «epicgames.com», esto volvería a ser lo más importante para la última etapa de nuestro ataque.
oAuth toma de posesión de la cuenta
Durante los siguientes días buscamos con anhelo un posible punto de huelga.
Como sucedió, desde el principio de nuestra investigación, un miembro del equipo tuvo un fuerte sentimiento sobre el mecanismo de SSO. Sin ninguna suposición o teoría que descartar, echamos un vistazo más de cerca al SSO y, de hecho, encontramos que Epic Games había escrito una implementación genérica de SSO para apoyar a varios proveedores de inicio de sesión. Ya era hora de cavar dentro de esta implementación.
Resulta que cuando un jugador inicia sesión en su cuenta haciendo clic en el botón «Iniciar sesión», Epic Games genera una URL que contiene un parámetro «redirectedUrl» (como se ve a continuación en el texto en negrita). Este parámetro es utilizado más tarde por «accounts.epicgames.com» para redirigir al jugador a la página de su cuenta.
Figura 5: El enlace de redirección después de que un jugador inicia sesión en su cuenta.
Sin embargo, pronto descubrimos que era posible manipular la URL de redireccionamiento y dirigir al usuario a cualquier página web dentro del dominio «* .epicgames.com».
Con la capacidad de controlar el parámetro «redirctedUrl», podríamos redirigir a la víctima a «ut2004stats.epicgames.com», el sitio que contenía la carga útil de XSS:
La carga útil de JavaScript podría realizar una solicitud a cualquier proveedor de SSO. Una solicitud a los proveedores de SSO contiene un parámetro de «estado» que se usa más adelante en «accounts.epicgames.com» para completar el proceso de autenticación. La carga útil de JavaScript contiene un parámetro de «estado» creado. El valor del parámetro «estado» contenía un JSON codificado en Base64 y el JSON contenía tres claves, «redirectUrl», «client_id» y «prodectName». El parámetro «redirectedUrl» se usa para la redirección a medida que se completa el inicio de sesión de SSO.
Múltiples proveedores de SSO
Quienes intenten iniciar sesión en Fortnite notarán que Epic Games utiliza varios proveedores de SSO: PlayStationNetwork, Xbox Live, Nintendo, Facebook y Google+. Entonces comprendimos que el mismo proceso que describimos anteriormente también podría recrearse con cada uno de estos proveedores de SSO utilizando la misma técnica. Sin embargo, para el propósito de POC, utilizamos Facebook como proveedor de SSO.
Como puede ver, logramos crear el parámetro «estado» con una redirección a «ut2004stats.epicgames.com» con la carga útil de XSS:
https://www.facebook.com/dialog/oauth?client_id=1132078350149238&redirect_uri=https://accounts.epicgames.com/OAuthAuthorized&state=eyJpc1BvcHVwIjoidHJ1ZSIsImlzQ3JlYXRlRmxvdyI6InRydWUiLCJpc1dlYiI6InRydWUiLCJvYXV0aFJlZGlyZWN0VXJsIjoiaHR0cDovL3V0MjAwNHN0YXRzLmVwaWNnYW1lcy5jb20vaW5kZXgucGhwP3N0YXRzPW1hcHMmU2VhcmNoTmFtZT0lMjIlM2UlM2NzY3JpcHQlMjBzcmM9JyUyZiUyZmJpdC5seSUyZjJRbFNIQk8nJTNlJTNjJTJmc2NyaXB0JTNlJTJmIyUyZiJ9&response_type=code&display=popup&scope=email,public_profile,user_friends
Figura 6: una redirección a «ut2004stats.epicgames.com» con la carga útil XSS
El proveedor de SSO, en este caso Facebook, responde con una redirección a «accounts.epicgames.com» que contiene el parámetro de estado manipulado:
Figura 7: Respuesta de Facebook de una redirección a «accounts.epicgames.com» que contiene el parámetro de estado manipulado.
A su vez, Epic Games toma el «código» (es decir, el token de SSO) y los parámetros de «estado» creados por el atacante recibidos del proveedor de SSO y realiza una solicitud al servidor de Epic Games para finalizar el proceso de autenticación:
Figura 8: solicitud de Epic Games a su servidor, junto con los parámetros de «estado elaborado» del atacante recibidos del SSO.
En respuesta, el servidor de Epic Games genera una respuesta sin validación de entrada y redirige al usuario a «ut2004stats.epicgames.com» con la carga útil de XSS y el token de SSO:
Figura 9: la respuesta del servidor de Epic Games sin validación de entrada y redirige al usuario a «ut2004stats.epicgames.com» con la carga útil de XSS y el token de SSO.
Finalmente, el usuario es redirigido a la página web vulnerable donde se ejecuta la carga útil XSS y roba su código de autenticación:
Figura 10: La página web vulnerable donde se ejecuta la carga útil XSS.
El gran problema aquí (al menos para Epic Games) es que el servidor de Epic Games no realizó ninguna validación de entrada en el parámetro «estado».
Tenga en cuenta que estábamos redirigiendo a la página ‘ut2004stats.epicgames.com’ con la vulnerabilidad XSS. Entonces, aunque el mecanismo CORS fue implementado por Epic Games, ‘ut2004stats.epicgames.com’ aún podría realizar solicitudes a ‘account.epicgames.com’.
Omisión de la WAF
A medida que se ejecutaba la carga útil de XSS, la WAF entró en vigencia y nos dijo que la solicitud estaba prohibida. Aparentemente, el único problema era la longitud de la URL de origen del script, por lo que simplemente la omitimos utilizando una URL acortada.
Ahora que teníamos el XSS, podíamos cargar nuestro propio JavaScript que, a su vez, se ejecutaría en el contexto de «ut2004stats.epicgames.com».
Ya era hora de escribir algún código JavaScript:
Figura 11: El código JavaScript utilizado para entregar la carga útil XSS.
La carga útil de XSS
El código abre una ventana y realiza una solicitud de oAuth al servidor del proveedor de SSO (en nuestro caso, Facebook) con todas las cookies del usuario y el parámetro «estado» creado.
Luego, Facebook responde con una redirección a «account.epicgames.com» que contiene el token de SSO («código» parámetro) y el parámetro «estado» creado previamente que fue afectado por el atacante.
Como el usuario ya ha iniciado sesión con su cuenta de Facebook, el servidor «account.epicgames.com» realiza una redirección a la URL que se encuentra dentro del parámetro «estado» creado. En nuestro caso, la redirección va a «ut2004stats.epicgames.com» con la carga útil XSS y el token oAuth de usuario de Facebook.
Finalmente, el token se extrae de la solicitud y se envía al servidor de los atacantes (para fines de POC utilizamos el servidor “ngrok” – 0aa62240.ngrok.io ).
Figura 12: El servidor Ngrok recibe una solicitud con el token de SSO.
Figura 13: El servidor Ngrok recibe una solicitud con el token de SSO.
El atacante ahora tiene el token de Facebook de los usuarios y puede iniciar sesión en la cuenta de las víctimas:
Figura 14: el token de Facebook del usuario capturado por el atacante.
. Leer artículo completo en Frikipandi Tres vulnerabilidades de Fortnite. Check Point las ha explicado una vez resueltas..
