Hace unos días se github reveló una vulnerabilidad que podría permitir un ataque de hombre en el medio contra los grupos de Kubernetes, CVE-2020-10749 . Esta vulnerabilidad no se encuentra en Kubernetes, sino en ciertas implementaciones de redes de contenedores: los clústeres solo IPv4 que usan implementaciones afectadas son vulnerables.

La vulnerabilidad permite ataques de hombre en el medio (MITM), donde un atacante puede interceptar el tráfico de red a un pod en un clúster de Kubernetes y suplantarlo a los clientes.

Cómo funciona

Para comprender esta vulnerabilidad, aquí hay algunos antecedentes relevantes:

  • Anuncios de enrutador: un componente del protocolo de descubrimiento vecino para IPv6 (especificado en RFC 4861 ), los anuncios de enrutador son un tipo de mensaje transmitido por enrutadores para anunciar su presencia; esencialmente, un mensaje de anuncio de enrutador informa a los destinatarios que existe un enrutador IPv6, en la dirección especificada en el mensaje, que puede enrutar cierto tráfico IPv6.
  • CAP_NET_RAW: CAP_NET_RAWes una poderosa capacidad de Linux que permite que los procesos con ella forjen cualquier tipo de paquete o se vinculen a cualquier dirección. Es importante destacar que los contenedores con la CAP_NET_RAWcapacidad pueden enviar anuncios de enrutadores IPv6.
  • Preferencia del cliente para IPv6 frente a IPv4: en un clúster solo IPv4, no se puede acceder a los contenedores a través de las direcciones IPv6. Sin embargo, si el DNS para el clúster devuelve registros IPv4 ( A ) e IPv6 ( AAAA ), muchos clientes probarán preferentemente la dirección IPv6 y recurrirán a la dirección IPv4.

Con este contexto, así es como funciona un exploit de CVE-2020-10749. Considere un clúster solo de IPv4, donde nunca se han enrutado direcciones IPv6. Si un atacante obtiene acceso a uno de sus pods, que tiene CAP_NET_RAW, puede enviar anuncios de enrutador IPv6 “corruptos”, que afirman que el pod del atacante es un enrutador IPv6 que sabe cómo resolver todas las direcciones IPv6. Las implementaciones de redes de contenedores vulnerables ahora enviarán todo el tráfico para el que DNS devuelve un registro IPv6 al pod del atacante, lo que le permite ver este tráfico y actuar con éxito como un intermediario, suplantando el servidor al cliente y al cliente. el servidor.

Además, una implementación específica en el clúster está expuesta a esta vulnerabilidad solo si acepta conexiones que no son TLS o conexiones TLS que no realizan la validación del certificado; el uso adecuado de TLS siempre frustrará los ataques de intermediarios desde la capa de red. Sin embargo, incluso si una implementación usa TLS correctamente, un atacante puede usar las mismas técnicas para realizar un ataque de denegación de servicio (DoS).

Cómo mitigar este problema

En este momento, aún no se ha lanzado una versión parcheada de kubelet: la fecha prevista es el 17 de junio. Los usuarios deben actualizar su versión de kubelet tan pronto como se lance el parche. Hasta entonces, puede mitigar la amenaza que representa esta vulnerabilidad mediante los siguientes pasos:

  1. Configure hosts para rechazar anuncios de enrutadores de forma predeterminada: esta configuración frustrará este ataque, pero puede interrumpir el tráfico legítimo. Sin embargo, es poco probable que se rompa el tráfico legítimo en un clúster solo IPv4. Para cambiar esta configuración, establezca el parámetro del kernel net.ipv6.conf.all.accept_raen 0 en sus hosts (para que esta configuración sea persistente, debe editarla /etc/sysctl.conf).
  2. Deshabilite CAP_NET_RAW en sus pods de forma predeterminada, habilitándolo solo para los pods que lo necesitan. Puede aplicar esta política (y eliminar las excepciones que necesita) utilizando políticas en la plataforma de seguridad StackRox Kubernetes.
  3. Utilice TLS con validación de certificado en sus solicitudes. Sin embargo, como ya se señaló, este paso no puede evitar los ataques DoS.
  4. Fortalezca su clúster y asegúrese de tener la visibilidad que necesita para detectar ataques. Para aprovechar esta vulnerabilidad, un atacante debe controlar uno de los pods en su clúster, lo que puede suceder si instala involuntariamente un pod malicioso, o si un atacante utiliza otros medios para obtener el control de uno de sus pods. 
¡Haz clic para puntuar esta entrada!
(Votos: 1 Promedio: 5)

compartir en ....
Avatar

Acerca de Brian Alexander Diaz

Brian Alexander Diaz Investigador en temas de seguridad y Devops Mi nombre es Brian Alexander Diaz. El objetivo de este blog es promover la cultura y mentalidad en seguridad por todo el Internet y que la gente aprenda a facilitar su vida y crear  sistemas mas seguros .

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *