Une faille critique a été détectée dans les versions 6.3.54.0 et 6.3.53.2 de Google Security Operations SOAR. Un utilisateur authentifié disposant des autorisations nécessaires pour importer des fichiers ZIP (par exemple, lors de l'importation de cas d'utilisation) peut importer une archive ZIP capable d'écrire des fichiers à des emplacements arbitraires sur le système de fichiers du serveur.

Le système d'extraction des fichiers des archives ZIP n'a pas pu empêcher l'écriture des fichiers de l'archive en dehors du dossier de destination prévu. Cette faille est également appelée "traversée de répertoire" ou "ZipSlip".

Que dois-je faire ?

Aucune action n'est requise de la part du client. Tous les clients ont été automatiquement mis à niveau vers la version corrigée ou une version ultérieure : 6.3.54.1 ou 6.3.53.3.

Quelles failles sont corrigées ?

Un pirate informatique pourrait exploiter cette faille pour écraser les fichiers de l'application. En écrasant un fichier JavaScript utilisé par la fonctionnalité de génération de rapports, un pirate informatique pourrait exécuter du code à distance (RCE) sur l'instance Google SecOps SOAR. L'auteur de l'attaque peut exécuter son propre code sur le serveur.

Les clients peuvent configurer Google SecOps pour ingérer des données provenant de buckets Cloud Storage leur appartenant à l'aide d'un flux d'ingestion. Jusqu'à récemment, Google SecOps fournissait un compte de service partagé que les clients utilisaient pour accorder des autorisations au bucket. Une opportunité existait pour qu'une instance Google SecOps d'un client puisse être configurée pour ingérer des données à partir du bucket Cloud Storage d'un autre client. Après avoir effectué une analyse de l'impact, nous n'avons trouvé aucune exploitation actuelle ou antérieure de cette faille. La faille était présente dans toutes les versions de Google SecOps antérieures au 19 septembre 2023.

Que dois-je faire ?

Depuis le 19 septembre 2023, Google SecOps a été mis à jour pour corriger cette faille. Aucune action n'est requise de la part du client.

Quelles failles sont corrigées ?

Auparavant, Google SecOps fournissait un compte de service partagé que les clients utilisaient pour accorder des autorisations à un bucket. Étant donné que différents clients ont accordé la même autorisation de compte de service Google SecOps à leur bucket, il existait un vecteur d'exploitation qui permettait au flux d'un client d'accéder au bucket d'un autre client lors de la création ou de la modification d'un flux. Ce vecteur d'exploitation nécessitait de connaître l'URI du bucket. Désormais, lors de la création ou de la modification d'un flux, Google SecOps utilise des comptes de service uniques pour chaque client.