Amenazas en el mundo de los videojuegos

Desde hace ya varios años los videojuegos están generando más dinero que otras formas de entretenimiento audio visual más clásicas, como pueden ser el cine y la televisión. Cómo todo lo que mueve dinero en esta vida, los videojuegos también están en el punto de mira de mucha gente: desde jóvenes que quieren hacer de su hobby una carrera, hasta empresas que patrocinan eventos. Cómo no podía ser de otra forma en un negocio que está tan ligado a los ordenadores y a internet, también ha atraído las miradas de cibercriminales.

Las maneras en que estos cibercriminales actúan contra usuarios y plataformas son muy variadas. Antes de saltar a ver algunas de ellas, dejadme que intente explicaros cómo funciona el modelo de negocio.

Una de las razones por las que la industria del video juego lo está haciendo tan bien es porque han sabido evolucionar su modelo de negocio y adaptarse a los nuevos tiempos. Esta adaptación ha venido de la mano de la introducción del concepto social.

Algunos juegos siguen teniendo un modelo similar al clásico. El modelo clásico es el modelo en el que el consumidor compra un videojuego y ese video juego es el producto final. Un ejemplo de este tipo de juegos podría ser The secret of Monkey Island™, es un juego que te instalabas en el ordenador y no necesitabas nada más para jugar, es decir, era un juego autocontenido.
MI

Imagen de The Secret of Monkey Island.

Ese modelo ha evolucionado y ha ido introduciendo el concepto de social. No estoy hablando del concepto de multijugador, estoy hablando del concepto de social: plataformas como Steam o Battle.net, donde cualquiera puede ver tus logros en los juegos, rankings, skins que demuestran tu calidad y experiencia, etc.

Aparte de la evolución del modelo de negocio, otra razón por la que los videojuegos son tan rentables es porque la piratería no les ha afectado tanto como a otras industrias. Por un lado, piratear juegos de consolas no es tan fácil como descargarse una película de internet, además del juego, normalmente se necesita una modificación física del dispositivo. Para que os hagáis a la idea de lo complicado que puede ser la copia de juegos en consolas, el método de protección anti piratería de la Nintendo 64 se consiguió saltar en 2015, casi 20 años después de que la consola saliera al mercado.

Por otro lado, no se puede “piratear” un servicio, es decir, aunque seas capaz de evitar todas las protecciones anti copia del mundo, el servicio que ofrecen a día de hoy las plataformas de videojuegos hace que los jugadores quieran jugar en los servidores oficiales y así tener acceso a los servicios que estos ofrecen.
Ahora que entendemos a grandes rasgos el modelo de negocio, vamos a ver a qué amenazas se enfrentan estos servicios en el día a día.

Denegación de servicio

Como ya hemos dicho, las plataformas de videojuegos, como Steam o Battlenet, ofrecen un servicio como principal fuente de ingresos. El que este servicio esté caído, sobre todo en fechas claves, puede provocar pérdidas muy fuertes a estas plataformas.

No hay que remontarse muy atrás para encontrar un ataque de denegación de servicio contra Steam. El día de Navidad de 2015, Steam fue víctima de un ataque de denegación de servicio por parte del grupo Phantom Squad. Este ataque no fue sólo una denegación de servicio típica, si no que a la vez que la denegación de servicio ocurría, los usuarios que podían conectar y acceder a su cuenta aterrizaban en cuentas que no eran la suya, accediendo así a información personal de otros usuarios.

Esto forzó a Steam a desconectar todo su servicio y a realizar una actualización de emergencia para solucionar el problema de privacidad, ocasionando no sólo una pérdida económica, sino que también una pérdida de imagen.

En las mismas fechas pero un año antes, el grupo Lizard Squad atacó los sistemas on-line de Microsoft y Sony, dejando así también a miles de usuarios sin poder acceder a sus servicios.

Ransomware

En una época en la que todas las semanas se escucha en la oficina que el cliente X o el cliente Y se ha vuelto a infectar con ransomware, no debería sorprendernos que algunas familias de ransomware, además de cifrar documentos ofimáticos, buscan extensiones relacionadas con los video juegos.

Un ejemplo de ransomware haciendo objetivo a extensiones relacionadas con los videojuegos es TeslaCrypt. Entre los ficheros que cifra se encuentran datos de perfil, partidas guardadas, mods y mapas.

Datos personales de usuarios

Las plataformas sociales de video juegos contienen los datos personales de sus usuarios. No sólo eso, si no que muchas además tienen una plataforma de pagos, por lo que, además de los datos personales de los usuarios, se pueden encontrar datos de carácter financiero.

Algunos ejemplos de este tipo de ataques pasan por SEGA en 2011 o el famoso caso del ataque de LulzSec a SONY.

Grupos APT

En cuanto a APTs, se han identificado al menos dos grupos que están, o han estado, haciendo objetivo a la industria del video juego TG-3279 y Winnti. Aunque se conoce que de alguna manera estos dos grupos están ligados, no se ha podido confirmar si alguno de ellos es un subgrupo que forma parte del otro.

Los objetivos de estos grupos se han centrado hasta ahora en el robo de certificados, propiedad intelectual y, por supuesto código fuente.

Trampas

Además de eso, las empresas de video juegos tienen que lidiar con tramposos. Aunque a veces las trampas vienen acompañadas de unos hacks muy ingeniosos, una gran proporción de tramposos puede hacer que los jugadores dejen de jugar ya que las posibilidades de ganar contra ciertas trampas son escasas. Estos cheats se pueden adquirir on-line, pero si quieres hacértelos tú, no necesitas más que seguir los tutoriales que se encuentran en internet.

Ante esto las compañías tienen tanto sistemas de detección de trampas, que detectan trampas conocidas, como programas de «reporte», que permiten a los usuarios denunciar a usuarios sospechosos de hacer trampas.

Tramposo en acción.

No son todos los problemas a los que esta industria se enfrenta, pero sirve para hacerse a la idea del calibre que tiene el mundo de los videojuegos.

Espero que os haya gustado y por favor, no dudéis en dejar en los comentarios información sobre ataques contra estas plataformas o, simplemente, trucos que os hayan marcado, ya sea por divertidos, elegantes o por eficaces.

SmartHive - Plataforma de despliegue ágil de honeypots

Despliegue de honeypots de forma ágil y económica con SmartHive

SmartHive se trata de un proyecto cuyo principal objetivo es simplificar la creación de redes de honeypots a bajo coste, mediante una plataforma que permite la gestión, explotación y despliegue ágil de honeypots en Internet.

Leer más

Evitando HSTS, ¿una cuestión de tiempo?

Como vimos en el artículo anterior http://securityinside.info/hsts-una-defensa-mitm-sslstrip/ , HSTS fue creado para que los navegadores rechazasen conexiones HTTP a ciertos lugares y, de este modo evitar ataques de interceptación tipo mitm o sslstrip. Para ello, se introduce la nueva cabecera Strict-Transport-Security en el protocolo HTTP, que establece unos parámetros para indicar al navegador una política de como manejar las conexiones SSL para un sitio web en concreto. Los navegadores que implementan HSTS mantienen además una lista «precargada» de dominios  con lo cual se  evitaría el posible ataque al visitar por primera vez que se visita un sitio y no conocer que implementa HSTS. El ataque en esas circunstancias de primera visita, de no existir las listas precargadas podría ser efectivo. Es lo que se denomina ataque bootstrap.  

Más información sobre las listas precargadas puede encontrarse en el sitio web del proyecto Chromium, uno de los precursores principales de las listas precargadas HSTS.

Ataques a HSTS

A pesar de las listas precargadas, aún existen algunas oportunidades para esquivar este mecanismo de protección, entre ellos:

  • Ataques DNS. Mediante la manipulación de las resoluciones DNS de la víctima podemos evitar que el dominio a atacar sea encontrado en las políticas HSTS manipulando la respuesta DNS que recibe la víctima. Así, y mediante un ataque mitm e interceptando las resoluciones de nombre,  se obligaría a la víctima a conectarse, por ejemplo a «cuentas.google.com» cuando se pretendía conectar a «accounts.google.com» . La manipulación de la resolución DNS engañaría al navegador al no encontrar ese nombre entre sus registros HSTS. Esta aproximación ha sido implementada y presentada en la Blackhat Asia 2014 por Leonardo NVE
  • Ataques basados en tiempo. Esta estrategia consiste en conseguir que la política HSTS caduque con lo cual el navegador, hasta que no renueve recibiendo el parámetro «max-age» visitando de nuevo el sitio, ignorará la obligación de establecer conexión HTTPS. Este el el tipo de ataque es el que vamos a describir aquí, y que fue demostrado por  José Selvi presentando en la BlackHat Europa 2014 su estudio y la correspondiente demostración.

HSTS, listas precargadas y registros dinámicos

Como hemos dicho, si conseguimos de algún modo hacer caducar los registros HSTS que mantiene el navegador, éste ignorará la política correspondiente y no forzará la conexión HTTPS hasta haber actualizado la política. Como podemos ver en las listas precargadas antes referidas, son multitud de sitios los que ya se encuentran enumerados. Observando las cabeceras en una solicitud HTTP podemos encontrar en la respuesta del servidor si éste incorpora HSTS:

 

Cabeceras HSTS

Cabeceras HSTS

En la siguiente imagen observamos como por ejemplo el sitio www.icloud.com no muestra el parámetro «preload» , cosa que sí aparece en facebook.com. De esta sencilla consulta podemos inferir que, presumiblemente www.icloud.com no se encuentra entre los registros precargados del navegador, y por tanto sería vulnerable en una primera visita a un ataque bootsrap.

Efectivamente, comprobamos en el navegador (chrome) que no existe el registro:

icloud hsts

No existe el registro HSTS de www.icloud.com precargado

 

Sin embargo tras visitar https://www.icloud.com:

Registro HSTS de www.icloud.com tras visitar el sitio

Registro HSTS de www.icloud.com tras visitar el sitio

Con estos ejemplos comprobamos que cualquier sitio que incorpore HSTS y que no esté precargado se registrará al visitar por primera vez el sitio HTTPS correspondiente, y quedará dinámicamente almacenado en las políticas del navegador hasta que expire (max-age) o sea eliminado. Las entradas precargadas no se pueden eliminar manualmente

NOTA: El modo en que se administran los registros HSTS depende en última instancia de la implementación propia del navegador en sí, con lo que este comportamiento puede variar entre los distintos navegadores existentes y debe ser comprobado en cada caso.

Hasta ahora mucha teoría, pero… ¿como podemos burlar hsts?

Regreso al futuro, engañando HSTS con ataques NTP

Como se menciona al comienzo del artículo, uno de los posibles métodos para evitar la protección HSTS pasa por hacer creer al navegador que la política ha caducado y de ese modo la ignore. Para ello, y dado que el navegador comprueba el tiempo basándose en la máquina donde corre, si conseguimos modificar el reloj de la máquina víctima a través de un ataque de red, estaremos en condiciones de burlar al navegador (o al menos, intentarlo) y evitar que fuerce una conexión HTTPS. A partir de ese momento, un ataque mitm con sslstrip sería efectivo.

NTP spoofing: Delorean, y directos al futuro

En la pasada BlackHat, el conocido investigador José Selvi (http://www.pentester.es) presentó una herramienta escrita en python como prueba de concepto para sortear HSTS. La herramienta se llama Delorean y hace las veces de servidor NTP el cual podemos configurar para mantenerse a la escucha de solicitudes ntp y responder con los parámetros deseados, en este caso llevar hacia adelante el reloj de la víctima.

Utilizando Delorean, iptables, sslstrip y mitm es posible llevar a cabo un ataque man in the middle y conseguir interceptar el  tráfico HTTPS a pesar de HSTS.

En el siguiente vídeo realizamos una demostración:

Conclusión

A pesar de que en los últimos años se ha avanzado mucho en la seguridad de las comunicaciones, son tan numerosas las variables que intervienen en las mismas, que hacen muy difícil definir un protocolo de comunicación que sea estándar e integrable y que a su vez proporcione una seguridad inquebrantable. HSTS en sí mismo es una muy buena protección pero como hemos visto, factores externos (en este caso un ataque NTP) abren una brecha en su diseño. De la misma forma, este mismo ataque que hemos demostrado aquí, con Ubuntu y Firefox puede no resultar efectivo en otro entorno,  dependiendo del sistema operativo, del mecanismo de sincronización, del sitio a atacar, del navegador, etc. Sin embargo, la posiblidad ahí está.

 

HSTS, una defensa contra MITM y sslstrip

Siempre escuchamos que debemos, al menos,  asegurarnos que nuestra navegación viaja sobre HTTPs cuando debemos introducir contraseñas y/o acceder a sitos de información confidencial. Pero…¿Es HTTPs una garantía absoluta de que nuestras comunicaciones son realmente seguras?. En las tecnologías de la información nunca podremos hablar de un 100% de seguridad, y siempre debemos estar atentos a multiples circunstancias que pudieran ser aprovechadas para vulnerar nuestras comunicaciones. En este artículo introducimos un ataque clásico y eficaz contra conexiones seguras (sslstrip) y un mecanismo relativamente reciente que lo mitiga (hsts). ¿Puede considerarse HSTS el final de SSLStrip? Veamos.

Ataques Man in the Middle y SSLStrip

El ataque de hombre en el medio o MITM (del inglés Man in the Middle) es una de las técnicas mas frecuentemente utilizadas por su implementación, relativamente sencilla, y por la eficacia de sus resultados. No obstante el uso de SSL/TLS y el uso de criptografía  en las comunicaciones ha puesto siempre en jaque este tipo de interceptación de tráfico. Ante esta dificultad los ataques han tratado de sacar partido de debilidades en las suites de cifrado negociadas en una conexión segura, como BEAST, CRIME o BREACH o en vulnerabilidades SSL como Heartbleed. Actualizaciones, parches y otros condicionantes hacen que estas circunstancias no sean, en general, sencillas de explotar.

Otra técnica muy conocida y utilizada ampliamente durante un buen periodo de tiempo es SSLStrip. SSLstrip fue presentado por Moxie Marlinspike en la Black Hat 2009, y demostraba una genial idea para interceptar conexiones HTTPS  donde, en lugar de atacar el cifrado entre el cliente y el servidor se engaña al cliente, interponiéndose en mitad de la conexión. De este modo, SSLStrip hace de pasarela, intercepta el tráfico HTTP, evita que llegue un mensaje de redirección a HTTPS por parte del servidor y a continuación establece y mantiene dos conexiones: una HTTP sin cifrar con el cliente (víctima) y otra con el servidor HTTPS, manejando las cookies y la sesión para hacer creer a la víctima que está bajo una conexión segura cuando en realidad todo el tráfico va sin cifrar.

Durante un buen periodo de tiempo esta técnica dio excelentes frutos puesto que, para el servidor todo era correcto (conexion segura) y para también para el cliente, el cual no es consciente de que la conexión no es cifrada. Algunas contramedidas contra este ataque pasaban por utilizar plugins de navegador para forzar HTTPS hasta que apareció una mejora en el protocolo denominada HSTS.

HSTS: HTTP Strict Transport Security

HSTS, acrónimo para HTTP Strict Transport Security, nace con el objetivo de evitar  ataques de interceptación en conexiones HTTPS. La idea principal es introducir una nueva cabecera HTTP denominada Strict-Transport-Security, la cual puede ser enviada por un servidor al navegador cliente para fijar una política que obligue a usar únicamente conexiones seguras SSL/TLS y de como manejar las mismas con el servidor. En una política HSTS hay dos parámetros principales:

  • max-age, seguida de un número que representa el tiempo en segundos en que un navegador debe utilizar siempre HTTPS para la conexión con el dominio concreto incluso si se escribe específicamente «http://» en el barra de direcciones. Pasado ese tiempo el navegador recupera el comportamiento habitual.
  • IncludeSubdomains es otro parámetro opcional, que indicaría además al cliente que todo subdominio debe ser accedido igualmente estrictamente bajo HTTPS. Esta opción ha de ser utilizada con cuidado para evitar dejar fuera de contexto posibles alias o hospedajes bajo un CDN.

Un ejemplo de la cabecera de respuesta HSTS de conexión  con un servidor web puede ser  el siguiente:

Strict-Transport-Security: max-age=31556926; includeSubDomains

Este campo de la cabecera establece que ,durante un año (max-age=31556926) tanto el dominio solicitado como todos sus subdominios (includeSubDomains) han de ser accedidos únicamente utilizando HTTPs.

Adicionalmente, una política HSTS también previene que un usuario pueda aceptar un certificado autofirmado o cualquier irregularidad al registrarse y recordarse la CA que firma un dominio ya visitado.

Un aspecto importante a tener en cuenta es, que cuando se visita por primera vez un servidor con HSTS se recibirán la cabecera Strict-Transport-Security y los parámetros fijados, momento desde el cual  el navegador reconocerá el sitio y aplicará la política HSTS hasta su expiración. Esta primera visita es un punto vulnerable puesto que aún el navegador no tiene información sobre el sitio en concreto. Lo mismo ocurre cuando la política caduca.

De este modo al igual que hace SSLStrip con el manejo de una  sesión HTTPs, en un ataque man in the middle se podrían eliminar las cabeceras HSTS en la primera visita (vulnerabilidad Bootstrap man in the middle)  y así de este modo evitar que el navegador reciba esta notificación y aplique una política estricta. Sin embargo del mismo modo que en la parte servidora, también es posible  establecer en el navegador (parte cliente) «listas precargadas» de dominios, a los que se aplicará una política estricta independientemente de que sea la primera vez que se visita el sitio HTTPS. Este mecanismo evitaría el Bootstrap man in the middle. En algunos navegadores se pueden consultar y/o añadir elementos de estas listas, por ejemplo en Chrome accediendo a la URI: chrome://net-internals/#hsts

 

hsts

– HSTS: Configuración de listas precargadas en Chrome –

 Consideraciones de seguridad en HSTS

Entonces…. ¿podemos considerar HTTP Strict Transport Security el mecanismo que acaba definitivamente con los ataques SSLStrip y similares?. No, y tal y como se describe en el propio RFC de HSTS existen diversos vectores de ataque entre ellos ataques basados en NTP o DNS poisoning y que convenientemente explotados pueden servir para evitar la protección ofrecida por HSTS.

En un próximo artículo echaremos un vistazo a algunas aproximaciones que hacen uso de esos vectores como por ejemplo, SSLStrip+ o Delorean.