Les clés AES statiques permettent aux attaquants de déchiffrer les jetons d’accès et d’exécuter du code à distance, déclenchant ainsi des conseils urgents en matière de correctifs.
Les entreprises qui s’appuient sur les services de partage de fichiers de Gladinet sont confrontées à une nouvelle série de correctifs Zero Day, cette fois pour empêcher les attaquants d’abuser des clés cryptographiques directement intégrées dans ses plates-formes CentreStack et Triofox.
La société de cybersécurité Huntress a averti que les attaquants abusent déjà des clés codées en dur pour effectuer l’exécution de code à distance (RCE) sur les serveurs concernés.
« L’implémentation AES des produits CentreStack et Triofox de Gladinet contient des clés cryptographiques codées en dur », ont déclaré les chercheurs de Huntress dans un article de blog. « Nous constatons que des attaquants ciblent cette faille au sein de notre clientèle. »
Comme pour tout serveur connecté à Internet, l’exécution de code à distance sur CentreStack ou Triofox peut potentiellement conduire au déploiement de logiciels malveillants, à la persistance de portes dérobées et au vol d’informations d’identification. Huntress a exhorté tous les clients CentreStack/Triofox à mettre à jour vers la dernière version, 16.12.10420.56791, affirmant que neuf de ses clients entreprises avaient déjà été concernés.
Clés codées en dur, conséquences plus graves
Au cœur du problème se trouve un échec de conception dans la façon dont CentreStack et Triofox génèrent les clés cryptographiques utilisées pour chiffrer les jetons d’accès que les plates-formes utilisent pour contrôler qui peut récupérer quels fichiers. Huntress a découvert que le serveur s’appuie sur une fonction appelée « GenerateSecKey() » pour produire la clé AES et le vecteur d’initialisation (IV) pour le cryptage des tickets – mais au lieu de générer des valeurs uniques, la fonction renvoie les mêmes chaînes statiques de 100 octets à chaque fois que le service s’exécute.
« Comme les clés ne changent jamais, nous pourrions les extraire de la mémoire une seule fois et les utiliser pour décrypter n’importe quel ticket généré par le serveur ou pire, chiffrer le nôtre », ont déclaré les chercheurs, ajoutant que les clés étaient des chaînes statiques de texte chinois et japonais.
Grâce à cette capacité, un adversaire peut demander n’importe quel fichier que le serveur est capable de servir, y compris le fichier sensible « web.config » qui contient la clé machine ASP.NET.
Avec la clé de la machine en main, les attaquants peuvent générer des charges utiles ViewState malveillantes auxquelles le serveur fera confiance, permettant ainsi l’exécution de code à distance via la désérialisation ASP.NET. Les attaques de désérialisation exploitent une analyse non sécurisée d’objets sérialisés (comme ViewState dans ASP.NET) pour injecter des charges utiles malveillantes qui s’exécutent avec les privilèges du service Web.
Patcher maintenant
Huntress a identifié plusieurs attaques actives, l’acteur menaçant tentant d’abord d’exploiter CVE-2025-11371, un bug d’inclusion de fichiers locaux non authentifié précédemment divulgué dans CentreStack/Triofox, suivi du nouvel exploit. Les deux ont permis aux attaquants d’obtenir le fichier web.config contenant la clé machine.
Aucune condition préalable telle que des informations d’identification valides ou un accès privilégié n’est nécessaire pour une attaque réussie au-delà de la connaissance des clés par défaut. Pour atténuer le risque, Huntress a exhorté tous les clients à mettre à jour immédiatement vers les dernières versions publiées par Gladinet le 8 décembre, car celles-ci contiennent des correctifs pour la cryptographie non sécurisée.
Lorsqu’une application immédiate de correctifs n’est pas réalisable, les modifications de configuration visant à remplacer les clés machine par des valeurs aléatoires peuvent réduire les risques jusqu’au déploiement des mises à jour. De plus, l’équipe Huntress a partagé la requête GET chiffrée pour web.config comme indicateur de compromission (IOC).
Gladinet n’a pas réussi à corriger complètement une faille similaire liée aux clés codées en dur, car les criminels ont trouvé un moyen de réactiver les conditions d’exploitation sur les systèmes corrigés.
