Responder: cómo funcionan los ataques a protocolos de red locales

Responder es una herramienta que demuestra un problema de seguridad clásico de las redes locales relacionado con ciertos protocolos antiguos de resolución de nombres, conocidos por sus siglas LLMNR y NBT-NS, que vienen activados por defecto en muchas redes Windows y que son inseguros por diseño. La resolución de nombres es el proceso por el cual un equipo traduce un nombre a una dirección para poder comunicarse, y lo habitual es que lo haga preguntando al servidor DNS. El problema surge cuando el DNS no encuentra el nombre: en ese caso, los sistemas recurren a estos protocolos de reserva, que preguntan a toda la red local si alguien conoce ese nombre, y aceptan sin ninguna verificación la respuesta de quien sea que conteste. Responder automatiza el aprovechamiento de esa confianza ciega: se hace pasar por el destino que la víctima busca, de modo que el equipo engañado se dirige a él y le envía lo que enviaría al servicio legítimo, que típicamente incluye información de autenticación. Lo que Responder demuestra, en definitiva, es por qué esos protocolos heredados deben desactivarse, ya que el fallo no está en la herramienta sino en que esos protocolos sigan activos en redes donde ya no son necesarios y donde no se puede confiar en todos los equipos conectados.

LLMNR y NBT-NS son dos protocolos de resolución de nombres heredados de los entornos Windows, pensados como mecanismo de reserva para cuando la resolución normal a través del DNS no encuentra un nombre. Su funcionamiento consiste en que el equipo que necesita resolver un nombre lanza una consulta a toda la red local, en modo difusión, preguntando si algún equipo de la red sabe a qué dirección corresponde ese nombre, y luego confía en la respuesta que reciba. El origen de su inseguridad está precisamente en ese modelo: fueron diseñados para redes pequeñas y de confianza, en las que se asumía que cualquier equipo que respondiera sería honesto, y por eso no incluyen ningún mecanismo para verificar que quien responde es realmente el destino legítimo. En una red moderna, donde no se puede asumir que todos los equipos conectados sean de confianza, esa ausencia de verificación es un agujero grave, porque permite que cualquier equipo de la red responda afirmando falsamente ser el destino buscado y sea creído sin cuestionamiento. Esto habilita el ataque de envenenamiento que herramientas como Responder automatizan. La buena noticia es que estos protocolos rara vez son necesarios hoy en día, porque el DNS cubre la resolución de nombres en prácticamente todos los entornos, de modo que pueden desactivarse sin efectos prácticos en la mayoría de las redes, cerrando así el problema de raíz.

La herramienta es legal, pero utilizarla en una red que no es tuya y sin autorización constituye un delito claro, y en este caso especialmente grave por la naturaleza del ataque. Un ataque de envenenamiento con Responder no se limita a observar, sino que intercepta activamente comunicaciones dirigidas a otros equipos y captura información sensible, típicamente información de autenticación de los usuarios de la red. Esto implica a la vez un acceso no autorizado a la red y una interceptación de comunicaciones ajenas, dos conductas que la legislación penaliza. Por eso Responder solo debe utilizarse en redes de tu propiedad, en entornos de laboratorio aislados preparados para practicar, o en el marco de una auditoría interna con autorización explícita y un alcance claramente definido, en la que la organización propietaria de la red ha dado permiso para probar precisamente este tipo de debilidades. En una auditoría autorizada, este tipo de prueba es muy valiosa porque demuestra de forma concreta el riesgo de mantener activos los protocolos heredados y justifica su desactivación. Como con todas las herramientas de seguridad de doble uso, lo que distingue una prueba legítima de un delito no es la herramienta ni el conocimiento, sino la autorización previa y la intención con la que se emplea.

La defensa contra el envenenamiento de protocolos de resolución de nombres es una de las más claras y efectivas que existen, porque el problema se corta de raíz eliminando lo que sobra. La medida principal y más importante es desactivar los protocolos heredados LLMNR y NBT-NS en los equipos de la red, ya que rara vez son necesarios en los entornos actuales, donde el DNS cubre la resolución de nombres, y su desactivación elimina por completo la posibilidad del ataque sin efectos prácticos en la mayoría de las redes. Como medida complementaria, conviene segmentar la red, de modo que un atacante situado en un segmento no pueda alcanzar a las posibles víctimas de otro, lo que limita el alcance de cualquier ataque de ámbito local. En tercer lugar, es fundamental usar contraseñas fuertes y mecanismos de autenticación robustos, porque aunque un atacante llegara a capturar información de autenticación, una contraseña larga y única no cedería ante una auditoría fuera de línea, y las protecciones modernas dificultan la reutilización de lo capturado. Por último, es muy recomendable monitorizar el tráfico de la red local con herramientas de análisis, ya que la aparición de respuestas anómalas a estas consultas de resolución de nombres es una señal reveladora de un envenenamiento en curso y permite detectarlo y responder. La combinación de desactivar los protocolos y reforzar la autenticación hace que este ataque deje de ser una amenaza.

Se dice que el problema es el protocolo y no la herramienta porque Responder no explota ningún fallo ni rompe ninguna protección, sino que simplemente se comporta como los propios protocolos LLMNR y NBT-NS permiten y esperan que se comporte cualquier equipo de la red. Estos protocolos, por diseño, lanzan una pregunta abierta a toda la red local y aceptan la respuesta de cualquiera sin verificarla, de modo que responder a esa pregunta afirmando ser el destino buscado no es una violación del protocolo, sino un uso previsto de él. Responder no hace más que automatizar esa respuesta. Por eso la raíz del problema no está en que exista una herramienta capaz de aprovecharlo, sino en que esos protocolos inseguros sigan activos en redes donde ya no son necesarios y donde no se puede confiar en todos los equipos. Esta distinción es importante desde el punto de vista defensivo, porque orienta la solución hacia el lugar correcto: no se trata de intentar bloquear una herramienta concreta, que además tiene muchas alternativas equivalentes, sino de eliminar la condición que hace posible el ataque, que es la presencia de los protocolos heredados. Desactivarlos resuelve el problema para cualquier herramienta que intente aprovecharlo, presente o futura, lo que ilustra un principio general de la seguridad: es más robusto cerrar la debilidad de fondo que perseguir cada herramienta que la explota.

En la gran mayoría de las redes actuales, desactivar LLMNR y NBT-NS no rompe nada y no tiene efectos prácticos negativos, porque la función que cumplen, que es la resolución de nombres, está ya cubierta de forma completa y fiable por el DNS, que es el mecanismo estándar y correctamente diseñado para esa tarea. Estos protocolos solo entran en acción como reserva cuando el DNS no encuentra un nombre, y en una red bien configurada esa situación corresponde casi siempre a consultas que de todos modos no deberían resolverse, como errores tipográficos o referencias a recursos que ya no existen, de modo que no se pierde funcionalidad legítima al desactivarlos. No obstante, como con cualquier cambio de configuración en una red, la recomendación prudente es planificar la desactivación, aplicarla primero en un entorno de prueba o en un grupo reducido de equipos, y verificar que la resolución de nombres mediante DNS funciona correctamente para todos los servicios y recursos que la organización utiliza. En los casos muy poco frecuentes en que alguna aplicación heredada dependiera de estos protocolos, lo adecuado es corregir esa dependencia configurando correctamente el DNS, en lugar de mantener activo un protocolo inseguro. En conjunto, el beneficio de seguridad de desactivarlos supera con mucho el riesgo prácticamente nulo de afectar a la operación, por lo que es una recomendación ampliamente aceptada.