[04/03/2020] En la era de la computación en la nube, donde la infraestructura debe ampliarse o implementarse rápidamente para satisfacer las necesidades organizativas en constante cambio, la configuración de nuevos servidores y nodos está completamente automatizada. Esto se hace usando archivos de definición legibles por máquina, o plantillas, como parte de un proceso conocido como infraestructura como código (IaC) o automatización de configuración continua (CCA).
Un nuevo análisis realizado por investigadores de Palo Alto Networks de plantillas de IaC recopiladas de repositorios de GitHub y otros lugares. identificó que casi 200 mil de esos archivos contenían opciones de configuración inseguras. El uso de esas plantillas puede generar serias vulnerabilidades que ponen en riesgo la infraestructura de la nube implementada por IaC y los datos que contiene.
"Al igual que cuando olvida bloquear su auto o deja una ventana abierta, un atacante puede usar estas configuraciones erróneas para evadir las defensas”, señalaron los investigadores. "Este alto número explica por qué, en un informe anterior, descubrimos que el 65% de los incidentes en la nube se debieron a configuraciones incorrectas de los clientes. Sin plantillas de IaC seguras desde el principio, los entornos en la nube están listos para ser atacados”.
Problemas generalizados de IaC
Existen múltiples marcos y tecnologías de IaC, los más comunes basados en el esfuerzo de recolección de Palo Alto son Kubernetes YAML (39%), Terraform de HashiCorp (37%) y AWS CloudFormation (24%). De estos, el 42% de las plantillas de CloudFormation identificadas, el 22% de las plantillas de Terraform y el 9% de los archivos de configuración de Kubernetes YAML tenían una vulnerabilidad.
El análisis de Palo Alto sugiere que la mitad de las implementaciones de infraestructura que usan plantillas AWS CloudFormation tendrán una configuración insegura. El informe profundiza aún más por tipo de servicio AWS afectado: Amazon Elastic Compute Cloud (Amazon EC2), Amazon Relational Database Service (RDS), Amazon Simple Storage Service (Amazon S3) o Amazon Elastic Container Service (Amazon ECS).
Por ejemplo, más del 10% de los cubos de almacenamiento S3 definidos en las plantillas fueron expuestos públicamente. Los cubos S3 mal protegidos han sido la fuente de muchas violaciones de datos reportadas públicamente en el pasado.
La ausencia de cifrado y registro de la base de datos, que es importante para proteger los datos e investigar el potencial acceso no autorizado, también fue un problema comúnmente observado en las plantillas de CloudFormation. La mitad no habilitó el registro S3 y la otra mitad no habilitó el cifrado S3 del lado del servidor.
Una situación similar se observó con el servicio de almacenamiento de datos Redshift de Amazon. El 11% de los archivos de configuración produjeron instancias de Redshift que fueron expuestas públicamente, el 43% no tenía el cifrado habilitado, y el 45% no tenía el registro activado.
Las plantillas Terraform, que admiten múltiples proveedores y tecnologías en la nube, no tuvieron mejores resultados. Alrededor del 66% de los cubos S3 configurados por Terraform no tenían habilitado el registro, el 26% de las instancias de AWS EC2 tenían SSH (puerto 22) expuesto a Internet y el 17% de AWS Security Groups definidos por plantillas permitían todo el tráfico entrante de manera predeterminada.
Otras configuraciones incorrectas comunes encontradas en las plantillas de Terraform incluyen:
Contraseñas de AWS Identity and Access Management (IAM) que no cumplen con los estándares mínimos de la industria (40%)
Contenedores sin CPU o limitación de recursos de memoria (64%)
Azure Network Security Groups (NSG) con SSH expuesto (51%)
Google Cloud Platform Storage sin registro habilitado (58%)
Azure Storage sin Secure Transfer habilitado (97%).
Los archivos Kubernetes YAML tuvieron la menor incidencia de configuraciones inseguras, pero éstas fueron significativas. De los archivos YAML inseguros encontrados, el 26% tenía configuraciones de Kubernetes que se ejecutaban como root o con cuentas privilegiadas.
"Las configuraciones que permiten contenedores como root, les proporcionan a los atacantes la oportunidad de poseer prácticamente cualquier aspecto de ese contenedor”, señalan los investigadores de Palo Alto. "Esto también facilita el proceso de realizar ataques de escape de contenedores, lo que abre el sistema host a otras amenazas potenciales. Los equipos de seguridad y DevOps deben garantizar que los contenedores no se ejecuten con cuentas root o privilegiadas”.
Configuraciones erróneas de IaC reflejadas en implementaciones reales
Los tipos de configuraciones incorrectas de plantillas de IaC y su prevalencia (la ausencia de cifrado y registro de la base de datos o servicios expuestos públicamente) están en línea con el tipo de problemas detectados por Palo Alto Networks en implementaciones de infraestructura en la nube reales:
76% de las organizaciones permiten el acceso público al puerto 22 (SSH)
69% de las organizaciones permiten el acceso público al puerto 3389 (RDP)
64% no puede habilitar el registro para su almacenamiento de datos
62% no habilita el cifrado para el almacenamiento de datos
47% de las organizaciones no utilizan la funcionalidad de rastreo para funciones serverless
Esto sugiere que el uso de plantillas IaC en procesos automatizados de implementación de infraestructura sin revisar que no tengan configuraciones inseguras u otras vulnerabilidades es un gran factor que contribuye a las debilidades de la nube observadas.
A menudo, los grupos ciberdelincuentes se dirigen a la infraestructura de la nube para implementar malware de criptominería que aprovecha la potencia de procesamiento que pagan las víctimas. Sin embargo, algunos de estos grupos también se están aventurando más allá de la criptominería y usan nodos de nube hackeados para otros fines maliciosos.
"Es evidente que los atacantes están utilizando los errores de configuración predeterminados implementados por plantillas de configuración de IaC débiles o inseguras, superando firewalls, grupos de seguridad o políticas de VPC, y exponiendo innecesariamente el entorno de la nube de una organización a los atacantes”, comentan los investigadores de Palo Alto. "La seguridad shift-left se trata de llevar la seguridad al punto más temprano posible en el proceso de desarrollo. Las organizaciones que constantemente llevan a cabo prácticas y procedimientos de shift-left dentro de las implementaciones en la nube pueden superar rápidamente a los competidores. Trabaje con los equipos de DevOps para incorporar sus estándares de seguridad en las plantillas de IaC. Este es un beneficio mutuo para DevOps y la seguridad”.
Lucian Constantin, CSO (EE.UU.)