Advertencias sobre incluir credenciales, claves y tokens al compartir código en repositorios de acceso público no deberían ser necesarias. Debería ser evidente que no se entregan las llaves de sus datos así como así. Pero, ¿qué sucede si una configuración incorrecta resulta en que una cuenta de almacenamiento interna supuestamente quede repentinamente accesible para todos?
Así es como Microsoft filtró el acceso a 38 terabytes de datos.
Wiz Research descubrió que el equipo de investigación de inteligencia artificial de Microsoft, al publicar un conjunto de datos de entrenamiento de código abierto en GitHub, expuso accidentalmente 38 terabytes de datos privados adicionales, incluyendo una copia de seguridad de disco de las estaciones de trabajo de dos empleados. Las copias de seguridad contenían datos sensibles, incluyendo contraseñas de servicios de Microsoft, claves secretas y más de 30,000 mensajes internos de Microsoft Teams de 359 empleados de Microsoft.
Un recurso de Azure llamado “Token de Acceso Compartido” (SAS) que permite a los usuarios compartir datos desde cuentas de almacenamiento de Azure fue la fuente del problema.
El token SAS se puede usar para restringir:
- A qué recursos puede acceder un cliente.
- Qué operaciones puede realizar un cliente (leer, escribir, listar, eliminar).
- A qué red puede acceder un cliente (HTTPS, dirección IP).
- Cuánto tiempo tiene acceso un cliente (hora de inicio, hora de finalización).
El almacenamiento de blobs es un tipo de almacenamiento en la nube para datos no estructurados. Un “blob”, que es una abreviatura de Binary Large Object (Objeto Binario Grande), es una masa de datos en forma binaria. Los tokens SAS de Azure Storage son esencialmente cadenas que permiten el acceso a los servicios de almacenamiento de Azure de manera segura. Son un tipo de URI (Identificador de Recurso Uniforme) que ofrecen derechos de acceso específicos a recursos de Azure Storage especificados, como un blob o una serie completa de blobs.
Un empleado de Microsoft compartió una URL de un almacenamiento de blobs en un repositorio público de GitHub mientras contribuía a modelos de aprendizaje de inteligencia artificial de código abierto. Esta URL incluía un token SAS excesivamente permisivo para una cuenta de almacenamiento interna.
La URL permitía el acceso a más que solo los modelos de código abierto. Estaba configurada para otorgar permisos en toda la cuenta de almacenamiento, exponiendo así accidentalmente datos sensibles adicionales.
Pero exponer datos sensibles ni siquiera es lo peor que podría haber ocurrido, explica Wiz.
“Un atacante podría haber inyectado código malicioso en todos los modelos de inteligencia artificial en esta cuenta de almacenamiento, y todos los usuarios que confían en el repositorio de GitHub de Microsoft habrían sido infectados por él”. Después de que Wiz compartiera sus hallazgos con Microsoft el 22 de junio de 2023, Microsoft revocó el token SAS dos días después.
Microsoft declaró que:
“La información que se expuso consistía en información única de dos ex empleados de Microsoft y las estaciones de trabajo de estos ex empleados. No se expusieron datos de clientes y no se pusieron en riesgo otros servicios de Microsoft debido a este problema. Los clientes no necesitan tomar ninguna acción adicional para mantenerse seguros”. Microsoft también dijo que como resultado de la investigación de Wiz, ha ampliado el servicio de supervisión de secretos de GitHub, que monitorea todos los cambios de código abierto público en busca de exposición de credenciales y otros secretos en texto plano, para incluir cualquier token SAS que pueda tener vencimientos o privilegios excesivamente permisivos.
Mejores prácticas para los tokens SAS
Para permitir que otros aprendan de sus errores, Microsoft compartió algunos consejos sobre el uso de las URL SAS.
- Aplicar el principio de menor privilegio: Limitar las URL SAS al conjunto más pequeño de recursos requeridos por los clientes (por ejemplo, un solo blob) y limitar los permisos solo a los necesarios para la aplicación (por ejemplo, solo lectura, solo escritura).
- Usar tokens SAS de corta duración: Siempre usar un tiempo de vencimiento a corto plazo al crear un token SAS y hacer que los clientes soliciten nuevas URL SAS cuando sea necesario. Azure Storage recomienda una hora o menos para todas las URL SAS.
- Manejar los tokens SAS con cuidado: Las URL SAS otorgan acceso a sus datos y deben tratarse como un secreto de la aplicación. Solo exponer las URL SAS a clientes que necesitan acceso a una cuenta de almacenamiento.
- Tener un plan de revocación: Asociar los tokens SAS con una política de acceso almacenada para la revocación detallada de un token SAS dentro de un contenedor. Estar preparado para eliminar la política de acceso almacenada o rotar las claves de la cuenta de almacenamiento si se filtra un token SAS o una clave compartida.
- Supervisar y auditar su aplicación: Hacer un seguimiento de cómo se autorizan las solicitudes a su cuenta de almacenamiento habilitando Azure Monitor y Azure Storage Logs. Usar una Política de Vencimiento de SAS para detectar clientes que usan URL SAS de larga duración. Wiz desaconseja el uso externo de los tokens SAS.
“[Los tokens SAS] son muy difíciles de rastrear, ya que Microsoft no proporciona una forma centralizada de gestionarlos dentro del portal de Azure. Además, estos tokens se pueden configurar para durar efectivamente para siempre, sin límite superior en su tiempo de vencimiento. Por lo tanto, el uso de tokens SAS de cuenta para compartir externamente es inseguro y debe evitarse”.