Problema con la sincronización de git: Análisis de los defectos de inyección de comandos en Kubernetes
Resumen ejecutivo
El investigador de Akamai Tomer Peled descubrió un defecto de diseño en el proyecto adicional de Kubernetes git-sync que permite una posible inyección de comandos. Presentará estos resultados en DEF CON 2024.
Este defecto de diseño puede provocar la exfiltración de datos de cualquier archivo del pod (incluidos los tokens de la cuenta de servicio ) o la ejecución de comandos con privilegios de usuario de git-sync .
Para explotar el defecto, todo lo que un atacante necesita hacer es aplicar un archivo YAML en el clúster, que es una operación que requiere pocos privilegios.
Esta vulnerabilidad se puede explotar en las instalaciones predeterminadas de Kubernetes en todas las plataformas, incluidas Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE) y Linode.
En esta entrada del blog, proporcionamos un archivo YAML de prueba de concepto (PoC), así como demostraciones que muestran el impacto potencial.
Puesto que no se ha asignado una CVE a este defecto de diseño, no hay ningún parche para ella y se puede seguir explotando.
El equipo de Kubernetes nos ha animado a compartir esta investigación para concienciar sobre estos vectores de ataque.
Introducción
Kubernetes no es ajeno a las vulnerabilidades de inyección de comandos. Solo en 2023, se descubrieron 7 vulnerabilidades de este tipo, entre ellas varias que nosotros mismos detectamos.. Las preocupaciones por el saneamiento de los datos de entrada nos llevaron a examinar más a fondo los vectores de ataque auxiliares: ¿este vector de ataque es exclusivo del proyecto principal de Kubernetes o se extiende a otros proyectos? Hay varios proyectos adicionales asociados a Kubernetes en los que se pueden ocultar vulnerabilidades, entre ellos git-sync.
El proyecto git-sync está diseñado para conectar un pod y un repositorio de git con el fin de sincronizar automáticamente los cambios entre su sitio y el servidor en lugar de realizar los cambios manualmente a través de una solución de integración e implementación continuas (CI/CD). Por ejemplo, los usuarios podrían utilizar esta función para enlazar su pod nginx con un repositorio que contenga los archivos que desean exponer a través de un pod nginx.
En esta entrada del blog, analizaremos de forma detallada el defecto de diseño, los problemas en el código fuente de Kubernetes que lo permiten y algunas medidas de mitigación. También hablaremos sobre la respuesta de Kubernetes a nuestros resultados.
Detalles del vector de ataque
Al examinar la página de uso de git-sync, podemos ver que admite muchos parámetros de configuración posibles para que un usuario pueda personalizar git-sync según sus necesidades. Esto permite una superficie de ataque potencialmente grande que un atacante podría explotar (Figura 1).
Fig. 1: Algunos de los parámetros de git-sync
El marco de Kubernetes utiliza archivos YAML prácticamente para todo, desde la configuración de la interfaz de red de contenedores hasta la gestión de módulos e incluso la gestión de secretos, por lo que una vulnerabilidad en YAML puede ser bastante grave. En este caso, se puede crear un pod con el fin de utilizar git-sync para conectarse a un repositorio remoto (o a un atacante).
La Figura 2 es un ejemplo de un archivo YAML de configuración que implementa un pod con git-sync.
Fig. 2: Archivo YAML de configuración que implementa un pod con git-sync
Los dos parámetros que más llamaron la atención como posibles vectores de ataque fueron GITSYNC_GIT y GITSYNC_PASSWORD.
Según los documentosoficiales de git-sync, GITSYNC_PASSWORD_FILE Es "el archivo desde el que se leerá la contraseña o el token de acceso personal (consulte los documentos de GitHub) que se utilizará para la autenticación de git (consulte --username)". Esto sugiere la posibilidad de la exfiltración de datos del "token de acceso" u otros archivos en el pod.
GITSYNC_GIT es (de nuevo según los documentos oficiales) "El comando de git que se va a ejecutar (en función de la búsqueda PATH , principalmente para pruebas). El valor predeterminado es "git", lo que significa que podemos elegir un archivo binario que se ejecutará en lugar de git y utilizarlo para la ejecución de código en el clúster.
Cadena de ataques propuesta
Con la información anterior en mente, nos propusimos probar nuestras teorías. Creemos que existen algunos vectores de ataque que los atacantes pueden explotar.
Ejecución sigilosa de código
Un atacante con pocos privilegios (Crear privilegios) en el clúster o espacio de nombres puede aplicar un archivo YAML malicioso que contenga una ruta a su archivo binario y hacer que se ejecute con el nombre de git-sync.
El archivo binario debe estar dentro del pod, lo que se puede hacer de varias formas diferentes, como a través de los análisis de Kubernetes, volúmenes de Kubernetes o LOLBins que se incluyen con el pod de git-sync (Figura 3).
Fig. 3: Ejemplo de YAML con LOLBins
Después de aplicar el archivo YAML, y según el personal de los equipos azules, git-sync es el elemento que se comunica con un servidor remoto y, por lo tanto, es razonable asumir que se puede confiar en que se comunique externamente. Esto permite a los atacantes eludir las medidas de seguridad como ventaja adicional a la ejecución del comando.
La Figura 4 muestra una prueba de concepto (PoC) de un posible ataque iniciando un malware de criptominería llamado XMRig mediante el usuario de git-sync.
Fig. 4: Prueba de concepto (PoC) de un posible malware de criptominería XMRig
Ahora, cuando un administrador de red audita los pods existentes y su comunicación fuera de la red de la empresa, lo más probable es que vea al usuario de git-sync comunicarse con un servidor externo.
Exfiltración de datos
Un atacante con privilegios de edición puede editar una implementación de git-sync para cambiar o añadir el parámetro GITSYNC_PASSWORD_FILE y dirigirlo hacia cualquier archivo del pod. Esto hará que git-sync envíe el archivo como medio de autenticación en su próxima conexión al repositorio de git.
Si el atacante también modifica la ubicación del repositorio de git y configura un servidor de seudorepositorio, la siguiente implementación del proceso de git-sync dentro del pod enviará el archivo en el parámetro GITSYNC_PASSWORD_FILE del pod a su equipo. No hay restricciones en las rutas de acceso a los archivos ni en los permisos necesarios para GITSYNC_PASSWORD_FILE.
Una exfiltración de alto riesgo no es difícil de imaginar. Tenga en cuenta lo siguiente: Los atacantes pueden utilizar esta técnica para recuperar el token de acceso del pod, lo que les permitiría interactuar con el clúster con la apariencia del pod de git-sync (Figura 5).
Fig. 5: Prueba de concepto (PoC) de un posible ataque de GITSYNC_PASSWORD_FILE
Divulgación y respuesta de Kubernetes
Revelamos nuestros resultados al equipo de Kubernetes en diciembre de 2023. Después de hablar con el equipo de Kubernetes, se tomó la decisión de que editar archivos YAML se considera una operación que requiere privilegios altos , por lo tanto, nuestros resultados no cruzan un umbral de seguridad. Sin embargo, desde nuestra perspectiva, aunque las operaciones de edición en un pod se consideran privilegiadas, el movimiento lateral sigue siendo posible con esta técnica. También existía la preocupación de perder integridad: el atacante podría robar información como si fuera un usuario legítimo de git-sync.
Sobre la cuestión de GITSYNC_GIT, el equipo de Kubernetes reconoció que los privilegios que se requieren para este tipo de acción son pocos, pero no pensó que las operaciones que requieren pocos privilegios provocarían ningún comportamiento perjudicial. Sin embargo, creemos que el defecto de diseño que hemos descrito permitiría a los atacantes ejecutar comandos mediante la suplantación de su identidad, y la única barrera para el comportamiento dañino es que se requieren pocos privilegios en el clúster. Este flujo de ataque es especialmente peligroso en las organizaciones que tienen una comunicación de git-sync autorizada previamente en su clúster.
En ambos casos, Kubernetes nos animó a compartir esta valiosa investigación online, ya que "ayuda a recordar a los administradores a pensar detenidamente en el área de superficie que exponen a los usuarios".
Mitigaciones
Dado que el equipo de Kubernetes no considera que las técnicas de ataque descritas en esta entrada del blog sean vulnerabilidades, no habrá un parche para ellas. Por lo tanto, para reducir la superficie de ataque que estas "características" permiten, recomendamos algunas posibles mitigaciones.
En primer lugar, aumente la supervisión de la comunicación que sale de la organización, específicamente de los pods de Kubernetes. Preste atención especial a los pods de git-sync, si ese nivel de detalle es posible.
En segundo lugar, recomendamos auditar los pods de git-sync para ver qué comando están ejecutando. Esto se puede hacer con el siguiente comando:
kubectl describe pod <git-sync-pod>
Por ejemplo, cuando ejecutamos este comando en el malware de criptominería que se muestra en la Figura 4, podemos ver el argumento –git que habría activado una señal de alarma al detectarlo, especialmente cuando el valor del argumento no es "git" (Figura 6).
Fig. 6: Ejecución de este comando de auditoría en el malware de criptominería de la Figura 4
Esta auditoría es una práctica recomendada de seguridad general, por lo que recomendamos ejecutar este comando en todos los pods, no solo en los pods de git-sync.
También hemos escrito una regla de OPA que puede detectar uno de nuestros vectores de ataque propuestos, en el que los ataques sustituyen al binario de git por una carga útil maliciosa:
package kubernetes.admission
deny[msg] {
input.request.kind.kind == "<Deployment/Pod>"
path := input.request.object.spec.env.name
contains(path, "GITSYNC_GIT")
msg := sprintf("Gitsync binary parameter detected, possible payload alteration, verify new binary ", [path])
}
Conclusión
En esta entrada del blog hemos mostrado dos vectores de ataque en el proyecto adicional de Kubernetes git-sync. Ambos vectores se deben a la falta de saneamiento de los datos de entrada, lo que pone de relieve la necesidad de una defensa sólida con respecto al saneamiento de los datos de entrada del usuario. Estos problemas de saneamiento de Kubernetes no son exclusivos de git-sync, como ya hemos debatido anteriormente .
Los miembros de los equipos azules deben estar atentos a comportamientos inusuales procedentes del usuario de git-sync en sus organizaciones. Creemos que estos vectores de ataque pueden tener un gran impacto en las empresas; por lo tanto, es importante para nosotros concienciar y ayudar a los administradores de seguridad para que conozcan el peligro potencial.
El grupo de inteligencia sobre seguridad de Akamai seguirá investigando amenazas como estas e informando sobre ellas para nuestros clientes y la comunidad de seguridad en general. Para obtener actualizaciones en tiempo real sobre todo aquello en lo que estamos trabajando, síganos en X (anteriormente Twitter).
A pesar de no estar de acuerdo sobre el resultado, queremos dar las gracias al equipo de Kubernetes por su respuesta y su discurso.