Rapport de vulnérabilité : plugin « ODBC Enrichment » de Guardsix (Logpoint)

Proof of Concept (PoC)

Le problème racine découle d’une absence de cloisonnement des droits côté backend. L’application omet de valider le rôle de l’utilisateur qui interroge certains endpoints restreints de l’API et les routes d’administration frontend.

Vulnérabilité 1 : Broken Access Control et exécution de requêtes SQL arbitraires

En situation réelle, un utilisateur compromis ou un insider disposant d’un simple profil basic_operator (strictement cantonné à la lecture des logs) peut s’affranchir de ses restrictions pour administrer les sources de données.

Scénario d’exploitation :

1. Authentification sur le portail Guardsix (Logpoint) avec un compte restreint (basic_operator) ;
2. Navigation forcée vers la route d’administration : https://<logpoint-ip>/#Enrichmentsources/sourceList ;
3. Le backend ne rejetant pas la requête, l’interface s’affiche et permet d’éditer n’importe quel connecteur ODBC en production ;
4. À ce stade, la surface est ouverte à l’exécution de requêtes SQL arbitraires, exécutées de manière transparente sur les serveurs de bases de données cibles avec les privilèges du compte configurés.

Vulnérabilité 2 : Vol d’identifiants et Mouvement Latéral via SSRF

L’accès illégitime découvert précédemment nous permet d’abuser d’un défaut logique de conception du plugin. Lors de la modification d’un connecteur, l’application conserve et réutilise systématiquement le credential mis en cache, sans l’invalider lorsque l’IP ou le Hostname cible est altéré. Ce comportement transforme le serveur Guardsix (Logpoint) en vecteur de SSRF pour exfiltrer des identifiants.

Scénario d’exploitation :

1. Via notre accès basic_operator élevé, nous éditons un connecteur de base de données valide ;
2. Sur un serveur de rebond contrôlé, nous montons un listener pour capturer les flux d’authentification (ex : msf auxiliary/server/capture/mssql ou Responder) ;
3. Dans la configuration du connecteur Guardsix (Logpoint), nous détournons le flux en remplaçant l’IP de la base légitime par celle de notre serveur attaquant ;
4. Nous laissons le champ du mot de passe sur sa valeur par défaut (encrypted), forçant le backend à piocher dans son coffre-fort ;
5. Le déclenchement de l’action « Test Connection » force le serveur Guardsix (Logpoint) à initier une connexion vers notre machine de capture ;
6. Résultat : Le SIEM s’authentifie sur notre listener et nous récupérons immédiatement le mot de passe en clair du compte configuré.

Impact et score CVSS

Cette chaîne d’exploitation permet un pivot critique depuis un simple compte opérateur vers l’ensemble de l’infrastructure de données :

• Confidentialité (Haute) : Exfiltration des secrets de production (credential dumping) via SSRF et accès total aux bases connectées.
• Intégrité (Haute) : Altération, falsification ou destruction de données via l’exécution de requêtes SQL arbitraires.
• Disponibilité (Haute) : Sabotage de la supervision ou DoS du serveur SQL (RCE potentielle via xp_cmdshell).

Score CVSS v4.0 : 7.7 (High)

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Versions affectées et correctifs

La vulnérabilité touche les périmètres suivants :

• Guardsix (Logpoint) : versions inférieures à la 7.9.0
• Plugin ODBC Enrichment : versions inférieures à la 5.2.1

La faille a été patchée par l’éditeur en révisant la logique métier : toute modification des paramètres de routage (Hôte, IP, Port) provoque désormais le flush immédiat des identifiants stockés. De plus, les décorateurs de vérification des droits ont été renforcés sur le backend.

Action de remédiation :

• Mise à niveau critique vers Guardsix (Logpoint) v7.9.0 et le module ODBC v5.2.1.

Timeline

Références

• Avis de sécurité Guardsix (Logpoint) : SSRF in ODBC Enrichment Source
• Advisory ID : LVD-2026-001
• CVE : CVE-2026-35548

Crédit

• Mickael Karatekin (SysDream)