ClickCease Ya están aquí los parches KernelCare para SAD DNS - TuxCare

Únase a nuestro popular boletín

Únase a más de 4.500 profesionales de Linux y el código abierto.

2 veces al mes. Sin spam.

Ya están aquí los parches KernelCare para SAD DNS

18 de noviembre de 2020 - Equipo de RRPP de TuxCare

Los parches KernelCare para SAD DNS están en caminoSad DNS (Side-channel AttackeD DNS) es una vulnerabilidad que fue revelada por académicos de la Universidad de California y la Universidad de Tsinghua, en la Conferencia ACM sobre Seguridad Informática y de las Comunicaciones CCS 2020. La vulnerabilidad se asignó a CVE-2020-25705. Afecta a distribuciones a partir de la 7ª v.o. (es decir, RHEL6 no está afectada, ya que su kernel aún no incluye la función de estrangulamiento de respuestas ICMP). Los parches KernelCare se publicarán en breve. El nuevo descubrimiento académico permite a un actor malicioso envenenar la caché de un servidor DNS y redirigir así potencialmente el tráfico de los usuarios a sitios o servicios que alojan contenidos no deseados o peligrosos. 


Contenido:

  1. Cómo funciona Sad DNS
  2. Mitigación de DNS tristes
  3. La causa principal
  4. Calendario de publicación de parches de KernelCare

 

Cómo funciona Sad DNS

Cómo funciona Sad DNS

El envenenamiento de la caché DNS fue descubierto por primera vez en 2008 por un investigador de seguridad Dan Kaminsky. Como la mayoría de los administradores saben, el Sistema de Nombres de Dominio (DNS) es un componente fundamental de Internet. Cuando un usuario teclea un dominio en su navegador, éste realiza una consulta a un servidor DNS para determinar la dirección IP que se corresponde con el nombre de dominio. 

 

La mayoría de las consultas DNS utilizan UDP, que es un protocolo sin estado que no requiere autenticación ni handshake. Las consultas DNS que utilizan UDP sólo requieren una dirección de origen (la máquina del usuario) y un par de puertos (origen y destino). Al no requerir autenticación, cualquiera puede consultar a un servidor DNS la dirección IP asociada a cualquier dominio registrado.

 

UDP se ejecuta en la capa de transporte del modelo OSI, pero los diseñadores incorporaron entropía a las consultas DNS para añadir algún tipo de seguridad. Las consultas incorporan un ID de transacción aleatorio que debe ser el mismo en la consulta y en la respuesta. La aleatorización de este valor hace menos probable la falsificación de solicitudes debido a su entropía. Sin embargo, el ID de la consulta es de sólo 16 bits, lo que significa que se necesitan menos de 100.000 "conjeturas" antes de que un atacante pueda forzar una coincidencia. Con la potencia de cálculo actual, los ataques de fuerza bruta con sólo 100.000 posibilidades pueden ejecutarse en pocos segundos.

 

Como Internet es tan grande, los resolvers DNS se utilizan para centralizar las consultas a los servidores autoritativos y distribuir las IPs de los dominios a las peticiones de los clientes. Cuando un servidor DNS recursivo consulta a un servidor autorizado, normalmente se utiliza el puerto 53 para enviar y recibir mensajes. Como el puerto ya es conocido, un atacante sólo necesita el ID de consulta de 16 bits. En un ataque de envenenamiento de caché, un atacante inunda el servidor recursivo con respuestas que contienen todos los ~65.000 ID posibles. Si el servidor DNS recursivo recibe la respuesta del atacante antes que la respuesta del servidor autoritativo, la caché DNS del dominio de destino queda envenenada. Como no se produce autenticación ni handshake, el resolver acepta la respuesta del atacante sin preguntar y la IP maliciosa resuelve para un dominio objetivo. 

 

Cuando un atacante envenena la caché del servidor recursivo DNS, cualquier usuario que consulte el dominio obtendrá la dirección IP asignada por el atacante para el dominio en cuestión. Esto significa que el usuario será dirigido a un servidor controlado por el atacante. El contenido que se muestra al usuario suele ser un sitio de phishing que tiene el mismo aspecto que el dominio legítimo. Mediante este ataque, un atacante puede robar credenciales, datos financieros y archivos potencialmente confidenciales si se engaña a los usuarios para que carguen el contenido.

 

Para combatir este problema, los resolvedores DNS utilizan puertos aleatorios. Esto significa que el atacante no sólo tendría que adivinar el ID de la consulta, sino también el puerto, lo que hace inviable el ataque. Se han incluido otras medidas de seguridad en la arquitectura DNS, como el uso de TCP en lugar de UDP y la incorporación de DNSSec al proceso. DNSSec requiere una firma con el mensaje de consulta, pero el protocolo aún está en pañales y no se ha adoptado universalmente.

 

Los tristes ataques DNS superan la aleatorización de puertos utilizando mensajes de error del Protocolo de Mensajes de Control de Internet (ICMP). Cuando un puerto está cerrado, una petición ICMP devuelve un mensaje de error "puerto inalcanzable". Utilizando este protocolo y un escaneo de los puertos cerrados, un atacante puede deducir qué puertos están abiertos a las respuestas DNS. Al reducir las "conjeturas" a un número limitado de puertos e identificadores de consulta, un atacante sólo necesita forzar unas cien mil respuestas. Este ataque no siempre es posible, ya que algunos resolvers utilizan sockets UDP conectados en lugar de sockets abiertos. Con un socket conectado, ambos servidores DNS están "atados" como pares utilizando el sistema operativo.

 

Algunos servidores utilizan la limitación de velocidad para detener la inundación de puertos ICMP de ataques de reflexión. Aunque esta defensa funciona contra la denegación de servicio (DoS) en servidores DNS, puede ser aprovechada en un ataque Sad DNS. Cuando se limitan las respuestas ICMP, un servidor no responde con un mensaje de error cuando se alcanza el límite de velocidad. Los atacantes inundan el servidor objetivo con suficientes mensajes ICMP para alcanzar el límite de tasa y luego determinar qué puertos están abiertos, eliminando el número de conjeturas en un ataque de fuerza bruta.

 

Para realizar un ataque Sad DNS, el atacante necesita:

 

  • Un sistema capaz de realizar consultas DNS contra un servidor DNS vulnerable.
  • La capacidad de recibir respuestas ICMP de dicho servidor DNS

 

 

Mitigación de DNS tristes

Mitigación de DNS tristes

Los ataques Sad DNS requieren varias condiciones preexistentes para ser explotados con éxito, por lo que las mitigaciones añaden una condición adicional que hace que el ataque sea inviable. Añadir cualquiera de las siguientes estrategias al proceso DNS hará que los ataques Sad DNS sean inviables para un atacante:

 

  • Configurar DNSSec, pero la adopción generalizada de este protocolo ha sido lenta.
  • No permitir respuestas ICMP. Esto tiene posibles efectos secundarios, ya que este tráfico se utiliza legítimamente para otros fines, como la supervisión.
  • Aplicar un parche al kernel para solucionar la causa raíz del problema, evitando así la identificación de los puertos utilizados. KernelCare está trabajando actualmente en los parches para CloudLinux7. Los parches para otras distribuciones compatibles se publicarán en breve.

 

 

La causa principal

La causa principal

Los tristes ataques DNS son posibles debido al límite predecible de la tasa de respuesta ICMP definido por el núcleo del servidor DNS. Al tener un número fijo de respuestas ICMP máximas por segundo, un atacante puede deducir qué puertos se están utilizando en la comunicación DNS y enviar paquetes especialmente diseñados a esos puertos. Otros sistemas operativos también se ven afectados por este problema, teniendo también límites diferentes pero fijos.

 

En teoría, es posible que Sad DNS sea sólo una de las múltiples vulnerabilidades utilizadas para explotar la ineficiente aleatorización de puertos ICMP. Otros servicios pueden ser vulnerables a ataques similares, pero hasta ahora no se han revelado otros. Parchear el kernel puede ayudar a protegerse en el futuro contra vulnerabilidades desconocidas.

A parche sobre Sad DNS para el kernel de Linux, y los proveedores de Linux están publicando las correcciones adecuadas para sus distribuciones, entre ellas Redhat, Debian, Suse, Ubuntu. El inconveniente de la aplicación de parches mediante software suministrado por el proveedor es el reinicio necesario para completar el proceso. Con KernelCare, los administradores pueden parchear en tiempo real sus servidores sin reiniciar y corregir Sad DNS y cualquier vulnerabilidad futura que afecte al protocolo ICMP y a los exploits de límite de velocidad.

 

 

Calendario de publicación de parches de KernelCare

Publicado el 23 de noviembre:

  • CloudLinux 6 Híbrido,
  • CloudLinux 7, 
  • Oracle Enterprise Linux 7,
  • RHEL 7,
  • CentOS 7,
  • CentOS 7 Plus

Los parches se aplicarán automáticamente en el plazo de 4 horas sin necesidad de reiniciar el sistema. Para actualizar manualmente, ejecute:

/usr/bin/kcarectl --actualizar

Previsto para la Semana nº 48:

  • Parches de Ubuntu
  • Parches de Debian

Previsto para la Semana nº 49:

  • Amazon Linux

Permanezca atento a las actualizaciones.

¿Desea automatizar la aplicación de parches de vulnerabilidad sin reiniciar el núcleo, dejar el sistema fuera de servicio o programar ventanas de mantenimiento?

Más información sobre Live Patching con TuxCare

Conviértete en escritor invitado de TuxCare

Empezar

Correo

Únete a

4,500

Profesionales de Linux y código abierto

Suscríbase a
nuestro boletín