Claude a découvert 493 failles de sécurité dans 25 projets open source, dont des protections qui semblaient activées alors que les logiciels autorisaient toujours des accès non prévus. Certains problèmes étaient restés dissimulés dans le code pendant des années.
Les recherches d’Anthropic sur l’IA ont examiné les interactions entre les paramètres de sécurité et la quantité de code restant accessible avant l’authentification. Elles ont notamment révélé des protections qui échouaient sans avertissement, laissant les logiciels exposés au-delà des restrictions prévues.
Une découverte a incité les développeurs d’OpenSSH à revoir les contrôles de sécurité de cet outil d’accès à distance très répandu. D’autres cas ont suscité des inquiétudes concernant des faiblesses que les administrateurs pourraient ne jamais remarquer lors des vérifications de configuration habituelles.
Des conflits de configuration laissaient les contrôles de sécurité désactivés
Les serveurs configurés pour exiger des certificats clients valides pouvaient tout de même accepter des connexions sans ces certificats en raison d’un conflit de configuration qui persistait depuis 21 ans. Au lieu de retarder la vérification comme prévu, un autre paramètre désactivait entièrement le contrôle, sans avertir les administrateurs.
Claude a analysé plus de cinq millions de lignes de code et recensé plus de 17 000 options de configuration, dont 3 842 associées à des fonctions de sécurité. Son enquête a identifié plusieurs problèmes liés à des combinaisons de paramètres que les logiciels acceptaient sans générer d’erreur :
- 94 contrôles désactivés silencieusement.Parmi les 162 combinaisons de configuration sensibles à la sécurité acceptées sans avertissement ni comportement documenté, 94 désactivaient une protection existante.
- 68 configurations incohérentes.D’autres combinaisons laissaient accessibles des chemins de connexion désactivés ou permettaient à l’ordre des paramètres de déterminer quelle restriction prévalait.
- Quatre projets présentant des règles de refus inefficaces.Lorsque les recherches DNS inversées étaient désactivées, les serveurs comparaient les restrictions fondées sur le nom d’hôte à des adresses IP numériques. Comme les motifs ne pouvaient pas correspondre, les règles d’accès prévues ne bloquaient pas les connexions.
Selon Anthropic, l’enquête comprenait le suivi de l’exécution des logiciels afin d’évaluer si les faiblesses de configuration suspectées affectaient réellement les contrôles de sécurité.
Les correctifs d’OpenSSH ont réduit le code accessible avant l’authentification
Dans 11 projets conçus pour des utilisateurs authentifiés, Claude a détecté 93 zones de code inutiles accessibles avant la connexion.
OpenSSH, un outil très répandu pour l’accès distant sécurisé, laissait environ 4 500 lignes de code expérimental de signature post-quantique accessibles à des clients non authentifiés dans la version 10.4, même lorsque l’algorithme était désactivé. Son serveur analysait les clés reçues avant de vérifier si la méthode de signature était autorisée.
Les développeurs ont déplacé la vérification de l’algorithme avant l’analyse des clés dans la version 10.5, mais deux failles subsistaient. Les clients pouvaient annoncer un algorithme approuvé tout en envoyant un autre type de clé, tandis que le traitement des certificats pouvait encore vérifier les signatures avant d’appliquer les restrictions configurées.
La version 10.6 a introduit des contrôles supplémentaires dans l’analyseur, réduisant d’environ 20 % le code accessible avant l’authentification, selon les mesures d’Anthropic.
Réduire l’exposition du code avant authentification peut limiter les vecteurs d’attaque potentiels, même que la présence de code accessible ne suffit pas, à elle seule, à établir l’existence d’une vulnérabilité exploitable.
Les équipes de sécurité doivent valider les protections déployées
Pour les entreprises qui s’appuient sur des passerelles d’accès à distance et des services exposés sur Internet, les conclusions de Claude révèlent un écart entre les configurations approuvées et le comportement réel des logiciels.
Un serveur peut disposer des correctifs à jour et de restrictions correctement documentées, mais les interactions entre ses paramètres peuvent tout de même permettre des accès non prévus. Les contrôles de sécurité habituels risquent de ne pas détecter cet écart.
Imaginons une organisation qui utilise une authentification reposant uniquement sur des certificats pour protéger un service critique. Une tentative de connexion contrôlée sans identifiants valides révélerait si le serveur applique la restriction dans sa configuration déployée. Inclure de tels contrôles dans les évaluations des vulnérabilités peut révéler des problèmes que les analyses CVE classiques et les inventaires de correctifs pourraient manquer.
Pour les équipes de sécurité qui gèrent une infrastructure étendue, la gestion de la surface d’attaque peut aider à identifier les systèmes accessibles depuis l’extérieur où ces faiblesses présenteraient le plus grand risque.
Les résultats générés par l’IA doivent toujours être vérifiés au regard des versions concernées des logiciels, mais une exposition confirmée peut justifier une remédiation même en l’absence de CVE publiée.
À mesure que la recherche automatisée révèle davantage de problèmes négligés, les équipes de sécurité devront distinguer les faiblesses théoriques d’une exposition démontrable. Les éléments attestant de l’exploitabilité, les configurations concernées et l’impact potentiel sur l’activité doivent guider le choix des correctifs à traiter en priorité.
Plus d’actualités en cybersécurité : un outil de test de sécurité alimenté par l’IA est apparu dans des cyberattaques contre des entreprises japonaises, suscitant des inquiétudes quant à son utilisation abusive.