Se encontró una vulnerabilidad crítica en las versiones 6.3.54.0 y 6.3.53.2 de Google Security Operations SOAR. Un usuario autenticado con permisos para subir archivos ZIP (por ejemplo, cuando importa casos de uso) podría subir un archivo ZIP capaz de escribir archivos en ubicaciones arbitrarias del sistema de archivos del servidor.

El sistema para extraer archivos de archivos ZIP no pudo evitar que los archivos dentro del archivo se escribieran fuera de la carpeta de destino prevista. Esto también se conoce como vulnerabilidad de salto de directorio o Zip Slip.

¿Qué debo hacer?

No se requiere que el cliente realice ninguna acción. Todos los clientes se actualizaron automáticamente a la versión corregida o superior: 6.3.54.1 o 6.3.53.3.

¿Qué vulnerabilidades se abordan?

Un atacante podría aprovechar esta vulnerabilidad para reemplazar archivos de la aplicación. Si se reemplaza un archivo JavaScript que usa la función de generación de informes, un atacante podría lograr la ejecución de código remoto (RCE) en la instancia de SOAR de Google SecOps. El atacante podría ejecutar su propio código en el servidor.

Los clientes pueden configurar Google SecOps para que ingiera datos de los buckets de Cloud Storage propiedad del cliente a través de un feed de transferencia. Hasta hace poco, Google SecOps proporcionaba una cuenta de servicio compartida que los clientes usaban para otorgar permiso al bucket. Existía una oportunidad para que la instancia de SecOps de Google de un cliente se pudiera configurar para transferir datos del bucket de Cloud Storage de otro cliente. Después de realizar un análisis de impacto, no encontramos ninguna explotación actual o anterior de esta vulnerabilidad. La vulnerabilidad estaba presente en todas las versiones de Google SecOps anteriores al 19 de septiembre de 2023.

¿Qué debo hacer?

Desde el 19 de septiembre de 2023, se actualizó Google SecOps para abordar esta vulnerabilidad. No se requiere que el cliente realice ninguna acción.

¿Qué vulnerabilidades se abordan?

Anteriormente, Google SecOps proporcionaba una cuenta de servicio compartida que los clientes usaban para otorgar permiso a un bucket. Debido a que diferentes clientes otorgaron el mismo permiso de cuenta de servicio de Google SecOps a sus buckets, existía un vector de explotación que permitía que el feed de un cliente accediera al bucket de otro cliente cuando se creaba o modificaba un feed. Este vector de explotación requería conocer el URI del bucket. Ahora, durante la creación o modificación de feeds, Google SecOps usa cuentas de servicio únicas para cada cliente.