Domain Mayday EP14: Cuando una firma de seguridad sufrió un secuestro de DNS — El incidente Fox-IT

Lo peculiar de un ataque de intermediario es que, mientras ocurre, todo parece normal.

El sitio carga. La barra de direcciones muestra el dominio correcto. El candado está cerrado. El certificado es válido. Los archivos se suben, los inicios de sesión tienen éxito, los correos llegan. No hay error, no hay advertencia, no hay imagen rota — solo un silencioso tercero sentado en medio de la conversación, leyendo todo lo que pasa por sus manos y reenviándolo para que ninguno de los extremos note el retraso.

Ahora imagine que eso le sucede a las personas cuyo trabajo es detectar exactamente eso.

En septiembre de 2017, la firma holandesa de ciberseguridad Fox-IT — una empresa que investiga brechas, construye sensores de detección de interceptaciones y asesora a gobiernos sobre cómo se mueven los atacantes — descubrió que un atacante había secuestrado el DNS de su propio dominio, obtenido un certificado TLS a su nombre y pasado casi un día leyendo el tráfico hacia y desde su portal de clientes. La cerradura del cerrajero había sido forzada. Y entonces Fox-IT hizo lo que casi ninguna empresa comprometida hace: publicó un relato detallado de exactamente cómo sucedió.

Incluso una firma de seguridad depende de su registrador

Esta es la incómoda verdad que este caso hace concreta: sin importar qué tan buena sea tu seguridad interna, una gran parte de tu superficie de ataque vive en una empresa que tú no administras.

Tu dominio — el nombre que tus clientes escriben, la dirección contra la que se emiten tus certificados, el destino al que apunta tu correo electrónico — está configurado en un registrador de dominios. Quien controla esa cuenta del registrador controla hacia dónde resuelve tu nombre. Puede redirigir tu sitio web, redirigir tu correo y demostrar la "propiedad" de tu dominio ante una autoridad certificadora. Nada de eso requiere tocar tus servidores, tus firewalls o tu código. Solo requiere iniciar sesión en un panel web.

Fox-IT era, por cualquier medida, una organización de seguridad seria. Ejecutaba captura completa de paquetes y sus propios sensores de red. Utilizaba autenticación de dos factores en su portal para clientes. Posteriormente fue adquirida por NCC Group. Y aun así quedó expuesta a través de la única cuenta en la que casi nunca iniciaba sesión — porque, como la propia empresa señaló, los ajustes de DNS en general cambian muy raramente, por lo que las credenciales que los protegían se fueron quedando silenciosamente obsoletas.

Como Fox-IT planteó al inicio de su propio informe: si tal ataque puede afectar a una firma de seguridad, lo más probable es que pueda afectar a muchos otros tipos de empresas que se centran menos en la seguridad.

19 de septiembre de 2017: el secuestro y el MITM

El relato de Fox-IT comienza con una línea que desde entonces se ha convertido en un pequeño clásico de la escritura sobre respuesta a incidentes: Para Fox-IT el "si" se convirtió en "cuando" el martes 19 de septiembre de 2017, cuando la empresa fue víctima de un ataque de intermediario.

Lo que ocurrió no fue un exploit de servidor. En la madrugada del 19 de septiembre, un atacante accedió a los registros DNS del dominio Fox-IT.com en nuestro registrador de dominios externo. Con el control de esos registros, el atacante modificó un registro DNS de un servidor específico para que apuntara a un servidor en su posesión e interceptara y reenviara el tráfico de vuelta a la infraestructura real de Fox-IT.

Ese último detalle — reenviar el tráfico — es lo que lo convirtió en un ataque de intermediario en lugar de una simple interrupción. Los visitantes seguían llegando a un portal funcional. Solo lo hacían a través del atacante primero.

El objetivo era específico. El ataque estaba dirigido específicamente a ClientPortal, la aplicación web de intercambio de documentos de Fox-IT, el sistema que Fox-IT usaba para intercambiar archivos de forma segura con clientes, proveedores y otras organizaciones. En otras palabras, el atacante fue directamente al canal por donde fluían los documentos confidenciales de los clientes.

Gracias a que Fox-IT lo detectó y contuvo, la empresa limitó el tiempo total efectivo del MitM a 10 horas y 24 minutos. La cobertura independiente confirmó el mismo dato: el incidente ocurrió el 19 de septiembre y duró 10 horas y 24 minutos.

Qué fue interceptado exactamente

Diez horas de ataque de intermediario en un portal de intercambio de documentos suena catastrófico. El botín real fue pequeño — y esa pequeñez es en sí misma la historia.

Durante la ventana de ataque, nueve usuarios individuales iniciaron sesión y sus credenciales fueron interceptadas. Pero esas credenciales resultaron inútiles en gran medida: el portal de Fox-IT requería un segundo factor de autenticación que el atacante, sentado en la ruta de red, no podía repetir. Help Net Security señaló que las credenciales de inicio de sesión de nueve usuarios fueron capturadas pero eran inútiles sin el segundo factor de autenticación.

En cuanto a archivos, doce archivos (de los cuales diez eran únicos) fueron transferidos e interceptados. Algunos contenían información confidencial de clientes. El atacante también capturó un subconjunto de nombres y direcciones de correo electrónico de usuarios de ClientPortal, algunos nombres de cuenta y un número de teléfono móvil, como resumió SecurityWeek.

Dos hechos mantuvieron el daño acotado. Primero, Fox-IT declaró claramente que los archivos clasificados como secreto de estado nunca se transfieren a través de nuestro ClientPortal — el material más sensible simplemente nunca existió en el canal expuesto. Segundo, el propio segundo factor de la firma amortiguó el robo de credenciales. La arquitectura limitó el radio de daño incluso después de que el perímetro — el DNS — hubiera fallado.

Cómo ocurrió: una contraseña obsoleta, sin segundo factor

El mecanismo parece una lista de verificación de cómo se toma un dominio sin una sola línea de malware en los servidores de la víctima.

Paso uno — entrar a la cuenta del registrador. El atacante inició sesión correctamente en el panel de control DNS de nuestro proveedor de registrador de dominio externo usando credenciales válidas. La investigación de Fox-IT concluyó que el atacante probablemente obtuvo acceso a las credenciales del panel de control DNS de su registrador de dominio mediante el compromiso de un proveedor externo. Dos debilidades combinadas hicieron que ese inicio de sesión funcionara: la contraseña no había sido cambiada desde 2013, y el registrador no ofrecía ningún segundo factor — en el momento de escribir esto, Fox-IT señaló que el registrador aún no admite 2FA.

Paso dos — cambiar DNS y demostrar "propiedad" ante una CA. Con el panel abierto, el atacante redirigió el DNS. Pero para ejecutar un ataque de intermediario creíble en un sitio HTTPS, necesitaba un certificado válido para fox-it.com — y la forma moderna de obtenerlo es demostrar que controlas el dominio. Así que el atacante hizo exactamente eso. En una estrecha ventana alrededor de las 02:05–02:15, redirigió e interceptó temporalmente el correo electrónico de Fox-IT con el propósito específico de demostrar que era propietario de nuestro dominio durante el proceso de registro fraudulento de un certificado SSL para nuestro ClientPortal. Esta es la parte que debería hacer pausar a todo lector: el control del DNS es, en la práctica, el control de la validación de dominio. Un certificado validado por dominio se concede a quien pueda responder al desafío de la CA — y aquí, controlar el DNS permitió al atacante redirigir el correo electrónico de validación y responderlo. El DNS decide dónde aterriza esa prueba de propiedad.

Paso tres — situarse en el medio. Armado con un certificado emitido legítimamente (pero obtenido fraudulentamente), el atacante apuntó el dominio a un VPS en el extranjero e interceptó el tráfico. Como describió SecurityWeek, el certificado SSL falso fue utilizado para un ataque MitM contra ClientPortal, con el tráfico al portal enrutado a través de un proveedor de servidor privado virtual (VPS) en el extranjero. Para un visitante, nada estaba mal. El candado era real. El certificado validado. El intermediario sostenía una llave en la que confiaba el navegador.

Tres capas — DNS, la autoridad certificadora y el propio TLS — funcionaban todas técnicamente de forma correcta. El atacante no rompió ninguna de ellas. Convenció a las tres de que era Fox-IT, y lo único que le permitió hacerlo fue un inicio de sesión obsoleto y sin un solo factor en un registrador.

La respuesta de Fox-IT: detectar, contener y luego contárselo a todos

Lo que diferencia este incidente de cientos de otros más silenciosos es la respuesta — tanto técnica como editorial.

La detección fue rápida. Fox-IT determinó que los servidores de nombres de su dominio fox-it.com habían sido redirigidos, detectando la intrusión aproximadamente cinco horas después de que comenzara — unas cinco horas después de que comenzara el ataque, según Help Net Security. La captura completa de paquetes y los sensores de red que la empresa ejecutaba sobre sí misma le proporcionaron el registro forense para reconstruir exactamente qué había sido tocado y qué no.

El contenimiento fue deliberado. En lugar de desconectar el portal y alertar al atacante, Fox-IT eligió una mitigación más discreta: deshabilitó el segundo factor de autenticación de nuestro sistema de autenticación de inicio de sesión del ClientPortal — un movimiento contraintuitivo, pero que le permitió gestionar la situación mientras recuperaba el control de su DNS, sin revelar que había detectado la intrusión. Luego contactó inmediatamente a los clientes afectados respecto a estos archivos.

Luego llegó la parte que lo convirtió en un caso de estudio. Tres meses después, tras el análisis y con una investigación policial en marcha, Fox-IT publicó un post-mortem completo con marcas de tiempo bajo una tesis simple: la transparencia genera más confianza que el secretismo y hay lecciones que aprender. Una empresa de seguridad había sido expuesta de la manera más representativa posible — y en lugar de ocultarlo, entregó a la industria un análisis detallado. El titular de BleepingComputer capturó el tono que merecía el momento: Top Security Firm Admits to MitM Security Incident.

Qué enseña esto sobre la seguridad del registrador y los registry locks

Deja de lado los detalles y el incidente Fox-IT es una lección sobre dónde está el perímetro real. Para la mayoría de las organizaciones, el perímetro no es solo el firewall. Es el inicio de sesión del registrador. Esto es lo que argumenta el caso:

1. Trata la cuenta del registrador como infraestructura de producción. Rara vez cambia, por lo que es fácil olvidarla — y eso es exactamente por qué se deteriora. Una contraseña sin cambiar desde 2013 no es "bajo riesgo porque hay poco tráfico"; es una credencial de alto valor sin monitoreo.

2. Exige autenticación multifactor en el registrador — y cámbiate si no la ofrece. El registrador de Fox-IT no admitía 2FA en absoluto. La cuenta más importante en la cadena de seguridad de tu dominio estaba protegida solo por una contraseña. La presencia o ausencia de 2FA en un registrador es un criterio de adquisición, no un añadido opcional.

3. Usa un registry lock. Más allá del propio inicio de sesión del registrador, muchos registros ofrecen un registry lock — un bloqueo del lado del servidor que impide cambios en los servidores de nombres y registros de contacto a menos que se complete un paso de verificación manual fuera de banda. Un registry lock habría significado que incluso con una contraseña del registrador completamente comprometida, no se podría redirigir el DNS silenciosamente. Convierte "a un panel de distancia" en "múltiples personas y una llamada telefónica de distancia."

4. Implementa DNSSEC donde puedas. DNSSEC firma criptográficamente las respuestas DNS para que los resolvedores puedan detectar manipulaciones en la ruta de resolución. No es una solución mágica aquí — un atacante que controla los registros autoritativos puede volver a firmarlos — pero eleva el costo y cierra clases enteras de manipulación DNS en tránsito. La defensa en profundidad en la capa DNS importa precisamente porque, como mostró este caso, el DNS se sitúa por encima de TLS y la emisión de certificados en la pila de confianza.

5. Recuerda que el control del DNS equivale al control del certificado. El atacante obtuvo un certificado TLS válido demostrando la propiedad del dominio a través del correo electrónico redirigido. Monitorea los registros de Transparencia de Certificados para detectar certificados inesperados emitidos contra tus dominios. Un certificado fraudulento que aparece en CT es una de las pocas señales externas de que un secuestro de DNS puede estar en marcha.

6. Mantén un segundo factor en la propia aplicación. El 2FA del portal de Fox-IT es la razón por la que nueve contraseñas robadas fueron inútiles sin el segundo factor de autenticación. Cuando la capa exterior (DNS) falló, la capa interior (MFA a nivel de aplicación) aún limitó el daño.

El hilo conductor: tu dominio es un punto único de fallo que en parte externalizas. Reforzarlo no es glamoroso, y solo da sus frutos el día en que alguien intenta exactamente lo que le pasó a Fox-IT.

El ángulo Namefi

El incidente Fox-IT es, en esencia, un problema de control y procedencia. El atacante nunca necesitó ser Fox-IT. Solo necesitaba que un sistema — el panel del registrador — creyera que lo era, durante el tiempo suficiente para redirigir el DNS y emitir un certificado. Todo lo que estaba aguas abajo confió en esa creencia.

Namefi está construido para hacer que el control de dominios sea verificable y resistente a manipulaciones, en lugar de depender de una única contraseña reutilizable en el panel web de un proveedor. Al representar la propiedad del dominio como un activo verificable en cadena que permanece compatible con el DNS, el control se convierte en algo que puedes auditar y demostrar — no solo en una cuenta en la que alguien podría iniciar sesión silenciosamente y reconfigurar. Los cambios críticos pueden vincularse a la propiedad que realmente tienes, en el espíritu de un registry lock, en lugar de a una credencial que no ha sido rotada en años.

Nada de esto haría imposible a un atacante determinado. Pero la historia de Fox-IT trata en última instancia de un único inicio de sesión robado que se traduce en control total de un nombre. Cuanto más cerca esté el control del dominio de la propiedad verificable — y más difícil sea cambiar un nombre silenciosamente con una sola contraseña obsoleta — menos puede propagarse un momento como el "si se convirtió en cuando" de Fox-IT antes de que alguien lo note.

Una firma de seguridad detectó su propio secuestro en cinco horas y le contó al mundo cómo. La mayoría de las organizaciones no lo habrían detectado en ninguno de los dos sentidos. La lección más barata es la que Fox-IT pagó: bloquea el registrador antes de que se convierta en la puerta abierta.

Fuentes y lecturas adicionales

• Fox-IT (NCC Group) — Lessons learned from a Man-in-the-Middle attack (post-mortem principal)
• BleepingComputer — Top Security Firm Admits to MitM Security Incident
• Help Net Security — Security company Fox-IT reveals, details MitM attack they suffered in September
• Graham Cluley — Fox-IT reveals hackers hijacked its DNS records, spied on clients' files
• SecurityWeek — Hackers Target Security Firm Fox-IT
• GBHackers — Leading IT Security Firm Fox-IT hit by Cyber Attack
• Krebs on Security — A Deep Dive on the Recent Widespread DNS Hijacking Attacks (relacionado: técnica de secuestro DNS + certificado fraudulento a escala)