Kubernetes muestra debilidad incorporada



Una presentación de Shmoocon señala varias debilidades integradas en las configuraciones de Kubernetes y cómo un investigador puede explotarlas.

Los contenedores, procesos únicos virtualizados en entornos aislados, se están convirtiendo en partes importantes de la infraestructura de TI en muchas empresas, especialmente aquellas que adoptan DevOps o metodologías de implementación continua. Y Kubernetes, un sistema de código abierto para automatizar la implementación y administración de contenedores, está siendo adoptado por un número creciente de compañías que usan contenedores. Así que, naturalmente, probar y mejorar la seguridad de Kubernetes se ha convertido en un tema importante para los profesionales de la seguridad.

En la reciente ShmooCon en Washington, DC, Mark Manning, director técnico del Grupo NCC, hizo una presentación sobre Kubernetes para los probadores de penetración, una presentación en la que examinó las vulnerabilidades del sistema y las herramientas disponibles para probarlos. Al explicar por qué cree que el tema es importante, dice que las razones se reducen a números.

«El ochenta y cinco por ciento de los clientes definitivamente están implementando contenedores o planean hacerlo, en lo más común que veo», dice Manning. «Creo que es bastante seguro decir que con Fortune 500, la mitad de ellos están usando contenedores en la producción».

Peligros incorporados
En su presentación, Manning comenzó a analizar las vulnerabilidades con las que surgen a través de la configuración de Kubernetes, algo que, según él, es la raíz de muchos peligros.

«Creo que iría tan lejos como para decir que, de manera predeterminada, en realidad es una plataforma insegura», dice Manning. «Y si tomó solo el código de Kubernetes y lo implementó en su propio entorno, los valores predeterminados que se proporcionan crean muchas vulnerabilidades de seguridad en sí mismas». Ese riesgo, dice, es la razón por la cual tantas compañías han abandonado la plan de implementar Kubernetes en sus propios servidores y ahora usan proveedores de servicios en la nube para sus plataformas de Kubernetes.

Uno de los problemas que enfrentan las empresas con las configuraciones, dice Manning, es que hay muchas maneras de hacerlo mal. Y esa gran variedad de posibles problemas informa la forma en que Manning aborda las pruebas de seguridad en las implementaciones de Kubernetes.

Divide y prueba
«La forma en que hacemos evaluaciones es que veremos la aplicación por separado de la infraestructura», dice Manning. Como parte de ese proceso, dice que las pruebas y evaluaciones de aplicaciones son las mismas que se realizan en cualquier plataforma. El código fuente se evalúa en busca de vulnerabilidades y errores, todos los cuales se informan al cliente para su reparación. Luego viene la evaluación de Kubernetes.

En su presentación, Manning describió un proceso para configurar «pods de ataque» (un pod es una colección de contenedores) utilizando herramientas estándar de Kubernetes como kuberctl (una interfaz de línea de manage para Kubernetes) y cURL (una interfaz para acceder a la API) solo componentes de Kubernetes). Su equipo también utilizará herramientas de evaluación de seguridad estándar como metasploit, dirigidas a un objetivo de Kubernetes. El punto de hacer toda esta creación y «enroscar» los componentes es que un ataque exitoso podría permitir que alguien obtenga acceso a múltiples contenedores dentro del pod, violando la separación que se supone que protege cada aplicación.

«Comenzamos dentro de un contenedor y hacemos lo que llamamos &#39evaluaciones de ruptura&#39 que validarán si la tecnología del contenedor es efectiva o no para aislar a un atacante para que solo pueda afectar esta aplicación», explica Manning. Y en un despliegue de Kubernetes, esa tecnología de separación podría haberse debilitado intencionalmente.

Encontrar debilidad por diseño
«Kubernetes está haciendo elecciones activamente diseñadas para acelerar las cosas con un mayor rendimiento y hacer que las cosas funcionen más fácilmente, a costa de la seguridad», dice Manning. Contrasta esto con Docker, que emplea tecnología equivalent a la utilizada en el entorno limitado del navegador Google Chrome para mantener la separación y la seguridad.

En el caso de Kubernetes, explica, la seguridad se ha debilitado intencionalmente para facilitar a los administradores la creación y administración rápida de contenedores y pods. Es parte de un patrón que Manning dice que ha visto en otros productos, en el que están hechos con muchas funciones y son fáciles de usar, con la esperanza de que la seguridad se aplique de alguna manera más adelante.

Los principales benefactores criminales de todo esto, dice Manning, son criptomineros a quienes les encanta encontrar vainas desprotegidas. Y no tienen que investigar o usar exploits de día cero para hacerlo. «A lo largo de toda esta presentación, no estoy hablando de días cero o CVE o exploits como ese. Estoy hablando de configuraciones erróneas porque eso es lo que ha estado funcionando en todas estas evaluaciones», dice Manning.

Contenido relacionado:

Curtis Franklin Jr. es editor sénior en Darkish Reading through. En este puesto, se centra en la cobertura de productos y tecnología para la publicación. Además, trabaja en programación de audio y video para Dim Reading through y contribuye a actividades en Interop ITX, Black Hat, INsecurity y … Ver biografía completa

Más ideas





Enlace a la noticia unique