Introducción
En 2017, un socio de Verizon Wireless desconfiguró involuntariamente los controles de acceso a un servicio de Amazon S3, dejando al descubierto unos 6 millones de registros con nombres de clientes, información de contacto, direcciones, datos financieros e incluso pines de cuentas. Verizon fue informada en privado de la exposición el 13 de junio de 2017, y la configuración errónea fue remediada el día 22. Mientras el servicio permaneció mal configurado, cualquiera con una conexión a Internet podía ver fácilmente parte o la totalidad de estos datos.
En la era de la adopción masiva de soluciones de almacenamiento en la nube, por desgracia, vemos exposiciones como ésta con demasiada frecuencia. Los servicios en la nube parecen sencillos de configurar, pero un pequeño error puede exponer conjuntos de datos enteros en la Internet pública. Es posible que gestione muchos cubos de almacenamiento con diferentes niveles de acceso para uso interno y externo, y rápidamente puede resultar difícil gestionar sus configuraciones. Las exposiciones de almacenamiento en la nube son particularmente problemáticas, ya que es fácil para un atacante acceder a los datos o modificarlos mientras un bucket de almacenamiento permanece mal configurado. El Departamento de Defensa de EE.UU., Dow Jones & Co. y Booz Allen Hamilton ya han sufrido graves violaciones de los buckets S3 y otros activos de almacenamiento en la nube.
Este blog explora cómo una mala configuración de un bucket S3 puede conducir a una brecha a través de un análisis paso a paso:
- Creación de un nuevo bucket de almacenamiento de Amazon S3
- Configuración de la lista de control de acceso (ACL) para este bucket de Amazon S3
- Vectores de ataque habituales para acceder a los datos una vez configurados los permisos del bucket
- Cómo comprobar la posible exposición involuntaria de los buckets de Amazon S3 mediante la plataforma ASM Censys
Análisis
Para demostrar la complejidad de la configuración del acceso al almacenamiento en la nube, considere el grupo de acceso "Usuario autenticado" de Amazon para los buckets. Esto podría no sonar tan aterrador al principio, ¿verdad? Sin embargo, en la nomenclatura de Amazon, un "usuario autenticado" es cualquier persona con al menos una cuenta AWS de nivel libre. En otras palabras, si tu bucket de S3 está configurado con acceso de grupo "Usuario autenticado", cualquiera que esté dispuesto a registrarse para obtener una cuenta de AWS tiene acceso completo a tus datos. Se han documentado riesgos a gran escala relacionados con un profesional que ha configurado incorrectamente un bucket de almacenamiento utilizando este grupo de acceso.
Para ilustrar cómo un atacante podría comprometer y exfiltrar datos de un bucket de almacenamiento, recorreremos un ejemplo utilizando la herramienta CLI de AWS.
Utilizando una cuenta privada, crearemos un nuevo cubo de almacenamiento.
Ahora es el momento de configurar la política ACL para este bucket. Le daremos acceso de lectura al grupo de usuarios autenticados, ya que queremos que nuestros colegas puedan ver cualquier documento almacenado en el bucket.
Con nuestro bucket creado, es hora de subir algunos datos. `ohno.txt` es el archivo que queremos que nuestros colegas con cuentas AWS puedan leer.
Supongamos que han pasado unas semanas y que nuestro equipo interno ha estado utilizando este cubo con gran éxito.
Por desgracia, un atacante ha descubierto que nuestra empresa utiliza "mi cubo expuesto" como nombre de proyecto y quiere aprovecharlo para descubrir datos potencialmente expuestos en nuestro cubo de almacenamiento. Observan que al pulsar `https://my-exposed-bucket.s3.us-east-2.amazonaws.com/` en su navegador aparece un código de error `AccessDenied`, informándoles de que existe un cubo de almacenamiento con este nombre.
El atacante ahora sabe que potencialmente puede ver esta información. Configuran su herramienta personal CLI de AWS, e intentan listar el bucket usando el comando `ls`. Descubren que el bucket está expuesto y contiene un archivo `txt` llamado `ohno`.
Para acceder a los datos expuestos, el atacante utiliza el comando `cp` para copiar el contenido a un directorio de su máquina personal. Aquí, copiamos `ohno.txt` a `./Desktop`.
La información del cubo está ahora en la máquina personal del atacante. Afortunadamente, el contenido de nuestro documento expuesto es benigno.
De todos los buckets de almacenamiento gestionados por Censys ASM, ~8,5% están expuestos como públicamente legibles, escribibles o con ajustes de configuración editables. En todos sus proveedores de almacenamiento en la nube, esto puede suponer que una parte considerable de sus buckets de almacenamiento estén mal configurados y puede dar lugar a ataques como los ilustrados anteriormente.
¿Qué puedo hacer?
La buena noticia es que la configuración incorrecta de los cubos es un problema que tiene solución. Aplicando las mejores prácticas en tu equipo e introduciendo soluciones automatizadas para descubrir riesgos, puedes protegerte mejor de las exposiciones.
- Asegúrese de que sus servicios de almacenamiento en la nube tienen configuradas las políticas IAM adecuadas.
- Cree y comunique políticas de seguridad sólidas dentro de su equipo. El NIST ofrece directrices de seguridad exhaustivas para las infraestructuras de almacenamiento.
- Considere la posibilidad de implantar una solución ASM automatizada para identificar los errores de configuración del almacenamiento en la nube. Censys es el único proveedor de ASM que detecta los riesgos asociados a los buckets de almacenamiento que usted posee, y aprovecha automáticamente sus datos para descubrir buckets de almacenamiento desconocidos que pueden afectar a su postura de seguridad.
- Los clientes actuales de Censys ASM pueden navegar a la página de la lista de cub os de almacenamiento para ver una recopilación actualizada de sus cubos de almacenamiento y cualquier riesgo asociado. ¿No es cliente de Censys ASM? Póngase en contacto con nosotros a través de la página de contactoCensys .
--
