itrox.siteGithub

Subdomain Takeover

I. Descripción

Vulnerabilidad que permite a un atacante secuestrar el subdominio de un activo que apunta a un servicio externo como AWS, del cual su configuración ya no existe. Esto se plantea a nivel de registros DNS del subdominio debido a que estos aún se encuentran activos, pero el servicio al que apuntan ha sido eliminado o desactivado

Ejemplo:

  • subdomain.domain.tld apunta a app.aws.com

  • Los recursos de aws (app) han sido eliminado

  • El subdominio aún apunta a app.aws.com, pero como la app no existe, un atacante puede crear un nuevo recurso en dns-aws con ese nombre y tomar control del subdominio

II. PoC

  1. Enumerar subdominios de un dominio

  2. Ejecutar subzy sobre fichero de subdominios para tener una primera visualización de posibles subdominios vulnerables (se recomienda igualmente corroborar de forma manual) y filtrar salida con string vulnerable

# Esta es una forma de guardar salida de subzy y filtrar por string vulnerable
subzy run --targets subdomains.txt --hide_fails --verify_ssl --output subdomain-takeover.txt
echo "[" > subdomain-takeover.json && awk '/{/{block=""} {block=block $0 "\n"} /}/{if (block ~ /"status": "vulnerable"/) print block","}' subdomain-takeover.txt | sed '$s/,$//' >> subdomain-takeover.json && echo "]" >> subdomain-takeover.json

# Esta es otra forma
subzy run --targets subdomains.txt --hide_fails --verify_ssl | tee sub-takeover.txt
cat sub-takeover.txt | sed -n '/\[ VULNERABLE \]/p'

  1. Analizar listado de subdominios con Nuclei para fortalecer posibles indicios de activos vulnerables con template de takeovers

nuclei -l subdomains.txt -t $HOME/nuclei-templates/http/takeovers/

  1. Verificar registros DNS (CNAME o NS) de un subdominio marcado como posible vulnerable (igual se recomienda verificar manualmente este paso para todos los subdominios mediante bucle while

# Ejecución individual sobre subdominios
dig CNAME subdomain.domain.tld

# Bucle while de ejecución automática
while read subdomain; do echo "$subdomain:"; dig $subdomain CNAME; echo "################################"; done < subdominios.txt

  1. Analizar respuestas y verificar recursos diferentes entre subdominio y registro

subdomain.domain.tld 3600 IN CNAME app.aws.com.

  • Si app.aws.com no responde como sitio o muestra uno de los siguientes mensajes de error al acceder, se puede considerar potencialmente como vulnerable

curl -s -i -L http://subdomain.domain.tld | sed '$a\\'

  • "No such app" (Heroku)

  • "404 - Site not found" (GitHub Pages)

  • "Bucket does not exist" (AWS S3)

  • "404 - Page not found" (Generic)

  1. Intentar reclamar el subdominio ingresando al servicio tercero (AWS por ejemplo), crear una instancia web y asignarle el mismo nombre del recurso trazado desde el registro dns CNAME (app.aws.com) y corroborar si este puede ser reclamado.

III. Impacto

  • Uso de subdominios para robo de credenciales, datos bancarios y phishing, alojando sitios falsos con inicios de sesión, portales de pago, etc

  • Publicación de contenido malicioso

  • Controlar un subdominio de confianza se podría utilizar para capturar cookies y tokens de sesión por redireccionamientos, si no se encuentran configurados los headers Secure o HttpOnly

  • Inyección de payloads XSS maliciosos que afecten otros subdominios del dominio principal

  • Reactivar servicios que previamente contenían información sensible del dominio original

  • Daño reputacional sobre la compañía que genere que los usuarios pierdan la confianza en el subdominio afectado, y por consiguiente, sobre el dominio como tal

IV. Mitigación

  • Revisión de registros DNS en busca de subdominios que apunten a servicios desactivados. En caso de desactivar un servicio, eliminar inmediatamente el registro DNS que lo apunta

  • Evitar usar registros CNAME con wildcard (*.domain.tld)

  • Reclamar servicios antiguo que hayan sido usados en servicios externos (AWS, Heroku) aunque no estén en uso

AnteriorVulnerabilidades (PoC)SiguienteCORS