La protección contra amenazas de Azure Security Center permite detectar y prevenir las amenazas en una amplia variedad de servicios, que abarcan desde el nivel de Infraestructura como servicio (IaaS) hasta los recursos de la Plataforma como servicio (PaaS) en Azure, como IoT, App Service y las máquinas virtuales locales.

En Ignite 2019 anunciamos nuevas funcionalidades de protección contra amenazas para contrarrestar amenazas sofisticadas en plataformas en la nube, incluida la vista previa de la protección contra amenazas para el soporte técnico de Azure Kubernetes Service (AKS) en Security Center y la vista previa de la evaluación de vulnerabilidad de las imágenes de Azure Container Registry (ACR).

Clústeres de Kubernetes y Azure Security Center 

En este blog, describiremos un ataque de minería de criptodivisa a gran escala reciente contra los clústeres de Kubernetes detectado hace poco por Azure Security Center. Este es uno de los muchos ejemplos de cómo puede ayudarle Azure Security Center a proteger sus clústeres de Kubernetes contra amenazas.

Los ataques de minería criptográfica en entornos en contenedor no son nuevos. En Azure Security Center, detectamos periódicamente una amplia gama de actividades de minería que se ejecutan dentro de contenedores. Normalmente, esas actividades se ejecutan dentro de contenedores vulnerables, como aplicaciones web, con vulnerabilidades conocidas que se aprovechan.

Recientemente, Azure Security Center detectó una nueva campaña de minería criptográfica que tiene como destino concretamente entornos de Kubernetes. Lo que diferencia este ataque de otros ataques de minería criptográfica es su escala: en solo dos horas, se implementó un contenedor malintencionado en decenas de clústeres de Kubernetes.

Los contenedores ejecutaron una imagen desde un repositorio público: kannix/monero-miner. Esta imagen ejecuta XMRig, un extractor Monero de código abierto muy popular.

Las telemetrías mostraron que el contenedor se implementó por medio de una implementación de Kubernetes llamada kube-control.

Como puede mostrarse en la configuración de implementación siguiente, la implementación, en este caso, garantiza que se ejecutarían 10 réplicas del pod en cada clúster:

Además, el mismo actor que implementó los contenedores de minería criptográfica también enumeró los recursos del clúster, incluidos los secretos de Kubernetes. Esto podría provocar la exposición de cadenas de conexión, contraseñas y otros secretos que podrían habilitar el movimiento lateral.

Lo interesante es que la identidad de esta actividad es system:serviceaccount:kube-system:kubernetes-dashboard, que es la cuenta de servicio del panel.
Este hecho indica que el panel de Kubernetes implementó el contenedor malintencionado. La cuenta de servicio del panel también inició la enumeración de recursos.

Hay tres opciones para la forma en que un atacante puede aprovechar el panel de Kubernetes:

1. Panel expuesto: El propietario del clúster expuso el panel a Internet y el atacante lo encontró mediante un análisis.
2. El atacante obtuvo acceso a un solo contenedor del clúster y usó la red interna del clúster para tener acceso al panel (que es posible con el comportamiento predeterminado de Kubernetes).
3. Desplazamiento legítimo al panel mediante las credenciales del clúster o de la nube.

La pregunta es cuál de las tres opciones anteriores estaba implicada en este ataque. Para responder a esta pregunta, podemos usar una sugerencia proporcionada por Azure Security Center, las alertas de seguridad sobre la exposición del panel de Kubernetes. Alertas de Azure Security Center cuando el panel de Kubernetes se expone a Internet. El hecho de que esta alerta de seguridad se desencadenara en algunos de los clústeres atacados implica que el vector de acceso aquí es un panel expuesto a Internet.

Una representación de este ataque en la matriz de ataque de Kubernetes tendría un aspecto similar al siguiente:

Evitación de los ataques de minería de criptodivisa

¿Cómo se puede evitar esto?

1. No exponga el panel de Kubernetes a Internet: exponer el panel a Internet significa exponer una interfaz de administración.
2. Aplique RBAC en el clúster: cuando se habilita RBAC, la cuenta de servicio del panel tiene permisos muy limitados de forma predeterminada, lo que no permitirá ninguna funcionalidad, incluida la implementación de nuevos contenedores.
3. Conceda solo los permisos necesarios a las cuentas de servicio: Si se usa el panel, asegúrese de aplicar solo los permisos necesarios a la cuenta de servicio del panel. Por ejemplo, si el panel se usa solo con fines de supervisión, conceda solo los permisos "get" a la cuenta de servicio.
4. Permita solo imágenes que sean de confianza: imponga la implementación solo de contenedores que sean de confianza, desde registros de confianza.

Más información

Kubernetes se está convirtiendo rápidamente en el nuevo estándar para la implementación y la administración de software en la nube. Pocas personas tienen una amplia experiencia con Kubernetes y muchas solo se centran en aspectos generales de ingeniería y administración, mientras pasan por alto la seguridad. Un entorno de Kubernetes debe configurarse cautelosamente para que sea seguro, con cuidado de no dejar abierta ninguna puerta que deje una superficie expuesta a ataques específicos para contenedores. Azure Security Center proporciona:

1. Detección y visibilidad: detección continua de instancias administradas de AKS en suscripciones registradas de Security Center.
2. Recomendaciones de la puntuación segura: elementos que permiten a los clientes tomar medidas con el fin de cumplir los procedimientos recomendados de seguridad en AKS como parte de la puntuación segura del cliente; por ejemplo, "Debe usarse control de acceso basado en rol para restringir el acceso a un clúster de Kubernetes Service".
3. Detección de amenazas: análisis basado en el clúster y en el host; por ejemplo, “Se ha detectado un contenedor con privilegios”.

Si desea obtener más información acerca del soporte técnico de AKS en Azure Security Center, visite la documentación aquí.