Una URL de CDN del Departamento de Defensa de EE. UU. publicaba el listado XML de sus objetos, con ETag incluido

Resumen

El fallo es una divulgación de información por mala configuración, de severidad baja. Una URL de CDN, cuya dirección aparece censurada en el reporte, respondía con el listado XML en bruto de los objetos almacenados. Para cada objeto mostraba estos campos:

• Key
• LastModified
• Size
• StorageClass
• ETag

El contenido de los ficheros seguía con control de acceso, de modo que no se podían descargar. Lo expuesto era la información sobre ellos: cómo se llamaban, cuándo se modificaron, cuánto ocupaban y su identificador o hash.

El punto delicado es el ETag. Según explica el investigador, en una subida a S3 de una sola parte suele coincidir con el MD5 del objeto. En las subidas multiparte no es un MD5 y lleva una marca propia. Por eso el reporte propone tratar cualquier ETag expuesto como una posible huella del fichero.

Pasos de reproducción

El reporte solo tiene un paso, y la dirección está censurada en la versión divulgada:

1. Visitar la URL de la CDN afectada. La respuesta es directamente el listado XML con los campos anteriores.

Impacto

El investigador describe cuatro consecuencias:

• Reconocimiento: nombres, fechas, tamaños y ETag permiten a un atacante hacerse un mapa del contenido interno y de los patrones de actividad.
• Huella de ficheros: con los hashes expuestos se puede confirmar que un fichero coincide con otro conocido, detectar duplicados o versiones concretas, y relacionar contenido entre sistemas si el mismo hash aparece en filtraciones o repositorios públicos.
• Subidas accidentales: si alguien sube por error un fichero sensible, su existencia puede detectarse enseguida por los metadatos o el ETag.
• Cumplimiento: el reporte señala que exponer metadatos y hashes es una mala configuración que puede chocar con las directrices de NIST y del DoD.

El investigador añade que un listado así no aporta nada: las CDN actuales, como CloudFront o Akamai, pueden servir solo los recursos públicos previstos, sin mostrar los metadatos del almacenamiento. El listado amplía la superficie de ataque sin ninguna necesidad operativa.

Remediación

El reporte consta como resuelto, pero no detalla qué cambio se aplicó. Estas son las medidas que propuso el investigador:

• Desactivar el listado público del bucket o del endpoint de la CDN, para impedir las respuestas ListBucket o de directorio.
• Si hace falta un listado para contenido público legítimo, servir solo los objetos previstos mediante una CDN que no muestre el índice del bucket ni los ETag.
• Usar URL firmadas o prefirmadas para distribuir el contenido no público.
• Valorar si se pueden quitar los campos ETag de los listados públicos, o sustituirlos por identificadores truncados u opacos.
• Auditar los objetos almacenados en busca de contenido sensible subido por error y vigilar los intentos de enumeración.
• Revisar de inmediato la configuración de la CDN y de S3, junto con los registros de acceso.

Qué aprender de este caso

• Al auditar una CDN, abre también la raíz del dominio o de la ruta de almacenamiento, no solo los recursos enlazados: una respuesta XML con Key y ETag indica que el listado del bucket está abierto.
• Comprueba por separado el permiso de leer objetos y el de listarlos. Aquí los ficheros estaban protegidos y, aun así, sus nombres, fechas y hashes eran públicos.
• Si el ETag no indica subida multiparte, puede ser el MD5 del objeto: compáralo con hashes de ficheros conocidos para saber si dos copias son iguales sin descargar ninguna.
• Al configurar un bucket detrás de una CDN, no concedas ListBucket al público si el servicio solo necesita entregar objetos concretos.