Aperçu de la vulnérabilité
Type de vulnérabilité: Injection SQL
Date de rapport: 10 Mars, 2025
Statut:Résolu et corrigé
Méthode de divulgation: Divulgation responsable par Searchlight Cyber/Asset Note
Versions contenant la résolution
Stable
2.174.94 (ou toute version commençant par 2.174 et se terminant par un numéro supérieur à 94 – par exemple 2.174.103)
Candidat
2.184.23 (ou toute version commençant par 2.184 et se terminant par un numéro supérieur à 23 – par exemple 2.184.35)
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)
Analyse de la portée et des causes profondes
La vulnérabilité permettait une injection SQL sur un terminal non authentifié via une charge utile spécialement conçue. Une analyse complète des causes profondes a été réalisée, identifiant que la vulnérabilité a été introduite dans la version 2.11.13, sorti le 2020-06-12Malgré de multiples évaluations d'intrusion internes et externes, le problème est resté indétecté en raison de la complexité 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é a été introduite en 2020 et que nos pratiques de développement internes se sont considérablement améliorées depuis. De plus, aucune autre vulnérabilité de ce type n'a été découverte dans le cadre de nos recherches.
Exposition et impact des données
Calendrier de découverte et de remédiation
- Date d'introduction: 2020-06-12 (v2.11.13)
- Date de rapport: 2025-03-10
- Patch déployé: Le jour même pour tous les clients hébergés (2025-03-10)
- Temps de réponse: Déploiement immédiat du correctif dès notification
Searchlight Cyber/Asset Note a publié ses conclusions plus tôt que prévu, ce qui a laissé certains clients sur site exposés pendant une courte période.
Nous avons aidé un certain nombre de ces clients dans leurs enquêtes pour trouver des preuves de compromission ou d’exploitation, mais jusqu’à présent, nous n’en avons trouvé aucune.
Fréquence et couverture
Nous effectuons chaque année des tests complets d'authentification et d'intrusion d'API par l'intermédiaire d'une société de sécurité tierce accréditée CREST afin de garantir des évaluations indépendantes et de haute qualité. Outre ces évaluations externes, des tests d'intrusion internes sont réalisés avant chaque version stable trimestrielle, ce qui nous permet d'identifier et de corriger proactivement les vulnérabilités potentielles tout au long de notre cycle de développement.
Méthodologie de test
Notre processus de tests d'intrusion comprend des tests authentifiés et non authentifiés afin de garantir une couverture complète de tous les niveaux d'accès. Ces évaluations sont réalisées par des équipes de sécurité internes et des spécialistes externes, offrant ainsi une évaluation complète de nos systèmes sous différents angles.
Dernière évaluation de sécurité (test de pénétration)
Un test de pénétration complet a été réalisé le 10 janvier 2025. Le résumé de gestion du rapport est disponible et peut être partagé sur demande pour plus 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 suivent les meilleures pratiques reconnues par l'industrie, notamment celles définies par l'OWASP. Cette formation est régulièrement mise à jour afin de garantir l'adéquation avec les dernières menaces et techniques d'atténuation.
Révision et automatisation du code
Toutes les modifications de code sont soumises à un processus d'approbation rigoureux en plusieurs étapes, incluant une revue par un membre senior de l'équipe de sécurité, spécifiquement chargé d'évaluer les risques potentiels. De plus, nous utilisons des outils de tests statiques de sécurité des applications (SAST) tout au long du processus de développement, permettant une détection précoce des vulnérabilités et favorisant 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 d'API ne puisse être réduit en raison d'exigences fonctionnelles essentielles, telles que la nécessité d'accepter les réponses des webhooks, nous continuons de nous concentrer sur le maintien et le renforcement continu de notre sécurité globale. Nous avons déjà procédé à 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, la récente analyse n'a identifié aucune vulnérabilité supplémentaire. Ces points de terminaison sont soigneusement évalués, surveillés et utilisés uniquement en cas d'absolue nécessité afin de minimiser les risques.
Segmentation des infrastructures
Dans nos environnements hébergés, une séparation fonctionnelle est appliquée entre les composants clés, notamment l'API, l'authentification et les services d'intégration, afin de réduire le risque de déplacement latéral 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 sont déchiffrées uniquement par l'API et les services d'authentification, garantissant ainsi une séparation solide entre le stockage des données et les mécanismes d'accès.
Validation de l'efficacité
Afin de renforcer notre dispositif de sécurité global, nous faisons appel à plusieurs sociétés de sécurité tierces pour assurer une supervision renforcée et une validation indépendante de nos systèmes. Parallèlement, nous élargissons et améliorons nos contrôles de sécurité internes afin de garantir une couverture plus étendue, une analyse plus approfondie et une amélioration continue à toutes les phases de développement et de déploiement.
Communications de sécurité
Nous reconnaissons que certains clients ont été informés de cette vulnérabilité par le biais d'une publication de recherche en sécurité tierce, avant même d'avoir reçu une communication directe de Halo. Cela est dû en partie à la publication inattendue du rapport externe, survenue alors que nous accompagnions encore activement nos clients sur site dans leur processus de mise à niveau.
Nous reconnaissons 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 les clients hébergés soient informés rapidement de l'application d'un correctif, quel que soit l'état d'avancement des déploiements sur site.