Microsoft AI reveló involuntariamente un secreto que otorga acceso a 38TB de datos confidenciales durante 3 años

La IA de Microsoft reveló accidentalmente un secreto que otorga acceso a 38TB de datos confidenciales durante 3 años

El equipo de investigación de WIZ descubrió recientemente que un token SAS sobreprovisionado había estado expuesto en GitHub durante casi tres años. Este token otorgaba acceso a un enorme tesoro de datos privados de 38 terabytes. Este almacenamiento en Azure contenía secretos adicionales, como claves SSH privadas, ocultas dentro de las copias de seguridad de disco de dos empleados de Microsoft. Esta revelación destaca la importancia de robustas medidas de seguridad de datos.

¿Qué sucedió?

WIZ Research reveló recientemente un incidente de exposición de datos encontrado en el repositorio AI de GitHub de Microsoft el 23 de junio de 2023.

Los investigadores que gestionaban GitHub utilizaron una función de intercambio de almacenamiento en Azure a través de un token SAS para dar acceso a un conjunto de datos de entrenamiento de IA de código abierto.

Este token fue mal configurado, dando acceso a todo el almacenamiento en la nube de la cuenta en lugar del conjunto de datos previsto.

• ¿Por qué los humanos temen a la inteligencia artificial AI?
• ¿Pueden los Modelos de Lenguaje Grandes Actuar y Razonar Verdaderamente? Investigadores de la Universidad de Illinois en Urbana-Champaign Introducen LATS para Mejorar la Toma de Decisiones
• El Mejor Algoritmo de Optimización para tu Red Neuronal

Este almacenamiento comprendía 38TB de datos, incluida una copia de seguridad de disco de dos estaciones de trabajo de empleados con secretos, claves privadas, contraseñas y más de 30.000 mensajes internos de Microsoft Teams.

Los SAS (Shared Access Signatures) son URLs firmados para compartir recursos de almacenamiento de Azure. Están configurados con controles detallados sobre cómo un cliente puede acceder a los datos: qué recursos se exponen (cuenta completa, contenedor o selección de archivos), con qué permisos y durante cuánto tiempo. Consulte la documentación de almacenamiento de Azure.

Después de revelar el incidente a Microsoft, el token SAS fue invalidado. Desde su primera confirmación en GitHub (20 de julio de 2020) hasta su revocación, casi tres años transcurrieron. Consulte la línea de tiempo presentada por el equipo de WIZ Research:

Sin embargo, como enfatizó el equipo de investigación de WIZ, hubo una mala configuración con la Firma de Acceso Compartido (SAS).

Exposición de datos

El token permitía que cualquier persona accediera a otros 38TB de datos, incluidos datos sensibles como claves secretas, contraseñas personales y más de 30.000 mensajes internos de Microsoft Teams de cientos de empleados de Microsoft.

A continuación se muestra un fragmento de algunos de los datos más sensibles recuperados por el equipo de Wiz:

Como destacaron los investigadores, esto podría haber permitido a un atacante inyectar código malicioso en el blob de almacenamiento que luego podría ejecutarse automáticamente cada vez que un usuario (presumiblemente un investigador de IA) confiara en la reputación de Microsoft, lo que podría haber provocado un ataque de cadena de suministro.

Riesgos de seguridad

Según los investigadores, los tokens SAS de cuenta como el presentado en su investigación presentan un alto riesgo de seguridad. Esto se debe a que estos tokens son permisivos y de larga duración, escapando del perímetro de monitoreo de los administradores.

Cuando un usuario genera un nuevo token, este es firmado por el navegador y no desencadena ningún evento de Azure. Para revocar un token, un administrador debe rotar la clave de cuenta de firma, revocando así todos los demás tokens a la vez.

Irónicamente, el riesgo de seguridad de una característica del producto de Microsoft (tokens SAS de Azure) causó un incidente para un equipo de investigación de Microsoft, un riesgo al que hace referencia la segunda versión de la matriz de amenazas de Microsoft para servicios de almacenamiento:

Expansión de secretos

Este ejemplo destaca perfectamente el problema generalizado de la expansión de secretos dentro de las organizaciones, incluso aquellas con medidas de seguridad avanzadas. De manera intrigante, resalta cómo un equipo de investigación de IA, o cualquier equipo de datos, puede crear de forma independiente tokens que podrían poner en peligro potencialmente a la organización. Estos tokens pueden evitar inteligentemente las salvaguardias de seguridad diseñadas para proteger el entorno.

Estrategias de mitigación

Para usuarios de Azure Storage:

1 – Evite los tokens SAS de cuenta

La falta de monitoreo convierte esta característica en un agujero de seguridad en su perímetro. Una mejor manera de compartir datos externamente es utilizando un SAS de servicio con una Política de Acceso Almacenada. Esta característica vincula un token SAS a una política, lo que proporciona la capacidad de administrar centralmente las políticas de los tokens.

Mejor aún, si no necesitas utilizar esta característica de uso compartido de Azure Storage, simplemente desactiva el acceso SAS para cada cuenta que poseas.

2 – Habilitar Azure Storage Analytics

El uso de tokens SAS activos se puede monitorear a través de los registros de Storage Analytics para cada una de tus cuentas de almacenamiento. Azure Metrics permite el monitoreo de solicitudes autenticadas mediante SAS e identifica las cuentas de almacenamiento que han sido accedidas a través de tokens SAS, durante un periodo de hasta 93 días.

Para Todos:

1 – Audita tu Perímetro de Github en busca de Credenciales Sensibles

Con alrededor de 90 millones de cuentas de desarrolladores, 300 millones de repositorios alojados y 4 millones de organizaciones activas, incluyendo el 90% de las empresas Fortune 100, GitHub posee una superficie de ataque mucho más grande de lo que se ve a simple vista.

El año pasado, GitGuardian descubrió 10 millones de secretos filtrados en repositorios públicos, un aumento del 67% con respecto al año anterior.

GitHub debe ser monitoreado activamente como parte del perímetro de seguridad de cualquier organización. Los incidentes que involucran credenciales filtradas en la plataforma continúan causando brechas masivas en grandes empresas, y este agujero de seguridad en el caparazón protector de Microsoft no dejó de recordarnos la brecha de datos de Toyota hace un año.

El 7 de octubre de 2022, Toyota, el fabricante de automóviles japonés, reveló que había expuesto accidentalmente una credencial que permitía el acceso a datos de clientes en un repositorio público de GitHub durante casi 5 años. El código fue público desde diciembre de 2017 hasta septiembre de 2022.

Si tu empresa tiene equipos de desarrollo, es probable que algunos de los secretos de tu empresa (claves de API, tokens, contraseñas) terminen en repositorios públicos de GitHub. Por lo tanto, se recomienda encarecidamente auditar la superficie de ataque de GitHub como parte de tu programa de gestión de superficie de ataque.

Palabras Finales

Toda organización, independientemente de su tamaño, debe estar preparada para enfrentar una amplia gama de riesgos emergentes. Estos riesgos a menudo surgen de una supervisión insuficiente de las extensas operaciones de software dentro de las empresas modernas de hoy en día. En este caso, un equipo de investigación de IA creó y expuso inadvertidamente un enlace de uso compartido de almacenamiento en la nube mal configurado, eludiendo las barreras de seguridad. Pero ¿cuántos otros departamentos – soporte, ventas, operaciones o marketing – podrían encontrarse en una situación similar? La creciente dependencia del software, los datos y los servicios digitales amplifica los riesgos cibernéticos a escala global.

Combatir la propagación de información confidencial y los riesgos asociados requiere reevaluar las capacidades de supervisión y gobierno de los equipos de seguridad.

We will continue to update Zepes; if you have any questions or suggestions, please contact us!