Incidentes Asociados
Loading...
- El equipo de investigación de IA de Microsoft, mientras publicaba un conjunto de datos de capacitación de código abierto en GitHub, expuso accidentalmente 38 terabytes de datos privados adicionales, incluida una copia de seguridad en disco de las estaciones de trabajo de dos empleados. * La copia de seguridad incluye secretos, claves privadas, contraseñas y más de 30.000 mensajes internos de Microsoft Teams. * Los investigadores compartieron sus archivos utilizando una característica de Azure llamada tokens SAS, que permite compartir datos de cuentas de Azure Storage. * El nivel de acceso puede limitarse únicamente a archivos específicos; sin embargo, en este caso, el enlace se configuró para compartir toda la cuenta de almacenamiento, incluidos otros 38 TB de archivos privados. * Este caso es un ejemplo de los nuevos riesgos que enfrentan las organizaciones cuando comienzan a aprovechar el poder de la IA de manera más amplia, ya que ahora más ingenieros trabajan con cantidades masivas de datos de capacitación. A medida que los científicos e ingenieros de datos se apresuran para llevar a producción nuevas soluciones de inteligencia artificial, las enormes cantidades de datos que manejan requieren controles y salvaguardas de seguridad adicionales. Como parte del [trabajo en curso] del equipo de investigación de Wiz (https://www.youtube.com/watch?v=rbHALyrxj0Y) sobre la exposición accidental de datos alojados en la nube, el equipo escaneó Internet en busca de contenedores de almacenamiento mal configurados. En este proceso, encontramos un repositorio de GitHub bajo la organización de Microsoft llamado "robust-models-transfer". El repositorio pertenece a la división de investigación de IA de Microsoft y su propósito es proporcionar código fuente abierto y modelos de IA para el reconocimiento de imágenes. Los lectores del repositorio recibieron instrucciones de descargar los modelos desde una URL de Azure Storage: La URL de almacenamiento expuesta, tomada del repositorio GitHub de Microsoft. Sin embargo, esta URL permitía el acceso a algo más que modelos de código abierto. Se configuró para otorgar permisos en toda la cuenta de almacenamiento, exponiendo por error datos privados adicionales. Nuestro análisis muestra que esta cuenta contenía 38 TB de datos adicionales, incluidas las copias de seguridad de las computadoras personales de los empleados de Microsoft. Las copias de seguridad contenían datos personales confidenciales, incluidas contraseñas de servicios de Microsoft, claves secretas y más de 30.000 mensajes internos de Microsoft Teams de 359 empleados de Microsoft. Contenedores expuestos bajo la cuenta de almacenamiento 'robustnessws4285631339' Una pequeña muestra de archivos confidenciales encontrados en las copias de seguridad de la computadora Conversación de Teams redactada entre dos empleados de Microsoft Además del alcance de acceso demasiado permisivo, el token también se configuró mal para permitir permisos de "control total" en lugar de solo lectura. Es decir, un atacante no sólo podría ver todos los archivos de la cuenta de almacenamiento, sino que también podría eliminar y sobrescribir los archivos existentes. Esto es particularmente interesante considerando el propósito original del repositorio: proporcionar modelos de IA para usar en código de entrenamiento. El repositorio indica a los usuarios que descarguen un archivo de datos del modelo desde el enlace SAS y lo introduzcan en un script. El formato del archivo es "ckpt", un formato producido por la biblioteca TensorFlow. Está formateado usando el formateador
picklede Python, que es propenso a la ejecución de código arbitrario por diseño. Es decir, un atacante podría haber inyectado código malicioso en todos los modelos de IA en esta cuenta de almacenamiento, y todos los usuarios que confían en el repositorio GitHub de Microsoft habrían sido infectados por él. Sin embargo, es importante tener en cuenta que esta cuenta de almacenamiento no estuvo expuesta directamente al público; de hecho, era una cuenta de almacenamiento privado. Los desarrolladores de Microsoft utilizaron un mecanismo de Azure llamado "tokens SAS", que le permite crear un enlace compartible que otorga acceso a los datos de una cuenta de Azure Storage; aunque, tras una inspección, la cuenta de almacenamiento aún parecería completamente privada. Introducción a los tokens SAS ------------------------------- En Azure, un token de firma de acceso compartido (SAS) es una URL firmada que otorga acceso a los datos de Azure Storage. El nivel de acceso puede ser personalizado por el usuario; los permisos varían entre solo lectura y control total, mientras que el alcance puede ser un solo archivo, un contenedor o una cuenta de almacenamiento completa. El tiempo de vencimiento también es completamente personalizable, lo que permite al usuario crear tokens de acceso que nunca caducan. Esta granularidad proporciona una gran agilidad a los usuarios, pero también crea el riesgo de conceder demasiado acceso; En el caso más permisivo (como hemos visto anteriormente en el token de Microsoft), el token puede permitir permisos de control total, en toda la cuenta, para siempre, proporcionando esencialmente el mismo nivel de acceso que la propia clave de la cuenta. Hay 3 tipos de tokens SAS: SAS de cuenta, SAS de servicio y SAS de delegación de usuario. En este blog nos centraremos en el tipo más popular: los tokens SAS de cuenta, que también se utilizaron en el repositorio de Microsoft. Generar una Cuenta SAS es un proceso sencillo. Como se puede ver en la pantalla siguiente, el usuario configura el alcance, los permisos y la fecha de vencimiento del token, y genera el token. Detrás de escena, el navegador descarga la clave de la cuenta de Azure y firma el token generado con la clave. Todo este proceso se realiza del lado del cliente; no es un evento de Azure y el token resultante no es un objeto de Azure. Creación de un token SAS de alto privilegio que no vence. Debido a esto, cuando un usuario crea un token altamente permisivo que no vence, no hay forma de que un administrador sepa que este token existe y dónde circula. Revocar un token tampoco es una tarea fácil: requiere rotar la clave de cuenta que firmó el token, lo que hace que todos los demás tokens firmados con la misma clave también sean ineficaces. Estos obstáculos únicos hacen de este servicio un blanco fácil para los atacantes que buscan datos expuestos. Además del riesgo de exposición accidental, los inconvenientes del servicio lo convierten en una herramienta eficaz para los atacantes que buscan mantener la persistencia en cuentas de almacenamiento comprometidas. Un [informe de Microsoft] reciente (https://www.microsoft.com/en-us/security/blog/2023/09/07/cloud-storage-security-whats-new-in-the-threat-matrix/# :~:text=Create%20SAS%20Token) indica que los atacantes están aprovechando la falta de capacidades de monitoreo del servicio para emitir tokens SAS privilegiados como puerta trasera. Dado que la emisión del token no está documentada en ninguna parte, no hay forma de saber que fue emitido y actuar en su contra. Riesgos de seguridad de SAS ----------------------- Los tokens de SAS suponen un riesgo de seguridad, ya que permiten compartir información con identidades externas no identificadas. El riesgo se puede examinar desde varios ángulos: permisos, higiene, gestión y seguimiento. ### Permisos Un token SAS puede otorgar un nivel de acceso muy alto a una cuenta de almacenamiento, ya sea a través de permisos excesivos (como leer, enumerar, escribir o eliminar) o a través de amplios alcances de acceso que permiten a los usuarios acceder al almacenamiento adyacente. contenedores. ### Higiene Los tokens SAS tienen un problema de vencimiento: nuestros escaneos y monitoreo muestran que las organizaciones a menudo usan tokens con una vida útil muy larga (a veces infinita), ya que no hay un límite superior en el vencimiento de un token. Este fue el caso del token de Microsoft, que fue válido hasta 2051. ### Gestión y monitoreo Los tokens SAS de cuentas son extremadamente difíciles de administrar y revocar. No existe ninguna forma oficial de realizar un seguimiento de estos tokens dentro de Azure, ni de monitorear su emisión, lo que dificulta saber cuántos tokens se han emitido y están en uso activo. La razón por la que ni siquiera se puede realizar un seguimiento de la emisión es que los tokens SAS se crean en el lado del cliente, por lo tanto, no es una actividad rastreada por Azure y el token generado no es un objeto de Azure. Debido a esto, incluso lo que parece ser una cuenta de almacenamiento privado puede quedar ampliamente expuesta. En cuanto a la revocación, no existe forma de revocar una Cuenta SAS singular; la única solución es revocar toda la clave de la cuenta, lo que invalida también todos los demás tokens emitidos con la misma clave. Monitorear el uso de tokens SAS es otro desafío, ya que requiere habilitar el inicio de sesión en cada cuenta de almacenamiento por separado. También puede resultar costoso, ya que el precio depende del volumen de solicitudes de cada cuenta de almacenamiento. Recomendaciones de seguridad de SAS --------------------------------- La seguridad de SAS se puede mejorar significativamente con las siguientes recomendaciones . ### Administración Debido a la falta de seguridad y gobernanza de los tokens SAS de la cuenta, deben considerarse tan confidenciales como la propia clave de la cuenta. Por lo tanto, se recomienda encarecidamente evitar el uso de Account SAS para compartir externamente. Los errores en la creación de tokens pueden pasar desapercibidos fácilmente y exponer datos confidenciales. Para compartir de forma externa, considere utilizar un servicio SAS con una [Política de acceso almacenado] (https://learn.microsoft.com/en-us/rest/api/storageservices/define-stored-access-policy). Esta característica conecta el token SAS a una política del lado del servidor, brindando la capacidad de administrar políticas y revocarlas de manera centralizada. Si necesita compartir contenido por tiempo limitado, considere usar una SAS de delegación de usuarios , ya que su tiempo de caducidad está limitado a 7 días. Esta característica conecta el token SAS con la administración de identidades de Azure Active Directory, brindando control y visibilidad sobre la identidad del creador del token y sus usuarios. Además, recomendamos crear cuentas de almacenamiento dedicadas para compartir externamente, para garantizar que el impacto potencial de un token con privilegios excesivos se limite únicamente a los datos externos. Para evitar los tokens SAS por completo, las organizaciones deberán deshabilitar el acceso a SAS para cada una de sus cuentas de almacenamiento. por separado. Recomendamos utilizar un CSPM para realizar un seguimiento y aplicar esto como política. Otra solución para deshabilitar la creación de tokens SAS es bloquear el acceso a “listar claves de cuentas de almacenamiento” operación en Azure (ya que no se pueden crear nuevos tokens SAS sin la clave) y luego rotar las claves de la cuenta actual para invalidar los tokens SAS preexistentes. Este enfoque aún permitiría la creación de User Delegation SAS, ya que se basa en la clave del usuario en lugar de la clave de la cuenta. ### Monitoreo Para realizar un seguimiento del uso activo del token SAS, debe habilitar los registros de Storage Analytics para cada una de sus cuentas de almacenamiento. Los registros resultantes contendrán detalles del acceso al token SAS, incluida la clave de firma y los permisos asignados. Sin embargo, cabe señalar que en los registros solo aparecerán los tokens utilizados activamente y que habilitar el registro conlleva cargos adicionales, lo que puede resultar costoso para cuentas con mucha actividad. Azure Metrics se pueden usar para monitorear el uso de tokens SAS en cuentas de almacenamiento. De forma predeterminada, Azure registra y agrega eventos de cuentas de almacenamiento hasta 93 días. Al utilizar Azure Metrics, los usuarios pueden buscar solicitudes autenticadas por SAS, destacando las cuentas de almacenamiento con uso de tokens SAS. ### Escaneo secreto Además, recomendamos utilizar herramientas de escaneo secreto para detectar tokens SAS filtrados o con privilegios excesivos en artefactos y activos expuestos públicamente, como aplicaciones móviles, sitios web y repositorios de GitHub, como se puede ver en El caso Microsoft. Para obtener más información sobre el escaneo de secretos en la nube, consulte nuestra charla reciente de la conferencia fwd:cloudsec 2023, "Escaneo de Internet en busca de exposiciones a la nube externa". ### Para clientes de Wiz Los clientes de Wiz pueden aprovechar las capacidades de escaneo secreto de Wiz para identificar tokens SAS en activos internos y externos y explorar sus permisos. Además, los clientes pueden utilizar Wiz CSPM para realizar un seguimiento de las cuentas de almacenamiento con soporte SAS. * Detectar tokens SAS: use esta [consulta](https://app.wiz.io/graph#~(query~(type~(~'SECRET_DATA)~select~true~where~(presignedURL_type~( IGUALDAD~(~'PresignedURLTypeAzureSASToken)))~relaciones~(~(tipo~(~(tipo~'PERMITS))~opcional~verdadero~con~(tipo~(~'STORAGE_ACCOUNT)~seleccione~verdadero))~(tipo ~(~(tipo~'INSTANCE_OF~reverso~verdadero))~con~(tipo~(~'SECRET_INSTANCE)~seleccione~verdadero~relaciones~(~(tipo~(~(tipo~'CONTIENE~reverso~verdadero)) ~con~(tipo~(~'CLOUD_RESOURCE)~seleccione~verdadero)))))))~vista~'tabla~columnas~(~(~'0~49)~(~'1~17)~(~ '2~17)~(~'3~17)))) para mostrar todos los tokens SAS en todos sus entornos de nube monitoreados. * Detectar tokens SAS con altos privilegios: use el siguiente control para detectar tokens SAS altamente privilegiados ubicados en cargas de trabajo expuestas públicamente. * Regla CSPM para bloquear tokens SAS: use la siguiente [Regla de configuración de la nube](https://app.wiz.io/graph#~(query~(type~(~'STORAGE_ACCOUNT)~select~true~ relaciones~(~(tipo~(~(tipo~'ALERTED_ON~reverse~true))~con~(tipo~(~'CONFIGURATION_FINDING)~select~true~where~(configurationRuleShortName~(EQUALS~(~'StorageAccount-026 )))))~(type~(~(type~'CONTAINS~reverse~true))~optional~true~with~(type~(~'SUBSCRIPTION)~select~true)))))) para realizar un seguimiento del almacenamiento Cuentas que permiten el uso de tokens SAS. Riesgos de seguridad en el proceso de IA ------------------------------------- A medida que las empresas adoptan En términos más generales, es importante que los equipos de seguridad comprendan los riesgos de seguridad inherentes en cada etapa del proceso de desarrollo de la IA. El incidente detallado en este blog es un ejemplo de dos de estos riesgos. El primero es compartir demasiado datos. Los investigadores recopilan y comparten cantidades masivas de datos externos e internos para construir la información de entrenamiento necesaria para sus modelos de IA. Esto plantea riesgos de seguridad inherentes relacionados con el intercambio de datos a gran escala. Es fundamental que los equipos de seguridad definan directrices claras para el intercambio externo de conjuntos de datos de IA. Como hemos visto en este caso, separar el conjunto de datos públicos de IA en una cuenta de almacenamiento dedicada podría haber limitado la exposición. El segundo es el riesgo de ataques a la cadena de suministro. Debido a permisos inadecuados, el token público otorgó acceso de escritura a la cuenta de almacenamiento que contiene los modelos de IA. Como se señaló anteriormente, inyectar código malicioso en los archivos del modelo podría haber provocado un ataque a la cadena de suministro contra otros investigadores que utilizan los modelos del repositorio. Los equipos de seguridad deben revisar y desinfectar los modelos de IA de fuentes externas, ya que pueden usarse como vector de ejecución remota de código. Conclusión --------------- El simple paso de compartir un conjunto de datos de IA provocó una importante filtración de datos, que contenía más de 38 TB de datos privados. La causa principal fue el uso de tokens Account SAS como mecanismo para compartir. Debido a la falta de supervisión y gobernanza, los tokens SAS suponen un riesgo para la seguridad y su uso debería ser lo más limitado posible. Estos tokens son muy difíciles de rastrear, ya que Microsoft no proporciona una forma centralizada de administrarlos dentro del portal de Azure. Además, estos tokens se pueden configurar para que duren 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 no es seguro y debe evitarse. En un ámbito más amplio, se pueden prevenir incidentes similares otorgando a los equipos de seguridad más visibilidad de los procesos de los equipos de investigación y desarrollo de IA. A medida que vemos una adopción más amplia de modelos de IA dentro de las empresas, es importante crear conciencia sobre los riesgos de seguridad relevantes en cada paso del proceso de desarrollo de la IA y asegurarse de que el equipo de seguridad trabaje en estrecha colaboración con los equipos de investigación y ciencia de datos para garantizar que se definan las barreras de seguridad adecuadas. . El relato de Microsoft sobre este problema está disponible en el [blog de MSRC] (https://msrc.microsoft.com/blog/2023/09/microsoft-mitigated-exposure-of-internal-information-in-a-storage-account- debido a un token-sas-demasiado-permisivo/). Cronología ------------- * Jul. 20 de diciembre de 2020: token SAS primero comprometido en GitHub; Vencimiento fijado para el 5 de octubre de 2021 * Oct. 6 de octubre de 2021: vencimiento del token SAS actualizado hasta el 6 de octubre de 2051 * Jun. 22 de junio de 2023: Wiz Research encuentra e informa el problema al MSRC * Jun. 24 de julio de 2023: token SAS invalidado por Microsoft * Jul. 7 de agosto de 2023: token SAS reemplazado en GitHub * Agosto. 16 de septiembre de 2023: Microsoft completa una investigación interna sobre el posible impacto * Sep. 18, 2023 – Divulgación pública **¡Manténgase en contacto! ** ------------------- ¡Hola! Somos Hillai Ben-Sasson (@hillai), Shir Tamari (@shirtamari), Nir Ohfeld (@nirohfeld ), Sagi Tzadik (@sagitz_) y Ronen Shustin ([@ronenshh](https://twitter. com/ronenshh)) del equipo de investigación de Wiz. Somos un grupo de hackers veteranos con un único objetivo: hacer de la nube un lugar más seguro para todos. Nos centramos principalmente en encontrar nuevos vectores de ataque en la nube y descubrir problemas de aislamiento en los proveedores de la nube. ¡Nos encantaría saber de usted! No dude en contactarnos en Twitter o por correo electrónico: research@wiz.io.