Los especialistas encontraron la primera prueba conocida de que los atacantes están utilizando el control de acceso basado en roles (RBAC) de Kubernetes (K8) en el campo para construir puertas traseras.. Los actores maliciosos también implementaron DaemonSets para tomar el control de los clústeres de K8 que atacaron y robar sus recursos. Un servidor API configurado incorrectamente que permitía consultas no autenticadas de usuarios anónimos con privilegios fue el punto de entrada que permitió adquirir el primer acceso. El atacante emitió algunas consultas HTTP para enumerar secretos y luego realizó dos llamadas API para obtener información sobre el clúster al enumerar las entidades en el espacio de nombres ‘kube-system’. Estas solicitudes permitieron al atacante descubrir información sobre el clúster. Después de eso, el adversario buscó un despliegue con el nombre ‘kube-controller’ para determinar si se había llevado a cabo un ataque previamente o no en este clúster en particular.
Además, el atacante intentó eliminar varias implementaciones ya existentes de espacios de nombres como “api-proxy”, “worker-deployment”, “kube-secure-fhgxtsjh” y “kube-secure-fhgxt”. Para maximizar la cantidad de CPU disponible y reducir la probabilidad de ser encontrado si el servidor estaba lleno, suponemos que el atacante estaba deteniendo campañas más antiguas o campañas rivales.
Cuando el atacante empleó RBAC para adquirir persistencia, ese fue el componente más fascinante de este ataque. El atacante estableció un ClusterRole adicional con poderes casi administrativos. Debido a que era un rol de clúster, no estaba restringido a ningún espacio de nombres en particular. Después de eso, el adversario estableció una ‘cuenta de servicio’ con el nombre ‘controlador kube’ en el espacio de nombres ‘sistema kube’. En el último paso de su ataque, el actor malintencionado creó un ‘ClusterRoleBinding’, que vinculó el ClusterRole a la cuenta de servicio para proporcionar un estado persistente que fuera sólido y encubierto.
En esta etapa, el atacante ha generado persistencia que permite la explotación continua del clúster. Esto es así incluso en el caso de que se bloquee el acceso de usuarios anónimos. Además, adjuntar la función de “administrador de clúster” a un usuario nuevo o cuestionable puede activar alertas; sin embargo, el adversario ideó una técnica astuta para combinarse a la perfección con los registros de auditoría de la API. Esto se logró mediante la creación de un enfoque creativo para mezclarse. Al final, el atacante podría pasar desapercibido sin activar ninguna advertencia configurando el ClusterRoleBinding para acceder a “system:controller:kube-controller”. Este enlace parece ser completamente aceptable.
Después de eso, el actor malicioso construyó un DaemonSet para distribuir contenedores en todos los nodos usando una sola llamada a la API. La imagen del contenedor conocida como ‘kuberntesio/kube-controller:1.0.1’ se incluyó en el objeto de solicitud de formación DaemonSet. Esta imagen se almacenó en el registro público conocido como Docker Hub.
La imagen del contenedor con el nombre “kuberntesio/kube-controller” es un ejemplo de error tipográfico que intenta suplantar la cuenta real “kubernetesio”. A pesar de que solo tiene unas pocas docenas de imágenes de contenedores, ha acumulado millones de tirones. La imagen también imita la conocida imagen de contenedor ‘kube-controller-manager’, que es una parte esencial del plano de control. Es una imagen de contenedor que opera dentro de un pod en cada nodo maestro y es responsable de determinar cuándo un nodo ha fallado y tomar las medidas adecuadas en respuesta a esa falla. Es un componente de K8s de uso frecuente que debería existir en el clúster y tiene el potencial de engañar a las personas haciéndoles creer que es una implementación válida en lugar de un criptominero. Esto se debe a que debería existir en el clúster. Porque está destinado a funcionar de manera incesante,
Este nuevo ataque de K8 se conoce como RBAC Buster. Su propósito es explotar los servidores API de K8 para construir un ClusterRoleBinding y adquirir acceso completo al clúster con persistencia después de que se solucione la configuración incorrecta.
Entusiasta de la seguridad cibernética. Especialista en seguridad de la información, actualmente trabajando como especialista en infraestructura de riesgos e investigador.
Experiencia en procesos de riesgo y control, soporte de auditoría de seguridad, diseño y soporte de COB (continuidad del negocio), gestión de grupos de trabajo y estándares de seguridad de la información.
Envía tips de noticias a info@noticiasseguridad.com o www.instagram.com/iicsorg/.
También puedes encontrarnos en Telegram www.t.me/noticiasciberseguridad
