En las anteriores artículos (I, II) se realizo un repaso sobre los conceptos fundamentales del funcionamiento del Sistema DNS. En esta "entrada" se analizaran los problemas de seguridad asociados al Sistema DNS actual y cuales son las medidas de protección a implementar.
Si recordamos los anteriores artículos sobre DNS, para conectarnos a un servidor o cualquier otro recurso de una red, es necesaria alguna forma de indicar el destino, esto se consigue asignando direcciones de red (IP). La dirección de red (IP) debe de ser única para poder encaminar correctamente los paquetes de un host o router a otro, esto desde la perpestiva de los equipo informáticos. Sin embargo, ya se vio en su momento, que desde la perspectiva del usuario para acceder a los recursos de Internet se utilizan los nombres de dominio (DNS) que da lugar al Sistema de DNS actual, para cada nombre de dominio existe una o varias IP asociadas.
¿Qué pasaría si alguien consiguiera cambiar la IP asociada a un determinado dominio?
En ese caso, el acceso a los servicios a través del nombre de dominio "manipulado" conduciría al usuario hacia un servidor "malicioso" con publicidad, phishing, troyanos, malware, etc. En definitiva, llevaría al usuario hacia un servidor "falso" o incluso provocaría la caída del servicio (DoS).
Vulnerabilidades DNS
En 2008 fue descubierta una grave vulnerabilidad en el Sistema DNS por el investigador Dam Kamisky, esta permitía a un atacante realizar un "envenenamiento de la cache" (cache poisoning attacks). El ataque no era nuevo, sin embargo la forma de explotar esa vulnerabilidad fue lo que clasifico la vulnerabilidad como "muy crítica".
El ataque de "envenenamiento de la cache DNS" consiste en "explotar" una vulnerabilidad de modo que el servidor DNS acepta una información "manipulada", al no realizar una validación correcta en las respuestas DNS procedentes de una fuente (servidor) "no autoritativa". Al no validar correctamente el atacante puede "inyectar/manipular" registros siendo estos cacheados en el Servidor DNS.
La cache de los Servidores DNS es una pequeña base de datos que contiene el resultado de las peticiones de "nombres de dominio" (DNS) a consultas previas, con objeto de acelerar los tiempos de respuesta. Es decir, cuando los usuarios realizan una petición al www.google.es, realmente el sistema de cache devuelve inmediatamente la IP almacenada en la cache como consulta previa realiza por otro usuario, no llegando a consultar el registro original.
Existen dos tipo de cache:
Local: es la base de datos ubicada en los ordenadores de los usuarios, es decir, la cache que guarda tu ordenador cada vez que realizas una consulta mediante el navegador Web.
 |
| C:\ipconfig /displaydns |
Si deseamos borrar la cache local de DNS, se ejecuta el comando: ipconfig /flushdns
Remota: la base de datos ubicada en los servidores DNS, utilizada para acelerar las consultas DNS, de forma que ante las mismas consultas, resuelve utilizando el sistema de "cache" y no accediendo al registro DNS correspondiente.
El ataque de Dam Kamensky consite en "secuestrar" una sesión (hijack the authority record) procedente de un servidor autoritativo, de forma que el proceso de "envenenamiento" sea mucho más efectivo y rápido. La explicación con todo lujo de detalles sobre esta vulnerabilidad la podéis encontrar en la "An Illustrated Guide to the Kaminsky DNS Vulnerability", cuya lectura os recomiendo.
Como se puede intuir, el alcance del "problema" si se consigue envenenar la cache de un servidor DNS, y sobre todo si la cache que ha sido "envenenada" es la correspondiente a un servidor "raíz", es realmente alarmante ¿verdad?. Afortunadamente existe solución, y los servidores DNS han corregido la vulnerabilidad.
La falta de controles de integridad en las consultas recursivas realizadas por el protocolo DNS, y por consiguiente por los Servidores que lo implementan, hacen de él un protocolo (in)seguro.
Seguridad en los Sistemas
Existen algunas medidas para prevenir este tipo de ataques y vulnerabilidades:
1) Si el servidor DNS no es accesible desde Internet, no puede realizarse el ataque con éxito. Las empresas con servidores DNS propios, deberán de proteger el acceso a los servidores desde Internet, creando dos zonas (Externa / Interna). Siendo el servidor DNS interno de la red quien tenga mayor relevancia, mientras el externo sea configurado en modo Relay.
2) DNS-Sec: una solución parcial a los problemas existentes en DNS. DNSSEC responde a “Domain Name System Security Extensions”. DNSSEC es una extensión del protocolo DNS (RFCs 1034 y 1035) y es definido en varias especificaciones por la Internet Engineering Task Force (IETF). Proporciona control de integridad en los registros y consultas de los servidores DNS, aunque todavía existen ciertos problemas de implementación que ponen en duda su efectividad real, pero en teoría la correcta implementación de esta extensión daría con la solución al "envenenamiento de la cache". Existe un proyecto Open Source dedicado a gestionar e implementar DNSSEC en los servidores, denominado OpenDnsSec.
3) La utilización de SSL, se puede considerar una medida efectiva al validar el servidor mediante certificados. El problema real, es que no existe una forma sencilla de que el usuario sea correctamente advertido, y en la mayoría de los casos el "propio" usuario es quién ignora las advertencias de seguridad relacionadas. Es por tanto, una medida técnica efectiva, aunque parcialmente ignorada por la falta de concienciación en seguridad.
Realmente, esta vulnerabilidad es inherente al protocolo DNS, por lo que sigue existiendo y por consiguiente es explotable. Sin embargo, existen algunas medidas de mitigación que dificultan la ejecución del ataque y minimizan la probabilidad de éxito.
En caso, de no poder aplicar algunas de las medidas de "prevención" anteriormente expuestas, se deben de tomar una serie de precauciones, antes de configurar un servidor DNS con acceso desde Internet. A este respecto los fabricantes han desarrollado un parche para los servidores DNS (software) que realiza la "randomización" de los puerto origen (source port) que se utilizan en las conexiones para reducir la superficie de exposición y la probabilidad de éxito en el ataque.
La aplicación del parche disponible por el fabricante no es suficiente, se debe de realizar una configuración segura de los servidores DNS, limitar el uso de consultas recursivas y controlar mediante "listas de acceso" y/o cortafuegos los servidores autorizados.
Hasta aquí el flash de formación sobre DNS, espero que os hay gustado.
Un Saludo.
Referencias:
[1] Dam Kamensky Blog.
