¿Sigue siendo el error de Kaminsky un problema para sitios sin DNSSEC?

Kaminsky no es la primera persona en encontrar una vulnerabilidad de carga de caché de DNS. De hecho, se han encontrado muchas de estas vulnerabilidades y esa es la razón por la que DNSSEC es importante. DNSSEC es una estrategia de defensa en profundidad contra este patrón de ataque. Sin embargo, los proveedores de software responsables parchean las vulnerabilidades, y cuando encuentre un ataque de envenenamiento de caché de DNS en BIND, se solucionará inmediatamente .

  

¿Necesita usar DNSSEC en combinación con SSL / TLS para estar seguro?

En teoría, no. El punto entero de SSL / TLS (y la criptografía en general) es garantizar que hable con la persona adecuada (sin importar qué, incluso si el DNS está dañado).

Además, SSL / TLS es en su mayoría útil cuando su conexión puede ser fácilmente interceptada; en este caso, alguien no necesita meterse con DNS en absoluto. (La comunicación con DNS solo es útil si no tiene la respuesta de DNS correcta almacenada en la memoria caché; no importa lo que suceda con la conexión TCP)

Todavía es posible llegar (para idear) con un caso teórico como DNSSEC que sería necesario proteger:

1. un adversario no no tiene la capacidad de controlar completamente su conexión a Internet, y solo puede inyectar paquetes falsos (paquetes IP con una dirección IP de origen que no pertenece al adversario);
2. pero él conoce una debilidad de su resolución de DNS , y puede convencerlo de una declaración de DNS incorrecta (que bank.com resuelve mal.I.P.address);
3. bad.I.P.address le pertenece, y ejecuta un servidor web por encima de SSL / TLS allí (conocido como servidor HTTPS);
4. o bien: a) conoce una debilidad de su cliente SSL / TLS , de modo que puede convencer a su navegador de que el servidor SSL / TLS en bad.I.P.address realmente es "bank.com", o b) ha obtenido un certificado SSL / TLS para "bank.com" de una Autoridad de Certificación reconocida , por engaño (apareció en su escritorio que dice representar a "bank.com", por piratería ( conoce una debilidad en el proceso de verificación del certificado), por coacción (incluida la corrección legal), o por cualquier otro medio que pueda imaginar.

En este caso, DNSSEC aún te protegerá; sin DNSSEC, se conectaría con el usuario equivocado sin advertencias.

Es extremadamente improbable que alguien realice estos esfuerzos solo para obtener sus datos bancarios, ya que puede obtener tantos números de cuenta por medios técnicos (aparentemente, el fraude de pesca más infame aún funciona). a menos que su código de secreto bancario sea mucho más valioso que el código de secreto bancario promedio (quizás tenga mucho dinero y la capacidad de transferir cualquier cantidad a cualquier persona, solo con la contraseña de su cuenta bancaria normal, y no un paso adicional; una idea terrible) en cualquier caso).

Parece incluso menos probable que alguien se moleste con la intercepción de un número de tarjeta de crédito protegido por algún criptografía (cualquier criptografía) cuando obtiene mucho a la vez pirateando el sistema que los almacena (y Lo último que supe es que todavía pueden obtener muchos números a un precio razonable).

Pero SSL / TLS se usa para proteger algo mucho más crítico que los datos de pago: descargas de software . Muchos de los programas descargados, en particular las actualizaciones automáticas, solo son de confianza al ser descargados a través de un enlace "seguro" (el paquete de software no está firmado o la firma no se verifica automáticamente o el usuario, que no sabe que puede verificar la firma criptográfica del paquete, o incluso que debería haber una firma).

A menos que se ejecute en un entorno estrictamente segregado, el software descargado tiene la capacidad de leer no solo sus datos bancarios, sino todos sus archivos personales y cualquier información que envíe a través de enlaces SSL / TLS "seguros".

Defensas efectivas contra el ataque de Kaminsky. En riesgo de simplificarse en exceso, el ataque de Kaminsky se puede usar para atacar a clientes DNS que no usan la asignación aleatoria de puertos de origen. La defensa inmediata contra el ataque de Kaminsky es activar la aleatorización del puerto de origen. En estos días, la mayoría del software de DNS moderno realiza la asignación aleatoria de puertos de origen.

(Si no lo ha hecho desde hace tiempo, le recomiendo que actualice su software DNS, tanto en los clientes como en los servidores, para obtener los beneficios de esta defensa).

El estado actual. Afortunadamente, la mayoría de Internet ya ha actualizado su software de DNS a versiones más recientes que incorporan defensas contra el ataque de Kaminsky. Estas defensas hacen que el ataque de Kaminsky sea bastante difícil. (No son 100% imposibles, pero requerirían una gran cantidad de recursos: miles de millones de paquetes). Por lo tanto, es probable que la mayoría de los sitios en la actualidad estén razonablemente bien protegidos contra el ataque de Kaminsky. Por ejemplo, las probabilidades son muy buenas de que su ISP y su banco estén protegidos.

Si hay algún rezagado que no haya actualizado su software de DNS a una versión reciente que incorpore defensas contra el ataque de Kaminsky (por ejemplo, aleatorización de puertos de origen), es probable que sean muy vulnerables. El ataque de Kaminsky es bastante fácil de montar y altamente efectivo, si el servidor no incorpora defensas contra él.

¿Qué pasa con DNSSEC? DNSSEC es un acuerdo por separado. Está diseñado para brindar seguridad, incluso en situaciones en las que sus servidores DNS están comprometidos o cuando un interlocutor está atacando el tráfico de su red. Por lo tanto, en teoría, DNSSEC proporcionaría una defensa alternativa aceptable contra el ataque de Kaminsky.

Sin embargo, en la práctica, confiar en DNSSEC para protegerse del ataque de Kaminsky sería una mala idea. Hay dos problemas:

• Primero, DNSSEC no se implementa ampliamente hoy. Hoy en día, muy pocos dominios están firmados con DNSSEC. Esto hace que sea imposible implementar DNSSEC con una validación estricta. En cambio, en las implementaciones actuales de DNSSEC, si se recibe una respuesta para un dominio sin firmar, la respuesta se acepta sin realizar ninguna verificación criptográfica. Esto significa que un cliente que es vulnerable al ataque de Kaminsky aún puede ser atacado, incluso si usa DNSSEC.

• En segundo lugar, la aleatorización del puerto de origen es muy fácil de implementar, mientras que DNSSEC es más difícil (operacional y logísticamente) de implementar. Tendrías que estar loco para continuar usando las antiguas versiones vulnerables del software DNS. La implementación de la asignación aleatoria del puerto de origen es bastante fácil (solo actualice a la última versión de su software de DNS, en la mayoría de los casos), por lo que sería una locura no aprovechar la defensa de asignación aleatoria del puerto de origen.

DNSSEC sigue siendo una muy buena idea, y el ataque de Kaminsky subraya la importancia de implementar DNSSEC ampliamente. Entonces, no me malinterpretes. Le animo a habilitar DNSSEC en sus máquinas. Simplemente no lo vea como un sustituto de la aleatorización de puertos de origen.

En conclusión. Todos deberían usar la aleatorización de puertos de origen. Es una obviedad, y actualmente es la defensa más efectiva contra el ataque de Kaminsky. Afortunadamente, mi impresión es que la asignación aleatoria del puerto de origen ya se usa mucho, por lo que la mayoría de Internet debería estar razonablemente bien defendida contra el ataque de Kaminsky.

Teniendo una vista más larga, DNSSEC es importante porque brinda protecciones robustas contra una gran clase de posibles ataques contra DNS, incluso aquellos que no hemos pensado o no conocemos, pero que podrían descubrirse en el futuro. . Es el mejor profiláctico que tenemos, para prevenir proactivamente futuros incidentes como el ataque de Kaminsky. Por lo tanto, sería mejor que los operadores de red y otros hagan lo que puedan para implementar DNSSEC a toda velocidad.