(Update: y el bug ya se hizo público 2 semanas antes del plazo, y muchos servidores peruanos siguen vulnerables, excelente)
Update2: Ya hay plugin de metasploit para detectar el puerto de origen de los servidores DNS (lo que permite buscar todo un rango de IPs con facilidad). Esperen un exploit en unas horas.
ENJOY!
Pasen y tomen asiento. Trataré de ser breve y conciso, sin desviarme a temas "esotéricos" como IPv6, encriptación y jerga de seguridad informática (pero me pondré técnico y repartiré patadas al final, si sabes la diferencia entre un resolver y un name server, te puedes saltar la introducción). Aunque posiblemente no entiendan la mitad de lo que voy a decir, al menos crean en mis conclusiones. Deriven esto a los jefes/gerentes de sus áreas de sistemas y proveedores de Internet; y si la razón y un link a este post no funciona para convercerlos, apliquen el principio de ingeniería de Dilbert para convencer MBAs:
Esta tira de Dilbert que
usé hace casi dos años en este mismo blog, tiene hoy una importancia especial: los servidores a los que se refiere son de los mas importantes que podemos tener en internet (aunque muchos ni sepan que existen): los servidores de
DNS.
Qué es DNS?
(leer esta sección solo si hay un interés real en la introducción básica al problema, la pueden ignorar para
ir directamente a los trolls)
DNS es un protocolo de Internet que permite entre muchas otras cosas transformar un nombre de dominio como
www.google.com, que es algo que un ser humano maneja con relativa facilidad, a algo manejable por una computadora: un número bastante grande conocido como dirección IP (que muchos conocen en su versión amigable a humanos como los 4 numeritos separados por puntos). Otra de las funciones fundamentales de DNS es la de publicar qué servidor va a recibir los correos electrónicos que enviamos.
Esto hace que los servidores de DNS sean blanco frecuente de ataques; ya que quien logra traerse abajo un servidor de DNS, puede desaparecer de Internet a una empresa, o a todo internet para un grupo de usuarios. Por otro lado, quien logra manipular un servidor de DNS tiene carta abierta para ataques de
phishing, robo de información, etc.
Ahora vamos a profundizar un poco mas en la arquitectura de DNS (que puede ser una de las mas complejas que hay asi que no nos complicaremos mucho). Existen básicamente dos tipos de servidores de DNS: los servidores de DNS per-se, que tienen autoridad sobre la información de algún dominio, y los resolvers, también conocidos como servidores de
cache. Veamos un gráfico del
documento que define el standard de como debe funcionar DNS.
Local Host | Foreign
|
+---------+ +----------+ | +--------+
| | user queries | |queries | | |
| User |-------------->| |---------|->|Foreign |
| Program | | Resolver | | | Name |
| |<--------------| |<--------|--| Server |
| | user responses| |responses| | |
+---------+ +----------+ | +--------+
| A |
cache additions | | references |
V | |
+----------+ |
| cache | |
+----------+ |
Cuando un cliente, como un navegador de internet, necesita resolver un nombre de dominio, se conecta a un Resolver Server, no directamente a un servidor de DNS. Esta distinción se ha perdido ya que la implementación de-facto de DNS,
ISC BIND, permite manejar tanto el resolver como el name server con el mismo programa: el viejo y querido named. Esto quiere decir que cuando configuran los servidores de DNS para conectarse a Internet en sus computadoras de escritorio, lo que en verdad están configurando son los resolvers.
Uno de los puntos flojos en este esquema es el mecanismo en el que el Name Server envía la información al Resolver para que este la almacene en el cache (que es un almacenamiento temporal para evitar preguntarle la misma información al Name Server una y otra vez). Los ataques que aprovechan esta debilidad se conocen como
Envenenamiento de cache de DNS. Cuando un atacante logra envenenar el cache de un resolver, logra tener el control de las peticiones de los usuarios a este resolver, sin necesidad de haber comprometido el servidor de nombres principal.
Cuál es la vulnerabilidad de DNS?
Hace 5 días, el 8 de julio, sucedió algo que
no se había visto en la industria de la seguridad informática: publicación masiva de actualizaciones de seguridad para los principales servidores de DNS:
ISC BIND,
Microsoft Windows Domain Name System,
Cisco, etc. En el
VU de CERT se explica a grandes rasgos la vulnerabilidad y da una lista de sistemas afectados.
NO HAY DETALLES PÚBLICOS SOBRE LA VULNERABILIDAD. Pero si sabemos que existe, y ha sido
confirmada hasta por los mas escépticos. Esto es algo serio. MUY serio. Tan serio que estoy sentado a las 4:30am escribiendo esto luego de haber pasado 3 días en los que he dormido en total 5 horas (por otros temas, el punto es que debería dormir en vez de escribir este artículo). Los vectores de ataque son conocidos, los
paliativos y
soluciones también, desde hace muchos años. Ataques de cache de dns han
existido con anterioridad, pero el elevado ratio de éxito de este nuevo ataque y sobre todo la portabilidad que tiene, hace que sea una de las amenazas mas serias que ha tenido Internet como un todo desde hace muchos años.
Afortunadamente,
Dan Kaminski, el investigador de seguridad que descubrió el problema, ha dado un mes de plazo desde la fecha de publicación de los parches para esta vulnerabilidad (Julio 8), hasta la publicación de los detalles para realizar el ataque el 7 de Agosto en una conocida
conferencia de seguridad. Asi que los hostmasters (los administradores de los servidores de DNS), tienen tiempo para actualizar sus servidores (asumiendo que en el transcurso de estos días nadie descubra la vulnerabilidad y publique un
0day).
Y los hostmasters responsables ya están actualizando los servidores.
Pero en Perú la cosa no va tan bien.
Qué pasa en Perú?
Habiendo pasado ya una semana de la publicación de los parches de la vulnerabilidad, decidí hacer algunas pruebas sobre los principales servidores de DNS peruanos. Los resultados son bastante preocupantes.
(ver
tabla en formato original)
Como se puede ver, los servidores de DNS mas usados del país no han sido parchados luego de la primera de las cuatro semanas de plazo que hay para hacerlo. Es en este momento en que quiero hacer un comentario personal.
Si bien se ha dado un mes de plazo para parchar los servidores, hay un detalle: toda, TODA la comunidad de seguridad informática tiene los ojos puestos en esta vulnerabilidad, los buenos y los malos. Hay mucha gente dedicada en este momento a encontrar el problema para poder hacer una utilidad que lo aproveche. Posiblemente esta utilidad ya exista, pero no se hace pública aún. El riesgo en este momento es que los administradores se confíen en el mes de plazo y en este lapso de tiempo se publique una utilidad que explote la vulnerabilidad. Si esto sucede y los servidores siguen sin estar parchados, las consecuencias podrían ser
CATASTRÓFICAS. Y quisiera decir que estoy hablando en sentido figurado, pero esto es SERIO,
MUY SERIO.
Ahora, se que hay limitaciones técnicas para no actualizar: complejidad en la red de servidores DNS, dependencias, pérdida temporal de servicio para los clientes, y en el caso específico de este parche, modificaciones en los firewalls que están delante de los DNSs. Si bien estas limitaciones son técnicas y perfectamente entendibles, YA VA UNA SEMANA y el riesgo es demasiado alto como para dormirse.
Debido a que este problema es serio, voy a hacer todo lo posible por actualizar este cuadro diariamente hasta el día de la publicación detallada de la vulnerabilidad (agosto 7). Asi que espero que para ese día (idealmente mañana mismo!) todas las entradas esten en verde.
You are doing it wrong
Otro punto preocupante, es el desconocimiento básico de fundamentos de seguridad por parte de muchas instituciones que aparecen en la lista. Voy a decir algo muy sencillo que hasta un MCSE va a entender:
Si tienen un Name Server autoritativo, este NO DEBE FUNCIONAR COMO RESOLVER.Si usan BIND, limiten allow-recursion con un acl. Si usan servidores DNS windows formatéenlos, instalen un sistema operativo de verdad (nos gusta FreeBSD en el server room) y compren un libro de BIND (o entren en la mente de djb ). Pero por favor, nunca, nunca, NUNCA dejen que su servidor autoritativo permita recursion. Y si no me creen a mí, por favor, créanle a D.J. Bernstein.
TIP OF THE DAY (o como evitar los espantosos DNSs de speedy.com.pe): Si han leido este artículo en su totalidad, habrán notado algo en el párrafo anterior: pueden usar cualquier servidor que aparezca en la tabla con color rojo o verde como "servidor de DNS" en sus equipos, ya que estan funcionando como resolvers. Así que si no desean usar los lentísimos DNSs de speedy, o piensan como ya estoy empezando a pensar que el maravilloso
OpenDNS es MALIGNO, pueden usar los DNSs de bancos o de diarios importantes, al menos hasta que sus administradores aprendan a configurar sus servidores ;).
CONCLUSION
El problema es MUY SERIO y nos afecta A TODOS. En este momento mi principal preocupación es que se publique una utilidad que explote esta vulnerabilidad antes que termine el periodo de gracia y coja a muchos servidores (y por ende a sus usuarios!) sin estar actualizados. Mi segunda preocupación es que lleguemos al final del periodo de gracia y debido a falta de información o capacidad técnica, hayan todavía servidores sin actualizar. Esto sería una total irresponsabilidad, por lo que iré actualizando esta tabla con la mayor frecuencia posible. Si desean que aumente algún otro servidor a la lista de análisis, mencionenlo en los comentarios.
Update: Dan Kaminski da una explicación sencillísima del problema con la ayuda de su asistente.
FAQ (actualizado 20080720)
Actualicé mi BIND al último parche, pero sigo vulnerable. Por qué?El parche consiste en hacer que el puerto de origen de las respuestas del servidor sea aleatorio y con una entropía alta. En la mayoría de casos he visto que tienen la opción "query-source" activada, fijando el origen al puerto 53, efectivamente
ANULANDO EL PARCHE. Otro problema es que si se reduce el uso de puertos disponibles para el origen, se reduce también la entropía, la opción que tienen que verificar para esto es "avoid-v4-udp-ports".
Otra opción es que sea su firewall el que este haciendo esto, verifiquen sus reglas.
Desde mi red la entropía de los puertos de origen es alta, pero por Internet es bajísima, qué pasa?Posiblemente la salida de tus DNSs sea por un NAT en un firewall cisco/checkpoint/nokia/etc, que van incrementando secuencialmente los puertos de origan al hacer NAT (y asi venden seguridad... *sigh*). Reemplacen sus firewalls por equipos OpenBSD/FreeBSD con PF o en todo caso Linux con netfilter que si hacen esto (en BSD out of the box, en Linux con un poco de configuración). Otra opción es consultar con su vendor como habilitar la randomización de puertos de origen con entropía alta. Otra es darles IPs públicas a los DNSs para que no salgan por NAT. Si ninguna de estas es una opción válida, pues esperen a la andanada de script kiddies de agosto :)
Ojo: Checkpoint los protege si han pagado la suscripción de SmartDefense. Si _no_ la tienen, su equipo Checkpoint genera UDP source secuenciales (anulando los parches de sus servidores de DNS) Esta es una _excelente_ manera de Checkpoint para hacer que los clientes se suscriban :)
