Hoy en día muchas empresas y marcas, así como ciertos particulares subcontratan ciertos servicios a otras empresas, SaaS (Software as a Service), lo que le quita cierto trabajo en subservicios en los que igual no tienen ni tiempo ni conocimientos como para enredarse (sistemas de videoconferencias, servicios de tickets, backends, tiendas…).
Normalmente, el usuario crea una cuenta en ese servicio y cambia la DNS para que su subdominio servicio.dominio.com tenga su CNAME apuntando al SaaS en cuestión.
Esto le permite de forma cómoda y sencilla confiar ciertas partes de su negocio a desarrolladores con mayor experiencia, pero a veces no es todo perfecto…
El problema viene cuando la empresa en cuestión, por el motivo que sea (migración de servicios, simplemente estaban testeando un posible servicio futuro, problemas de pagos, olvidarse el renovar la suscripción), acaban su “contrato” con el SaaS pero se olvidan de actualizar su CNAME en servicio.dominio.com, ya sea borrándolo o apuntando al nuevo servicio que hayan contratado, esto es lo que se conoce como Dangling DNS, un despiste tan tonto como este, puede traer consigo problemas, los cuales veremos a continuación.
Igual leyéndolo pensemos que pueda ser algo puntual y bastante raro de ver, pero todo lo contrario, ha sido una “vulnerabilidad” bastante extendida que ha afectado tanto a empresas pequeñas como a empresas más grandes ( Microsoft, Chevron, Cruz Roja, UNESCO, 3M, Arm, Warner Brothers, Honeywell, Toshiba, Xerox, NHS, Volvo, y otros ).
Hasta hace algún tiempo, los SaaS no usaban ningún tipo de mecanismo para asegurar que la persona que reclamara un subdominio con un CNAME hacia su servicio, fuese el dueño del dominio en sí, (curioso, ¿verdad?), lo que significaba que, en caso de que alguna persona encontrara estos dangling DNS apuntando a dichos SaaS, con 4 clicks pudiera servir el contenido arbitrario que quisiera en nombre de la empresa, lo que como podemos imaginar no es nada bueno.
Por suerte, algunos SaaS han cambiado esto y ahora para registrar subdominios te piden ciertas “pruebas” para comprobar que sea un proceso legítimo, como por ejemplo pedirte que pongas ciertos TXT en el DNS (al cual no tenemos acceso), o que los subdominios solo puedan ser registrados una única vez con una cuenta.
De todos modos, siguen habiendo muchos SaaS que no ofrecen ningún tipo de seguridad, por lo que sigue siendo posible secuestrar subdominios, lo cual veremos a continuación y por último veremos las posibilidades de ataque que se nos pueden abrir al robar el subdominio.
Bien, supongamos que el dominio https://b0n3sh.com tiene un servicio para solicitar reuniones, el cual está externalizado, en el subdominio https://vuln.b0n3sh.com
Podemos ver que, efectivamente, el subdominio apunta tiene el CNAME apuntando al SaaS
Ahora, como hemos comentado antes, supongamos que la empresa abandona este servicio de reuniones, pero no borra el CNAME, para emular esto, vamos a borrar la cuenta de nuestro SaaS, sin tocar nuestro DNS, ahora, si visitamos https://vuln.b0n3sh.com nos encontramos un precioso error, que nos dirá algo así como “El servicio no está correctamente activado”.
Bien, pongámonos ahora en el lugar del atacante, habrá hecho los deberes y habrá visto que tenemos un dangling DNS, el cual al visitar, verá que no está registrado, si es un SaaS que no tiene implementado ningún tipo de seguridad a la hora de comprobar la persona que registra el subdominio, podrá vulnerar nuestro subdominio.
El atacante no tendrá más que registrarse en dicho SaaS y, dependiendo de cual, ya que cada uno está implementado de una forma distinta, elegir “custom domain”, con lo cual le damos nuestra propia URL, es decir la vulnerada.
Y con esto, el atacante tendría pleno dominio sobre el subdominio.
El alcance del ataque dependerá en parte del propio SaaS, algunos tienen interfaces más restrictivas que otras, mientras que algunas te dejan apuntar con un registro A a tu propia VPS, lo que te da completa libertad.
En el caso que nos aborda, estamos limitados a la interfaz de solicitar reuniones, pero eso no es motivo para frenar un posible ataque, recordemos que este es un dominio “conocido” y el cuál la víctima conoce (b0n3sh.com), por lo que el usuario, es difícil que desconfíe de un subdominio, ya que como sabemos los subdominios son “parte” de la misma gente que lleva el dominio.
Un ejemplo sería simplemente implementar un tipo de phishing, diciendo que nos hemos mudado a otra web, a la que invitamos al usuario a visitar, donde podríamos luego solicitarle ciertos datos, mediante un Evilginx, por ejemplo.
Poniéndonos un poco más creativos, vi que este SaaS daba la opción de incrustar HTML directamente (un poco escondido, eso sí :P), para mi sorpresa no parseaba bien, por lo que echándole un poco de imaginación, nos podemos “comer” la parte de las reuniones, lo que nos da un landing page mucho más directo, que incita a que el usuario nos haga caso y no se nos “distraiga por ahí”…
Y esto sería un ejemplo básico de como se puede hacer phishing con esta vulnerabilidad.
Como ya hemos dicho, dependemos mucho de la libertad que nos de el SaaS en cuestión para la libertad de nuestro ataque, algunos te dejan montar tu propio VPS y simplemente mediante registros A de DNS podemos apuntar dicho registro a nuestra VPS, los cuales incluso nos dejan gestionar los DNS para ese subdominio (sin tener nosotros control del dominio), con lo que podemos añadir nuestros TXT, nuestros MX, lo que significa que podemos enviar correos electrónicos como el dominio vulnerado, ya que “gozamos” de su reputación a la hora de enfrentarnos a medidas anti-spam como las de Gmail.
Además, podemos acceder a las cookies que sean declaradas en wildcard, lo cual suele ser lo común en caso de logins, podemos desde nuestro subdominio recibir dichas cookies mediante HTTP, en caso que tengan la flag SecureOnly no hay mayor problema ya que los SaaS nos suelen proveer automáticamente del TLS, por lo que nuestro tráfico irá por https.
Por último, otro apunte interesante podría ser que, en caso de que en el dominio vulnerado hubiese una aplicación corriendo y tuviese la cabecera especificada de forma que confie en los subdominios, aprovechándonos de este whitelist, nos permite realizar un ataque de CORS haciendo las peticiones desde el subdominio que tenemos en control, al dominio.
En otros casos, como el que hemos demostrado en este post, no tenemos tanta libertad a la hora de montar una VPS y poder tener un backend corriendo para nosotros, simplemente se nos da acceso a una interfaz desde la que montaremos un “html” o algún tipo de frontend todo con las herramientas que nos de dicha SaaS, siendo bastante limitada, por lo que va a tocar…
En los casos en los que tengamos un SaaS más restrictivo, tenemos que jugar con las cartas que nos dan, como hemos visto en el que hemos usado para este ejemplo, podemos incitar al usuario a que visite otro dominio desde donde realizar un phishing.
También, si nos permite ejecutar JavaScript y en el caso de que las cookies no tengan el flag de HttpOnly, podemos robar las cookies del dominio desde nuestro subdominio, como vemos a continuación.
Al final, todo depende de los SaaS, mientras no implementen sus comprobaciones, los clientes de dichos SaaS están expuestos a cierto peligro (siempre y cuando ocurra el pequeño olvido de los dangling DNS).
Tan sencillo como tener los DNS al día y nos ahorraremos un dolor de cabeza.
A modo de resumen, dejo un diagrama explicativo.
