En el año 2014, el hacker Frans Rosén daba a luz a esta genialidad llamada Subdomain Takeover. El descubrimiento de este yacimiento me pilló en mis años universitarios y recuerdo que entonces fue una auténtica convulsión en la industria. Por lo sencillo de ejecutar y por lo peligroso que se puede convertir para realizar ataques al dominio original o a los que confían en él.
Recientemente he encontrado un pequeño archivo donde guardaba mis trofeos, y me ha dado por ver si esta vulnerabilidad había desaparecido. Para mi sorpresa he encontrado que, a pesar de que muchos proveedores han arreglado esta brecha, son muchos los que todavía son vulnerables:
Back to basics: Subdomain Takeover Attacks
En pocas palabras, un Subdomain Takeover consiste básicamente en reclamar un subdominio “muerto” y, de esta manera, conseguir acceso a modificar un dominio verificado del tipo “malicioso.dominio.com”, crear un correo electrónico de “dominio.com” y, a partir de este punto, todas las fechorías que se te ocurran. Extremadamente sencillo de conseguir, extremadamente peligroso, pura dinamita en un mundo donde el e-mail sigue siendo el principal vector de entrada en las organizaciones.
Esto sucede cuando un subdominio registrado en un proveedor cualquiera caduca, y el registro CNAME se queda apuntando al aire. En este momento, si alguien se registra en el proveedor y reclama este registro, se hará con el subdominio. Lo que va a permitir realizar Hacking Web Technologies de tipo Watering Hole para distribuir malware o hacer ataques de Phishing utilizando ese subdominio para generar direcciones de correo electrónico del dominio original y portales para robar credenciales convincentes.
En el año 2014, la mayor parte de los proveedores web (AWS, Fastly, Heroku, Azure, GitHub, etcétera) eran vulnerables. A día de hoy muchos de estos proveedores ya han parcheado esta falta de verificación, pero no todos. Si quieres ver el listado actualizado en tiempo real, está en este repositorio:
Buscando este tipo de vulnerabilidades me he encontrado con una variante que tiene cierta gracia. En ocasiones cuando el subdominio expira y la dirección IP que se queda suelta uno de estos proveedores la puede reutilizar. Esto hace que nos encontremos con situaciones divertidas, como un dominio “subdominio.blanco.com” apuntando a “negro.com”. Algo que para las aplicaciones web de las empresas es extremadamente peligroso, ya que este nuevo dominio podría tener un contenido que, de hacerse público, podría perjudicar su reputación.
En mi experiencia, el tres de cada cuatro veces que nos encontramos con esta vulnerabilidad se ha producido y se produce de la siguiente manera:
Subdomain Taceover: Un proceso personal
Al igual que en la "Fiebre del Oro", con los buscadores llegaron las herramientas para explotar este tipo de nuevas fallas que pueden ser explotadas en campañas maliciosas o simplemente en proyectos de Ethical Hacking o ejercicios de Red Team.
Actualmente es abrumadora la cantidad de herramientas que esta maravillosa comunidad genera y comparte para encontrar estas pepitas. Yo os hoy voy a explicar el proceso en este artículo utilizando las que creo que mejores resultados me dan.
1. Enumeración
El primer paso es definir cuál es nuestro objetivo e intentar listar la mayor cantidad de subdominios posibles. Esta fase es de vital importancia en el proceso, y quien sepa diferenciarse aquí, contará con una gran ventaja. Existen cientos de enumeradores de subdominios, pero para mi hay tres claros ganadores: OWASP Amass, Anubis y Sublist3r
En mi caso, yo hago pasar el dominio por estos tres frameworks y después, junto los tres resultados de búsqueda en un solo fichero txt. Os impresionará descubrir la ingente cantidad de subdominios que, hasta la más pequeñas de las webs, tienen. Pero si no has encontrado, puedes seguir utilizando otras herramientas o procesos.
Como os podéis imaginar, este es un proceso en el que se pueden utilizar todas las técnicas de hacking con buscadores para hacer procesos de footprinting usando desde el webscrapping, hasta los índices secundarios de los buscadores, hasta fugas de datos en metadatos usando la FOCA con los módulos de enumeración de DNS y subdominios. Cuanto más perseveres en esta fase, más fácil es que encuentres una "pepita de oro" en tu tamiz.
2. Limpieza
Una vez tenemos este fichero TXT con todos los subdominios localizados, verificaremos qué webs existen y cuáles no, ya que estos motores de búsqueda en ocasiones utilizan permutadores de palabras para descubrir posibles dominios en ataques de fuerza bruta o diccionario. Para este proceso, yo os recomiendo MassDNS.
Esta espectacular herramienta chequea miles de dominios en segundos y te devuelve la respuesta encontrada para cada uno de ellos. A muchos hackers les gusta eliminar en esta fase todo aquello que no sea un Error 404, a mí me gusta mantener todo por la variante que he explicado antes.
3. Búsqueda del subdominio objetivo
Básicamente aquí tienes dos caminos. Revisar las respuestas que ha devuelto Massdns y buscar por títulos atípicos, o mi preferida: Usar EyeWitness.
Esta herramienta hace una captura de pantalla "screenshot" de todas las páginas web que hemos incluido en el ámbito de prueba (Scope) y genera un informe en formato HTML categorizado por tipo de respuesta. De un vistazo ves todos los resultados.
4. Explotación del Subdomain Takeover
Una vez hemos identificado en la fases de footprinting y fingerprinting que hemos realizado en los puntos anteriores la existencia de una vulnerabilidad en un subdominio en el proveedor de turno, simplemente faltaría registrarse, crear un registro CNAME y apuntarlo a nuestra propia web. Si estás en un proceso de Red Team, este es justo uno de los rincones que normalmente se escapan a los equipos de IT.
Las posibilidades de hacer maldades una vez tenemos el dominio son infinitas. Como os he dicho basta con ver que el proveedor está en la lista de proveedores vulnerables a Subdomain Takeover.
5. Automatización
Como los entornos web son seres vivos, es interesante monitorizar los subdominios de manera que cuando uno se caduque podamos ser los primeros en reclamarlo. Algunos hackers automatizan todo el proceso cuyo resultado termina en el informe de EyeWitness de manera que siempre tienen una versión actualizada de sus dominios. Esto es relativamente sencillo hacerlo con AWS y Slaac.
Otra opción es utilizar la herramienta de supervisión de Certificate Transparency para Desarrolladores en Facebook que permite utilizar la red social. Esta herramienta permite monitorizar estos certificados directamente en tu correo electrónico: “The quieter you become, the more you are able to hear”
La industria de la ciberseguridad tiene la gran virtud o inconveniente, según se quiera ver, de que el gran público tiene acceso a potentísimas herramientas a golpe de clic, y por mucho que ciertos proveedores hayan arreglado esta vulnerabilidad, a alguien se le volverá a ocurrir una manera como ésta de colarse en la cocina. El "Subdomain Takeover" no está muerto, ni mucho menos.
Keep looking!
Autor: Pablo García Pérez
Figura 1: Subdomain Takeover: Empresas en riesgo por subdominios olvidados |
Recientemente he encontrado un pequeño archivo donde guardaba mis trofeos, y me ha dado por ver si esta vulnerabilidad había desaparecido. Para mi sorpresa he encontrado que, a pesar de que muchos proveedores han arreglado esta brecha, son muchos los que todavía son vulnerables:
Back to basics: Subdomain Takeover Attacks
En pocas palabras, un Subdomain Takeover consiste básicamente en reclamar un subdominio “muerto” y, de esta manera, conseguir acceso a modificar un dominio verificado del tipo “malicioso.dominio.com”, crear un correo electrónico de “dominio.com” y, a partir de este punto, todas las fechorías que se te ocurran. Extremadamente sencillo de conseguir, extremadamente peligroso, pura dinamita en un mundo donde el e-mail sigue siendo el principal vector de entrada en las organizaciones.
Figura 2: Estadísticas anuales de sitios afectados por Subdomain Takeover |
Esto sucede cuando un subdominio registrado en un proveedor cualquiera caduca, y el registro CNAME se queda apuntando al aire. En este momento, si alguien se registra en el proveedor y reclama este registro, se hará con el subdominio. Lo que va a permitir realizar Hacking Web Technologies de tipo Watering Hole para distribuir malware o hacer ataques de Phishing utilizando ese subdominio para generar direcciones de correo electrónico del dominio original y portales para robar credenciales convincentes.
Figura 3: Hacking Web Technologies |
En el año 2014, la mayor parte de los proveedores web (AWS, Fastly, Heroku, Azure, GitHub, etcétera) eran vulnerables. A día de hoy muchos de estos proveedores ya han parcheado esta falta de verificación, pero no todos. Si quieres ver el listado actualizado en tiempo real, está en este repositorio:
Figura 4: Listado de proveedores afectados por Subdomain Takeover |
Buscando este tipo de vulnerabilidades me he encontrado con una variante que tiene cierta gracia. En ocasiones cuando el subdominio expira y la dirección IP que se queda suelta uno de estos proveedores la puede reutilizar. Esto hace que nos encontremos con situaciones divertidas, como un dominio “subdominio.blanco.com” apuntando a “negro.com”. Algo que para las aplicaciones web de las empresas es extremadamente peligroso, ya que este nuevo dominio podría tener un contenido que, de hacerse público, podría perjudicar su reputación.
En mi experiencia, el tres de cada cuatro veces que nos encontramos con esta vulnerabilidad se ha producido y se produce de la siguiente manera:
- Equipo de marketing pide a IT una web para un sorteo, campaña o promoción.
- Equipo de IT crea una web temporal en con un proveedor para no agrandar la infraestructura innecesariamente.
- Se acaba el ciclo de vida útil de esa web, pero no se apaga.
- Pasan 5, 10, 15 o 20 años
- El subdominio ha expirado en el proveedor y un atacante lo atrapa.
- El atacante podría generar una web falsa, mandar mensajes de e-mail, ejecutar código contra el servidor, etcétera.Como podéis ver, se trata de un problema que, comienza por pensar que no toda la infraestructura es igual de importante y se agrava por no tener una fecha de caducidad y apagado de los servicios. Algo fundamental en el ciclo de vida del software.
Subdomain Taceover: Un proceso personal
Al igual que en la "Fiebre del Oro", con los buscadores llegaron las herramientas para explotar este tipo de nuevas fallas que pueden ser explotadas en campañas maliciosas o simplemente en proyectos de Ethical Hacking o ejercicios de Red Team.
Figura 5: Manual de Ethical Hacking en 0xWord |
Actualmente es abrumadora la cantidad de herramientas que esta maravillosa comunidad genera y comparte para encontrar estas pepitas. Yo os hoy voy a explicar el proceso en este artículo utilizando las que creo que mejores resultados me dan.
1. Enumeración
El primer paso es definir cuál es nuestro objetivo e intentar listar la mayor cantidad de subdominios posibles. Esta fase es de vital importancia en el proceso, y quien sepa diferenciarse aquí, contará con una gran ventaja. Existen cientos de enumeradores de subdominios, pero para mi hay tres claros ganadores: OWASP Amass, Anubis y Sublist3r
Figura 6: OWASP Amass |
En mi caso, yo hago pasar el dominio por estos tres frameworks y después, junto los tres resultados de búsqueda en un solo fichero txt. Os impresionará descubrir la ingente cantidad de subdominios que, hasta la más pequeñas de las webs, tienen. Pero si no has encontrado, puedes seguir utilizando otras herramientas o procesos.
Figura 7: FOCA tiene módulos de descubrimiento de subdominios desde el principio |
Como os podéis imaginar, este es un proceso en el que se pueden utilizar todas las técnicas de hacking con buscadores para hacer procesos de footprinting usando desde el webscrapping, hasta los índices secundarios de los buscadores, hasta fugas de datos en metadatos usando la FOCA con los módulos de enumeración de DNS y subdominios. Cuanto más perseveres en esta fase, más fácil es que encuentres una "pepita de oro" en tu tamiz.
2. Limpieza
Una vez tenemos este fichero TXT con todos los subdominios localizados, verificaremos qué webs existen y cuáles no, ya que estos motores de búsqueda en ocasiones utilizan permutadores de palabras para descubrir posibles dominios en ataques de fuerza bruta o diccionario. Para este proceso, yo os recomiendo MassDNS.
Figura 8: MassDNS |
Esta espectacular herramienta chequea miles de dominios en segundos y te devuelve la respuesta encontrada para cada uno de ellos. A muchos hackers les gusta eliminar en esta fase todo aquello que no sea un Error 404, a mí me gusta mantener todo por la variante que he explicado antes.
3. Búsqueda del subdominio objetivo
Básicamente aquí tienes dos caminos. Revisar las respuestas que ha devuelto Massdns y buscar por títulos atípicos, o mi preferida: Usar EyeWitness.
Figura 9: EyeWitness |
Esta herramienta hace una captura de pantalla "screenshot" de todas las páginas web que hemos incluido en el ámbito de prueba (Scope) y genera un informe en formato HTML categorizado por tipo de respuesta. De un vistazo ves todos los resultados.
4. Explotación del Subdomain Takeover
Una vez hemos identificado en la fases de footprinting y fingerprinting que hemos realizado en los puntos anteriores la existencia de una vulnerabilidad en un subdominio en el proveedor de turno, simplemente faltaría registrarse, crear un registro CNAME y apuntarlo a nuestra propia web. Si estás en un proceso de Red Team, este es justo uno de los rincones que normalmente se escapan a los equipos de IT.
Figura 10: El Red Team en la empresa |
Las posibilidades de hacer maldades una vez tenemos el dominio son infinitas. Como os he dicho basta con ver que el proveedor está en la lista de proveedores vulnerables a Subdomain Takeover.
5. Automatización
Como los entornos web son seres vivos, es interesante monitorizar los subdominios de manera que cuando uno se caduque podamos ser los primeros en reclamarlo. Algunos hackers automatizan todo el proceso cuyo resultado termina en el informe de EyeWitness de manera que siempre tienen una versión actualizada de sus dominios. Esto es relativamente sencillo hacerlo con AWS y Slaac.
Figura 11: Supervisión de transparencia de certificados para desarrolladores en Facebook |
Otra opción es utilizar la herramienta de supervisión de Certificate Transparency para Desarrolladores en Facebook que permite utilizar la red social. Esta herramienta permite monitorizar estos certificados directamente en tu correo electrónico: “The quieter you become, the more you are able to hear”
Figura 12: Monitorización en e-mail |
La industria de la ciberseguridad tiene la gran virtud o inconveniente, según se quiera ver, de que el gran público tiene acceso a potentísimas herramientas a golpe de clic, y por mucho que ciertos proveedores hayan arreglado esta vulnerabilidad, a alguien se le volverá a ocurrir una manera como ésta de colarse en la cocina. El "Subdomain Takeover" no está muerto, ni mucho menos.
Keep looking!
Autor: Pablo García Pérez
Contactar con Pablo García |
Hola, buen artículo. Respecto a los enumeradores de subdominios, deberías echarle un vistazo a https://github.com/edu4rdshl/findomain ;)
ResponderEliminarHola, buen artículo.
ResponderEliminarRespecto a los enumeradores, deberías probar https://github.com/edu4rdshl/findomain.😉 Un abrazo.