Rapport d'intervention de sécurité : vulnérabilité liée à une injection SQL

Présentation générale de la vulnérabilité

‍

Type de vulnérabilité: Injection SQL
Date de signalement: 10 mars 2025
Statut: Résolue et corrigée
Méthode de divulgation: Divulgation responsable par Searchlight Cyber/Asset Note

‍

Versions comportant une résolution

Version stable
2.174.94 (ou toute version commençant par 2.174 et se terminant par un nombre supérieur à 94 – par exemple 2.174.103)
Version candidate
2.184.23 (ou toute version commençant par 2.184 et se terminant par un nombre supérieur à 23 – par exemple 2.184.35)
Version bêta
2.186.2 (ou toute version commençant par 2 et suivie d’un nombre supérieur à 186 – par exemple 2.187.1)

‍

Portée et analyse des causes profondes

Cette vulnérabilité permettait une injection SQL sur un point de terminaison non authentifié via une charge utile spécialement conçue. Une analyse complète des causes profondes a été menée, qui a permis d’identifier que la vulnérabilité avait été introduite dans la version 2.11.13, publiée le 12 juin 2020. Bien que le système ait fait l’objet de multiples tests d’intrusion internes et réalisés par des tiers, le problème est resté indétecté en raison de la nature complexe de la charge utile requise. Cela a considérablement réduit le risque d’exploitation ou de compromission des données.

Il convient de noter que cette vulnérabilité est apparue en 2020 et que nos pratiques de développement internes se sont considérablement améliorées depuis lors. De plus, aucune autre vulnérabilité de ce type n'a été découverte dans le cadre de ces recherches.

‍

Fuite de données et conséquences

Une enquête a été menée sur les journaux d'Azure Application Insights et d'AWS WAF pour les clients utilisant des services cloud ou hébergés. D'après cette analyse, aucune de compromission des données des clients n'a été identifiée. L'analyse suggère qu'une exploitation nécessiterait un haut degré de spécificité, ce qui limite la probabilité d'une exploitation malveillante généralisée et réussie.

‍

Calendrier des étapes de détection et d'assainissement

• Date de lancement: 12 juin 2020 (v2.11.13)

• Date de signalement: 10 mars 2025

• Déploiement du correctif: le jour même pour tous les clients hébergés (10 mars 2025)

• Délai de réponse: déploiement immédiat du correctif dès réception de la notification

Searchlight Cyber/Asset Note a publié ses conclusions plus tôt que prévu, ce qui a exposé certains clients utilisant une solution sur site à un risque pendant une brève période.

Nous avons aidé plusieurs de ces clients à mener des enquêtes visant à mettre en évidence des signes de compromission ou d'exploitation, mais nous n'en avons trouvé aucun à ce jour.

‍

Fréquence et couverture

Nous réalisons chaque année des tests d'authentification complets et des tests d'intrusion sur nos API par l'intermédiaire d'un cabinet de sécurité tiers accrédité CREST, afin de garantir des évaluations indépendantes et de haute qualité. Outre ces audits externes, des tests d'intrusion internes sont effectués avant chaque version stable trimestrielle, ce qui nous permet d'identifier et de corriger de manière proactive les vulnérabilités potentielles au cours de notre cycle de développement.

‍

Méthodologie de test

Notre processus de tests d'intrusion comprend à la fois des tests avec et sans authentification afin de garantir une couverture exhaustive à tous les niveaux d'accès. Ces évaluations sont menées conjointement par nos équipes de sécurité internes et des spécialistes externes, ce qui permet d'obtenir une analyse complète de nos systèmes sous différents angles.

‍

Dernière évaluation de sécurité (test d'intrusion)

Un test d'intrusion complet a été réalisé le 10 janvier 2025. Le résumé du rapport est disponible et peut être communiqué sur simple demande, dans un souci de transparence.

‍

Normes de codage et formation des développeurs

Tous les développeurs de Halo sont formés aux normes de codage sécurisé et respectent les bonnes pratiques reconnues par le secteur, notamment celles définies par l'OWASP. Cette formation est actualisée régulièrement afin de s'adapter aux dernières menaces et aux techniques de prévention correspondantes.

‍

Révision du code et automatisation

Toutes les modifications apportées au code sont soumises à un processus de validation rigoureux en plusieurs étapes, qui comprend notamment l'examen par un membre expérimenté de l'équipe de sécurité, chargé spécifiquement d'évaluer les risques potentiels pour la sécurité. De plus, nous utilisons des outils de test statique de sécurité des applications (SAST) tout au long du processus de développement, ce qui permet de détecter rapidement les vulnérabilités et de favoriser des pratiques de codage sécurisées dès le départ.

‍

Gestion de la surface d'attaque

Bien que le nombre de points de terminaison API ne puisse être réduit en raison d’exigences fonctionnelles essentielles — telles que la nécessité d’accepter les réponses des webhooks —, notre priorité reste de maintenir et de renforcer en permanence notre niveau global de sécurité. Nous procédons déjà à des évaluations rigoureuses des points de terminaison non authentifiés dans le cadre de nos pratiques de sécurité habituelles. C’est pourquoi, malgré la présence de plusieurs points de terminaison non authentifiés, l’examen récent n’a pas identifié de vulnérabilités supplémentaires. Ces points de terminaison sont soigneusement évalués et surveillés, et ne sont utilisés qu’en cas d’absolue nécessité afin de minimiser les risques.

‍

Segmentation des infrastructures

Dans nos environnements hébergés, la séparation fonctionnelle est appliquée à l’ensemble des composants clés — notamment l’API, l’authentification et les services d’intégration — afin de réduire le risque de propagation latérale en cas de compromission. De plus, les bases de données et les serveurs de bases de données sont isolés des couches applicatives, et toutes les données chiffrées ne sont déchiffrées que par l’API et les services d’authentification, ce qui garantit une séparation rigoureuse entre le stockage des données et les mécanismes d’accès.

‍

Validation de l'efficacité

Afin de renforcer notre dispositif global de sécurité, nous faisons appel à plusieurs sociétés de sécurité tierces pour assurer une surveillance supplémentaire et une validation indépendante de nos systèmes. Parallèlement, nous étendons et renforçons nos contrôles de sécurité internes afin de garantir une couverture plus large, une analyse plus approfondie et une amélioration continue à toutes les étapes du développement et du déploiement.

‍

Communication en matière de sécurité

Nous reconnaissons que certains clients ont pris connaissance de cette vulnérabilité par le biais d’une publication d’un chercheur en sécurité tiers, avant d’avoir reçu une communication directe de la part de Halo. Cela s’explique en partie par le moment inattendu de la publication de ce rapport externe, qui a eu lieu alors que nous étions encore en train d’accompagner activement nos clients sur site dans leur processus de mise à niveau.

Nous sommes conscients de l'importance d'une communication proactive et rapide, et avons depuis pris des mesures pour améliorer nos procédures internes. À l'avenir, nous veillerons à ce que tous nos clients hébergés soient informés sans délai dès qu'un correctif aura été appliqué, quel que soit l'état d'avancement des déploiements sur site.

‍