Dos empresas de seguridad demuestran gráficamente el peligro del secuestro de subdominios.
Las empresas de seguridad israelíes Check Point y CyberInt colaboraron esta semana para encontrar, explotar y demostrar un fallo de seguridad que permite a los atacantes secuestrar cuentas de jugadores en los juegos en línea de EA/Origin.
El exploit encadena varios tipos clásicos de ataques (phishing, secuestro de sesión y secuencias de comandos entre sitios), pero el defecto clave que hace que todo el ataque funcione es el mal mantenimiento de los DNS.
La mayoría de los videos hablan por sí mismos. El atacante engaña a una víctima a través de WhatsApp para que haga clic en un enlace poco fiable, la víctima hace clic y se apropia de él, y las credenciales robadas se utilizan para causar estragos en la cuenta de la víctima.
Lo que hace que este ataque sea diferente -y considerablemente más peligroso- es la posesión por parte del atacante de un sitio alojado en un subdominio válido y operativo de ea.com.
Sin un subdominio real en su posesión, el ataque habría requerido que la víctima iniciara sesión en un portal falso de EA para permitir que el atacante obtuviera una contraseña. Esto habría incrementado enormemente la probabilidad de que la víctima estuviera alerta a una estafa. Con el subdominio, el atacante pudo recoger el token de autenticación de una sesión de EA activa existente antes de explotarlo directamente y en tiempo real.
Cuando hablaron con Alex Peleg de CyberInt y Oded Vanunu de Check Point por teléfono comentaron en una entrevista:
¿Tomasteis el control de ese subdominio de EA en primer lugar?
Según los dos investigadores, es un error bastante común. Una gran empresa inicia una nueva campaña de marketing, crea un equipo de desarrollo para hacer el trabajo de programación necesario y le da al equipo un nuevo subdominio -como eaplayinvite.ea.com- para ejecutar la campaña.
El equipo de desarrollo acelera las nuevas instancias en AWS, Google Cloud o un proveedor similar, y luego utiliza un registro CNAME para conectar el subdominio de la empresa a un registro «Tipo A» interno del proveedor en el host. Cuando la campaña de marketing termina, el AWS u otra instancia de nube se cierra… pero nadie le dice al equipo que gestiona el dominio principal de la empresa que se deshaga del registro CNAME. Ahí es donde las cosas se tuercen.
Un atacante interesado en la compañía puede ver si ha lanzado un nuevo subdominio y luego utilizar la herramienta «dig» para ver cómo está alojada.
Si el atacante ve que la empresa ha utilizado un registro CNAME para redirigir a los DNS internos de un proveedor de Cloud Computing, el siguiente paso es esperar a que la campaña de marketing se complete y que las URLs involucradas en la campaña dejen de funcionar. Ahora escarbamos el nombre del subdominio de nuevo: si el CNAME original está intacto, estamos en el negocio. A continuación, el atacante utiliza una cuenta propia en el mismo proveedor de cloud computing y solicita el mismo nombre de DNS interno del proveedor utilizado originalmente por la campaña.
En este punto, el CNAME original apunta ahora al sitio web del atacante, no al sitio web controlado por la propia empresa. Armado con un subdominio de trabajo del dominio real de la empresa, las cookies que pertenecen a los usuarios de la empresa pueden ser capturadas (¡e incrustadas!). Esto hace posible ataques instantáneos contra las víctimas que utilizan los servicios de esa compañía.
En este caso, Alex y Oded abrieron con un ataque de phishing sobre WhatsApp, pero un atacante más atrevido podría haber comenzado con un ataque de Watering hole attack.
Imaginemos que un atacante serio hubiera comprado anuncios habilitados para HTML en una granja de banners, dirigidos específicamente a jugadores de EA: su anuncio podría abrir un iframe invisible a su subdominio secuestrado. Tal iframe podría recoger automáticamente cualquier token de autenticación de los jugadores conectados sin necesidad de interacción alguna por parte de los usuarios.
Un sinfín de posibilidades
Según Alex y Oded, el descuido hecho aquí por EA/Origin es deprimentemente común en las grandes compañías. Los equipos de desarrollo no hablan con los equipos de administración, ninguno de ellos habla con los equipos de operaciones más tradicionales que gestionan los servicios básicos como el DNS de toda la empresa, entonces es cuando se cometen errores. Los investigadores -y sus empresas- esperan que tras demostraciones públicas como ésta despierten a las grandes empresas, rompan los filtros y, en última instancia, hagan que las cuentas de los usuarios finales sean menos vulnerables a la piratería informática.
