No te confundas. Las habilidades de un hacker poco tienen que ver con ser experto en algún proveedor cloud particular. Sin embargo, conocer cómo funciona la nube y las herramientas que pone a disposición de sus clientes es un gran activo para entender la tecnología subyacente a productos y servicios y, sobre todo, dónde pueden existir fallas de seguridad explotables.
Asimismo, entender la forma en que los hackers realizan ataques es un game-changer para equipos que se dedican a mantener la seguridad. Además, no siempre los equipos de ciberseguridad se encuentran integrados con los de infraestructura, por lo que saber “dónde mirar” permite ser más efectivo a la hora de querer auditar el nivel de cumplimiento en seguridad de la nube.
En este artículo, discutiremos sobre aspectos de seguridad asociados a los principales servicios en AWS. Veremos cuáles son algunas de las cosas que buscan los hackers a la hora de intentar acceder a información sensible o ejecutar acciones que requieren permisos elevados. También, algunas de las estrategias que los equipos encargados de salvaguardar la infraestructura pueden aplicar y deben monitorear. La idea es contrastar ambas perspectivas, que usualmente se miran de forma aislada, para que así tengas un entendimiento más global de la ciberseguridad en entornos AWS.
Vectores de ataque y estrategias para mitigarlos en servicios de AWS
Para este artículo, asumiré que como atacante cuentas con autorización y acceso a la infraestructura a auditar. Haremos uso de AWS CLI y de conocimientos teóricos y prácticos de la nube. A su vez, los equipos que defienden esta infraestructura deben tener conocimientos de cómo funcionan sus principales servicios y de riesgos de ciberseguridad inherentes a ellos.
Identity Access Management (IAM)
Es imposible no partir hablando del servicio que se encarga de entregar los permisos a usuarios y servicios dentro de AWS. Principalmente, porque la causa raíz de la gran mayoría de vulnerabilidades presentes en la nube se deben a privilegios excesivos.
En AWS, existen usuarios (asociado normalmente a personas) y roles (asociado a quien lo requiere, usualmente servicios), los cuales obtienen sus permisos a través de políticas que pueden ser asignadas directamente o heredadas. Una de las principales diferencias entre un IAM user y un IAM role es que, a diferencia del primero, los roles no cuentan con credenciales permanentes de seguridad (como contraseñas y llaves de acceso). En su lugar, usan credenciales temporales para la sesión en la que el rol es asumido.
Así es como se ve una IAM policy en formato JSON:
Cada política cuenta con uno o más statements (declaraciones que entregan permisos). Lo más seguro es que cada uno de estos, y la política como un todo, se adhieran al principio de mínimo privilegio. Esto con el objetivo de impedirle a un atacante poder escalar privilegios a través de los permisos excesivos que puede tener esa política, ya sea para interactuar con otros usuarios o servicios.
Por regla general, los permisos de administración con una wildcard (es decir, que permiten todo sobre el recurso en cuestión) no son una buena práctica y deben ser restringidos en la medida de lo posible. Algunos ejemplos de permisos más específicos que pueden ser usados para escalar privilegios son:
- iam:CreateNewPolicyVersion: un atacante podría crear una nueva versión de política, a la cual, luego, le asigne permisos de administrador.
- iam:AttachRolePolicy: un atacante puede usar este permiso para adjuntar una nueva política a algún rol al cual ya tenga acceso.
- iam:CreateLoginProfile: un atacante puede crear una contraseña para un usuario con mayores privilegios e iniciar sesión en la consola con la nueva credencial.
- lambda:UpdateFunctionConfiguration: un atacante podría modificar la ejecución normal de una función lambda y ejecutar código malicioso usando los privilegios del rol asociado a la función lambda.
Explotando buckets de S3
AWS Simple Storage Service, o más conocido como S3, es uno de los primeros servicios de AWS y de los más utilizados para poder almacenar y acceder a información de manera escalable. Las organizaciones lo utilizan para almacenar documentos, páginas web, copias de bases de datos, archivos multimedia, logs, entre muchas otras opciones, por lo que es de gran interés desde una perspectiva de seguridad.
Los buckets públicos o con políticas de acceso mal configuradas son la causa de muchas brechas de datos reportadas. Con los siguientes comandos, podrás verificar si es que algún bucket sospechoso, en este caso suspiciousbucket, cuenta con acceso público.
Pueden existir casos donde requieras que el bucket interactúe con recursos externos. Para ello, una posible estrategia es configurar CORS (Cross-Origin Resource Sharing):
CORS no va a modificar directamente la postura de acceso general del bucket, solamente controla como los recursos del bucket pueden ser compartidos desde distintos orígenes.
AWS EC2 – Metadata
La IP 169.254.169.254 tiene un significado especial en la nube, ya que es usada por AWS para buscar metadata relacionada a la instancia, tanto del usuario, y particularmente de las credenciales de seguridad entregada desde IAM. Es solamente accesible localmente desde una instancia y disponible sin encriptación o autenticación.
Esta característica es especialmente atractiva para un hacker, ya que podría acceder a esta metadata si la aplicación alojada en la instancia es vulnerable a un Server-Side Request Forgery. El siguiente script entregaría la metadata asociada a las credenciales de la instancia, siempre y cuando el rol siga asociado a la misma:
Para acceder a la metadata de EC2 se usa el servicio de metadatos de instancias (IMDS por sus siglas en inglés), el cual tiene dos opciones (ambas habilitadas por defecto):
- IMDSv1: A través solicitud / respuesta, y es la forma utilizada más arriba al usar curl.
- IMDSv2: A través de un token de sesión.
La segunda versión es más segura dado que mitiga distintas vulnerabilidades, incluido un SSRF. Esto, debido a que el token de sesión no puede ser obtenido a través de HTTP, por lo que el hacker tendría que ser capaz de obtener este token de otra manera.
AWS WAF – Protección y Bypass
El AWS Web Application Firewall es un firewall capa 7, por lo que permite monitorear protocolos tales como HTTP / HTTPS, DNS, FTP y SSH. Ayuda a protegerte frente a exploits comunes y bots que pueden afectar tu seguridad o disponibilidad.
Una de las grandes ventajas de este servicio de AWS es que es muy fácil de implementar, cuenta con múltiples capacidades de seguridad activables solo con un par de clics y se integra nativamente a servicios críticos de AWS tales como el balanceador de carga de aplicaciones (ALB), Distribuciones de Cloudfront (CDNs) y AWS API Gateway.
Sin embargo, este servicio cuenta con una limitante: solo es capaz de examinar los primeros 8kb del cuerpo de una solicitud entrante. Esta limitación es información pública y, según el Modelo de Responsabilidad Compartida de AWS, es responsabilidad del cliente tenerla en cuenta al implementar sus medidas de seguridad.
Por ende, un hacker puede ejecutar un payload sobre las aplicaciones alojadas manipulando la solicitud, agregándole previamente 8kb de data basura. En Burp, se vería de esta forma:
¿Quiere decir esto que el WAF no me sirve?
En lo absoluto. El WAF sigue siendo una capa de protección adicional que te permitirá mejorar tu postura de seguridad e incluso te puede ayudar a comprender mucho mejor el tráfico que ingresa desde internet hacia tu infraestructura.
Sin embargo, no quita la responsabilidad de mantener la seguridad de tu infraestructura y aplicaciones alojadas. Por eso, es relevante aplicar un modelo de seguridad por capas, en el cual vas agregando múltiples barreras a un atacante para poder proteger tus sistemas e información sensible de manera más efectiva.
Conclusiones finales
En general, los responsables de la postura defensiva de una organización deben asegurarse de que los equipos de infraestructura sigan las mejores prácticas de seguridad. Sin embargo, este proceso puede ser agotador para todas las partes involucradas, ya que normalmente requiere solicitar evidencias manualmente y solo evalúa la seguridad en momentos específicos, en lugar de hacerlo de forma continua.
Afortunadamente, existen herramientas, como la plataforma de Seguridad y Cumplimiento de Hackmetrix, que te permiten realizar escaneos periódicos y alertar proactivamente cuando se detectan fallas que puedan comprometer tu infraestructura.
Por otra parte, los estándares y mejores prácticas de seguridad recomiendan realizar pruebas de hackeo ético realizadas por terceros para evaluar la efectividad práctica de la postura de seguridad de una organización. Las organizaciones tienden a realizar esto únicamente a nivel de sus aplicativos, pero no a las infraestructuras que las soportan. En Hackmetrix hemos realizado múltiples pruebas de hackeo ético sobre AWS y otros proveedores cloud a través de estrategias como las mencionadas en este artículo (puedes leer el artículo de nuestro blog donde mostramos cómo apropiarnos de una red EC2 completa).
Si esto te parece interesante, no dudes en contactarnos, o puedes averiguar más en el marketplace de AWS.
