Errores de política en S3 permiten escritura en claves no autorizadas
Usar prefijos en vez de claves exactas en las políticas de subida firmada expone el bucket a escrituras no deseadas, como muestran reportes de Shopify y BCM.
Cuatro reportes recientes en HackerOne describen el mismo fallo de seguridad en infraestructuras cloud: políticas de subida (upload) firmadas hacia Amazon S3 que permiten escribir en cualquier clave dentro de un prefijo, en lugar de restringirse a la clave específica generada por el servidor. El resultado es que cualquier usuario autenticado puede sobrescribir archivos administrativos, inyectar código o alterar datos ajenos simplemente cambiando el nombre del archivo subido.
El patrón técnico es sencillo de identificar. Cuando un backend genera una firma para que el navegador suba directamente a S3, la condición de la política suele usar starts-with sobre el campo $key. Por ejemplo, aceptar files/ significa que la política valida files/admin.html o files/../etc/passwd igual de bien que el UUID esperado. La solución no es restringir el contenido, sino usar una coincidencia exacta (exact match) sobre una clave única que el servidor genera y valida antes de emitir la firma.
Para detectar y verificar estas vulnerabilidades, el proyecto open source Stave introduce un modelo de análisis que va más allá de las comprobaciones estáticas habituales. Mientras que las reglas CEL (Common Expression Language) pueden afirmar si una configuración está en un estado inseguro, no responden a la pregunta de impacto: ¿qué claves específicas puede alcanzar un atacante? Para ello, Stave utiliza el solver lógico Z3. Este componente modela el espacio de claves y busca un testigo concreto (witness) que demuestre que la política admite una clave que el generador de la aplicación no produciría jamás. Si el solver devuelve SAT (satisfiable), la vulnerabilidad está confirmada con un ejemplo reproducible.
La herramienta modela la política de subida como un activo independiente (s3_upload_policy) dentro de su esquema de observación. Esto permite auditar el contrato de la política, no solo el estado del bucket. El control específico, identificado como CTL.S3.WRITE.SCOPE.001, dispara una alerta de severidad alta siempre que detecte que una operación de escritura está sujeta a un modo de clave de prefijo en lugar de exacta.
Para los equipos de seguridad y DevOps, esto no es solo teoría. Los reportes citados, incluidos los de Shopify y BCM, muestran cómo un error de configuración aparentemente menor se convierte en un vector de cadena de suministro o en una exposición de datos sensibles. Revisar las políticas de firma en los controladores Rails, Express o Django para asegurar que usan claves exactas es una tarea rápida que evita incidentes graves.
