TL; DR Imagínese lo que podría suceder si el dominio de nivel superior del código de país (ccTLD) de un estado soberano cayera en las manos equivocadas. Sin embargo, yo ( @Almroot ) compré el nombre de dominio que figura para la delegación de NS en el ccTLD de la República Democrática del Congo (
.cd
) y tomé temporalmente el 50% de todo el tráfico de DNS para ese TLD. En mi lugar, podría haber un atacante que aprovecharía esta oportunidad para MITM u otros abusos.
Introducción
Una semana antes de Navidad, decidí hacer un análisis de todos los registros NS de todos los TLD del mundo. Y una cosa me llamó la atención. El dominio
scpt-network.com
tenía el código de estado EPP "redemptionPeriod". Esto significa que el propietario no transfirió dinero para la renovación del dominio. Si el propietario continúa ignorando el pago, entonces le quitarán su propiedad y el dominio saldrá a la venta.
Situación bastante problemática, ya que se incluye en la lista de servidores NS que gestionan la zona
.cd
:
almroot@x:~$ dig NS +trace cd | grep "cd."
cd. 172800 IN NS ns-root-5.scpt-network.com.
cd. 172800 IN NS igubu.saix.net.
cd. 172800 IN NS sangoma.saix.net.
cd. 172800 IN NS ns-root-2.scpt-network.com.
cd. 172800 IN NS sabela.saix.net.
cd. 172800 IN NS ns-root-1.scpt-network.com.
Decidí escribir un script bash por si acaso me notificaría cada vez que cambiara el estado del EPP.
Para mi sorpresa, aproximadamente una semana después, recibí una notificación de que el dominio se había movido al estado "pendiente de eliminación".
Estaba consciente de la gravedad de la situación . El nombre de dominio pronto se pondrá a la venta para todos, es decir, cualquiera puede hacerse cargo fácilmente del servidor de nombres
.cd
.
Cambié el script y comencé a hacer ping al registrador cada minuto para obtener más cambios de estado.
En la noche del 30 de diciembre, llegó una notificación. Abrí mi computadora portátil y compré un nombre de dominio para evitar que cayera en las manos equivocadas.
Como quedaban tres registros de delegación más en SAIX (intercambio de Internet de Sudáfrica, punto de intercambio de tráfico de Sudáfrica ), el código de país permaneció operativo (aunque la velocidad para resolver cualquier dominio disminuyó ligeramente).
Una vez
scpt-network.com
que lo tuve, pude configurar cualquier subdominio a mi discreción. Por ejemplo, si crea un nuevo subdominio
ns-root-1
con un registro A que apunta a la dirección IP 1.3.3.7, las consultas de DNS para la zona .cd irán a esta dirección 1.3.3.7. Cualquier respuesta de DNS a estas consultas se aceptará como legítima.
Si no responde a la solicitud, el suscriptor expirará con el código de estado SERVFAIL. Esto es bueno, porque cuando recibe dicho código, intentará contactar con cualquier otro servidor de nombres (registro NS) para esa zona. Esto eventualmente terminará en uno de los registros SAIX normales y será redirigido apropiadamente al destino correcto.
Impacto potencial
La incautación del dominio nacional de alto nivel de un estado soberano tiene graves consecuencias negativas, especialmente si este dominio cae en manos de ciberdelincuentes o de un adversario extranjero. La República Democrática del Congo (RDC) es un país bastante grande. Esto es aproximadamente 90 millones de personas , sin mencionar las numerosas empresas y organizaciones internacionales que operan en esta zona de dominio.
Secuestrar el registro de TLD de DNS de todo un país es raro, pero no nuevo. Por ejemplo, hace diez años, los ciberdelincuentes se apoderaron del dominio de la antigua Unión Soviética (.su), y en 2015, los sitios vietnamitas Lenovo y Google (.vn) también fueron víctimas de secuestro de DNS.... Redirigir el tráfico DNS de sitios legítimos .cd a un sitio de phishing es una de las oportunidades obvias de abuso, pero existen otras:
- Intercepción pasiva del tráfico DNS
: para vigilancia o exfiltración de datos
- Creación de nuevos nombres de dominio "de la nada"
: imagine las posibilidades de generar rápidamente nuevos nombres de dominio con la botnet cambiando a nuevos servidores C&C cada pocos minutos, de modo que nadie tenga tiempo de bloquearlos (técnica de flujo rápido )
- Ataques de ejecución remota de código (RCE) en redes locales
: las víctimas serán empresas que utilicen WPAD (Protocolo de configuración automática de proxy)
- Respuestas de DNS falsificadas a consultas de DNS legítimas
: secuestrar por completo los dominios raíz en una zona.cd
o realizar un ataque DDoS.
Por ejemplo, podría escribir un exploit para secuestrar un dominio específico en una zona
.cd
. Imagine que para cualquier solicitud de NS,
google.cd
siempre devuelvo respuestas
ns-root-1.scpt-network.com
(en lugar de estas cuatro :)
[ns1,ns2,n3,ns4].google.com
. El suscriptor recibirá dicha respuesta y enviará cualquier solicitud de DNS posterior a
ns-root-1.scpt-network.com
.
También me hizo pensar: ¿qué pasa si respondo a todas las solicitudes de NS con un enlace a mí mismo? Luego, para cualquier solicitud a la que responda 1.3.3.7, todas las búsquedas de dominio terminarán yendo a ese enlace. Y todo el tráfico de red posterior se redireccionará a 1.3.3.7, lo que puede provocar un ataque DDoS.
De hecho, esto también afectará la disponibilidad de todo el TLD, ya que el 50% de las respuestas de DNS se volverán incorrectas. La fuerza de (ambos) ataques DoS se puede aumentar estableciendo un TTL alto en las respuestas de DNS.
Demos un paso más. Digamos que estoy falsificando específicamente registros TXT para el servidor
google.cd
. Utilizando archivos de texto falsos, engaño
al sistema de validación DNS-01 del registrador Let's Encrypt para que obtenga un certificado válido
google.cd
y luego piratee eficazmente el canal cifrado SSL / TLS.
Ya que puedo controlar la delegación de servidores NS para cualquier dominio
.cd
y obtener certificados válidosentonces puedo realizar un ataque MITM incluso si la víctima está usando SSL / TLS.
Nota del traductor. Algunos de los métodos descritos están disponibles para las agencias gubernamentales que controlan los dominios de código de país en sus países.
Si bien Google implementa varias contramedidas contra tales abusos, es seguro decir que esto no se aplica a todos los dominios raíz en la zona .cd. Para obtener más información sobre cómo las CA verifican la propiedad del dominio, consulte BR 1.7.3 .
Por último, pero no menos importante, con acceso privilegiado a un host ascendente con control de DNS, puedo ingresar a las LAN de la empresa(ejemplo en la captura de pantalla a continuación) que envían solicitudes de DNS a WPAD: puede rastrear sus solicitudes, respuestas falsas y redirigir a la víctima para que descargue y ejecute una configuración de servidor proxy maliciosa en JS . WPAD tiene una serie de problemas, incluyendo vulnerabilidades RCE, de acuerdo a los piratas informáticos del equipo de Proyecto Zero de Google.
Arreglando el problema
El 7 de enero de 2021, me comuniqué con los contactos administrativos y técnicos enumerados para la zona .cd en la página de la IANA . Inicialmente, quería transferir el dominio a un operador
.cd
.
Aunque uno de los contactos respondió y me refirió a un colega, en el momento de escribir este artículo, no he recibido una confirmación por escrito de que hayan solucionado el problema. Pero pronto el tráfico de DNS se redirigió a scpt-network. neto .
El 8 de enero, también envié un informe sobre la recompensa por errores de Internet a HackerOne, que ofrece recompensas por piratería responsable de la infraestructura de Internet.
Conclusión
El secuestro del servidor DNS es extremadamente negativo, especialmente si el atacante tiene malas intenciones. Esta vulnerabilidad afecta a más de un sitio, subdominio o dominio raíz. Cualquier sitio web puede convertirse en víctima de phishing, MITM o DDoS
.cd
, incluidos los sitios web de grandes empresas internacionales, instituciones financieras y otras organizaciones. Y este es el segundo país más grande de África y una zona de dominio popular.
En el momento de escribir este artículo, todavía soy propietario del nombre de dominio scpt-network.com, aunque la delegación de solicitudes de NS de la zona .cd se detuvo alrededor del 8 de enero de 2021 después de que los contacté. Realicé esta operación para evitar que los atacantes se apoderaran de la zona de dominio de la República Democrática del Congo, cuando cualquiera pudiera secuestrar el nombre de dominio de uno de los servidores que controlan el ccTLD. Afortunadamente, todo salió bien en este caso.