Investigadores de ciberseguridad han descubierto tres debilidades de seguridad en Azure Data Factory de Microsoft Flujo de aire Apache integración que, si se hubiera explotado con éxito, podría haber permitido a un atacante obtener la capacidad de realizar diversas acciones encubiertas, incluida la exfiltración de datos y la implementación de malware.
“Explotar estas fallas podría permitir a los atacantes obtener acceso persistente como administradores en la sombra sobre todo el clúster Airflow Azure Kubernetes Service (AKS)”, Unidad 42 de Palo Alto Networks dicho en un análisis publicado a principios de este mes.
Las vulnerabilidades, aunque clasificadas como de baja gravedad por Microsoft, se enumeran a continuación:
- Kubernetes RBAC mal configurado en el clúster Airflow
- Manejo secreto mal configurado del servicio interno de Ginebra de Azure, y
- Autenticación débil para Ginebra
Además de obtener acceso no autorizado, el atacante podría aprovechar las fallas en el servicio de Ginebra para alterar potencialmente los datos de registro o enviar registros falsos para evitar levantar sospechas al crear nuevos pods o cuentas.
La técnica de acceso inicial implica la elaboración de un gráfico acíclico dirigido (TROZO DE CUERO) y cargarlo en un repositorio privado de GitHub conectado al clúster de Airflow, o modificar un archivo DAG existente. El objetivo final es iniciar un shell inverso a un servidor externo tan pronto como se importe.
Para lograr esto, el actor de la amenaza primero tendrá que obtener permisos de escritura en la cuenta de almacenamiento que contiene los archivos DAG utilizando una entidad de servicio comprometida o un token de firma de acceso compartido (SAS) para los archivos. Alternativamente, pueden ingresar a un repositorio de Git utilizando credenciales filtradas.
Aunque se descubrió que el shell obtenido de esta manera se ejecutaba en el contexto del usuario de Airflow en un módulo de Kubernetes con permisos mínimos, un análisis más detallado identificó una cuenta de servicio con permisos de administrador de clúster conectada al módulo de ejecución de Airflow.
Esta mala configuración, junto con el hecho de que se podía acceder al pod a través de Internet, significaba que el atacante podía descargar la herramienta de línea de comandos de Kubernetes kubectl y, en última instancia, tomar el control total de todo el clúster “implementando un pod privilegiado e irrumpiendo en el nodo subyacente.”
Luego, el atacante podría aprovechar el acceso raíz a la máquina virtual (VM) host para profundizar en el entorno de la nube y obtener acceso no autorizado a los recursos internos administrados por Azure, incluido Geneva, algunos de los cuales otorgan acceso de escritura a cuentas de almacenamiento y centros de eventos.
“Esto significa que un atacante sofisticado podría modificar un entorno vulnerable de Airflow”, dijeron los investigadores de seguridad Ofir Balassiano y David Orlovsky. “Por ejemplo, un atacante podría crear nuevos pods y nuevas cuentas de servicio. También podría aplicar cambios a los nodos del clúster y luego enviar registros falsos a Ginebra sin dar la alarma”.
“Este problema resalta la importancia de administrar cuidadosamente los permisos de los servicios para evitar el acceso no autorizado. También resalta la importancia de monitorear las operaciones de servicios críticos de terceros para evitar dicho acceso”.
La divulgación se produce cuando Datadog Security Labs detalló un escenario de escalada de privilegios en Bóveda de claves de Azure que podría permitir a los usuarios con el rol Colaborador de Key Vault leer o modificar el contenido de Key Vault, como claves API, contraseñas, certificados de autenticación y tokens SAS de Azure Storage.
El problema es que, si bien un usuario con la función Colaborador de Key Vault no tenía acceso directo a los datos de Key Vault a través de una bóveda de claves configurada con políticas de acceso, se descubrió que la función sí incluía permisos para agregarse a las políticas de acceso de Key Vault y acceder Datos de Key Vault, evitando efectivamente la restricción.
“Una actualización de política podría contener la capacidad de enumerar, ver, actualizar y, en general, administrar los datos dentro de la bóveda de claves”, dijo la investigadora de seguridad Katie Knowles. dicho. “Esto creó un escenario en el que un usuario con el rol de colaborador de Key Vault podía obtener acceso a todos los datos de Key Vault, a pesar de no tener [Role-Based Access Control] permiso para administrar permisos o ver datos.”
Microsoft desde entonces actualizó su documentación para enfatizar el riesgo de la política de acceso, indica: “Para evitar el acceso no autorizado y la administración de sus almacenes de claves, claves, secretos y certificados, es esencial limitar el acceso del rol de colaborador a los almacenes de claves según el modelo de permiso de la política de acceso”.
El desarrollo también sigue al descubrimiento de un problema con el registro de Amazon Bedrock CloudTrail que dificultaba diferenciar las consultas maliciosas de las legítimas realizadas a modelos de lenguaje grandes (LLM), lo que permitía a los malos actores realizar reconocimientos sin generar ninguna alerta.
“Específicamente, las llamadas fallidas a la API de Bedrock se registraron de la misma manera que las llamadas exitosas, sin proporcionar ningún código de error específico”, dijo el investigador de Sysdig, Alessandro Brucato. dicho.
“La falta de información de error en las respuestas de la API puede obstaculizar los esfuerzos de detección al generar falsos positivos en los registros de CloudTrail. Sin este detalle, las herramientas de seguridad pueden malinterpretar la actividad normal como sospechosa, lo que genera alertas innecesarias y una posible supervisión de amenazas genuinas”.
About the Author
