Estudio técnico de la vulnerabilidad CVE-2025-5548
Dans ce travail, on analyse la vulnérabilité CVE-2025-5548, associée à un débordement de tampon sur la pile présent dans FreeFloat FTP Server v1.0. L'objectif principal du laboratoire est de comprendre comment une application vulnérable se comporte face à des entrées manipulées et d'observer, dans un environnement contrôlé, comment une défaillance de validation peut finir par affecter le flux d'exécution du programme.
Le développement du dépôt ne se limite pas à montrer le résultat final, mais reprend le processus complet de recherche : préparation de l'environnement, sélection des outils, observation de la défaillance, analyse de la mémoire et validation de l'impact réel de la vulnérabilité.
Le travail est conçu en deux blocs distincts.
Dans cette section, on explique comment l'environnement de pratique a été monté, quel système d'exploitation a été utilisé, quelle est l'application vulnérable et quels outils ont été jugés nécessaires pour mener l'analyse.
La deuxième partie se concentre sur la partie pratique. On y décrit le processus suivi pour détecter la défaillance, confirmer la corruption mémoire, étudier la réécriture des registres et vérifier comment la vulnérabilité peut être exploitée.
La pratique a été réalisée sur une machine virtuelle avec Windows 11 Pro 25H2 (Build 26200.6584). Le logiciel vulnérable sélectionné a été FreeFloat FTP Server v1.0, une ancienne application qui convient à ce type d'exercices car elle manque de nombreuses protections habituelles dans les programmes actuels.
Le réseau de la machine virtuelle a été configuré en mode NAT, ce qui a permis l'accès à Internet pour installer les dépendances, télécharger des outils et maintenir la connectivité de base du laboratoire.
Pour couvrir toutes les phases de l'analyse, il a été nécessaire de s'appuyer sur plusieurs utilitaires. Certains ont été utilisés pour préparer l'environnement, d'autres pour examiner le binaire et d'autres encore pour observer le comportement du processus lors de la défaillance.
Il a été utilisé pour télécharger des dépôts, maintenir organisées certaines ressources et faciliter la gestion du matériel utilisé durant la recherche.
Il a été utilisé comme support pour vérifier la connectivité, identifier le service exposé et confirmer que la cible répondait correctement sur le port attendu.
Il a été installé pour disposer de bibliothèques, d'en-têtes et d'outils utiles pour les tâches de débogage et d'analyse bas niveau dans le système Windows.
Il a été utilisé pour des modifications rapides, la révision de scripts et la manipulation simple de chaînes ou de données de test.
Il a servi d'environnement confortable pour écrire des scripts, tester des automatisations et travailler avec du code de manière plus ordonnée.
Il a été utile notamment lorsqu'il a fallu réviser des scripts plus longs ou déboguer la logique liée à la construction des charges.
Deux versions ont été envisagées :
Il a été nécessaire pour exécuter Ghidra, car cet outil est développé sur Java.
Il a été utilisé pour observer l'état du programme lors de l'exécution, vérifier les registres, examiner la mémoire et analyser le point exact où la défaillance se produit.
Il a été employé dans la phase d'analyse statique pour examiner le binaire et localiser des fonctions suspectes du point de vue de la sécurité.
Il a été utilisé comme support pour décompiler et mieux comprendre la logique interne du programme vulnérable.
Ce complément a facilité des tâches comme la création de motifs, le calcul du décalage (offset) et l'identification des caractères problématiques dans la charge.
Le composant principal du laboratoire a été FreeFloat FTP Server v1.0, qui agit comme système cible dans la preuve de concept. Son intérêt réside dans le fait qu'il intègre une vulnérabilité classique de débordement sur la pile, ce qui en fait un cas très approprié pour une analyse formative.
Bien qu'il existe des machines virtuelles déjà préparées pour ce type d'exercices, dans ce cas, on a choisi de documenter l'environnement et de justifier les outils utilisés. Cela permet de mieux comprendre pourquoi chaque application fait partie du laboratoire et quel rôle elle joue durant l'analyse.
La première étape a consisté à vérifier que le service FTP était accessible et fonctionnait correctement. Une fois la connectivité confirmée, le binaire a été examiné à l'aide d'outils d'analyse statique pour localiser d'éventuels points faibles liés à la gestion des chaînes.
Lors de cette révision, des fonctions non sécurisées comme strcpy et strcat sont apparues, ce qui a renforcé la suspicion que le service pouvait être vulnérable à des entrées trop longues. Plusieurs commandes du protocole FTP susceptibles de recevoir des données contrôlées par l'utilisateur ont également été examinées, et l'une d'elles a été sélectionnée comme candidate principale pour les tests.
Sur cette base, le processus a été chargé dans un débogueur pour observer son comportement lors de l'exécution.
La phase suivante a consisté à envoyer des chaînes de plus en plus longues pour vérifier si le programme cessait de répondre correctement. Cette procédure a permis de constater qu'à partir d'une certaine taille, le service échouait et finissait par provoquer une altération en mémoire.
Ce comportement a confirmé qu'il ne s'agissait pas d'une simple erreur de validation superficielle, mais d'une corruption réelle affectant le flux du processus.
Après avoir provoqué la défaillance, il a été nécessaire de calculer avec précision le nombre d'octets nécessaires pour atteindre l'adresse de retour. Pour cela, on a utilisé une séquence non répétitive, de sorte que la valeur reflétée dans EIP au moment du crash puisse être reliée à une position exacte dans l'entrée envoyée.
Grâce à cette procédure, on a obtenu le décalage précis nécessaire pour écraser le registre de contrôle.
Avec le décalage connu, un nouveau test a été préparé dans lequel l'adresse de retour a été remplacée par une valeur facilement reconnaissable. L'objectif était de vérifier si le programme permettait de modifier EIP de manière contrôlée.
Le test a été satisfaisant, car le débogueur a montré que le registre contenait exactement la valeur introduite. Cela démontrait qu'il était possible d'altérer le flux d'exécution et de le rediriger vers une adresse choisie.
Une fois ce point atteint, on a analysé quels octets pouvaient interférer avec la charge utile. Dans ce type de vulnérabilités, il est courant que certains caractères provoquent des troncatures, des changements inattendus ou une fin prématurée de la chaîne.
Par des comparaisons successives en mémoire, plusieurs bad characters ont été identifiés, parmi lesquels :
\x00\x0a\x0dLes détecter a été important pour construire une charge finale stable et compatible avec le comportement du programme vulnérable.
L'étape suivante a consisté à trouver une adresse appropriée permettant de rediriger l'exécution vers la zone mémoire où la charge serait logée. Cette analyse devait être faite en tenant compte du système d'exploitation et des protections actives, car certaines adresses ne sont pas stables entre les exécutions.
Dans le laboratoire, on a localisé une référence valide permettant de lier la réécriture du flux avec l'entrée contrôlée par l'attaquant.
Avec le contrôle du flux déjà validé, une shellcode compatible avec les restrictions découvertes précédemment a été construite. De plus, on a ajouté une zone préalable d'instructions neutres (NOP) pour faciliter l'arrivée sécurisée du CPU au début de la charge, même en cas de légère déviation dans la position attendue.
Cette étape a été importante pour augmenter la fiabilité de l'exécution.
Dans la dernière phase, la charge complète a été envoyée contre le service vulnérable pendant qu'un listener était maintenu à l'écoute sur la machine attaquante. Le résultat a été l'établissement d'une connexion à distance avec le système cible, confirmant ainsi que la vulnérabilité permet non seulement de provoquer un plantage du programme, mais aussi d'obtenir une exécution contrôlée.
Cela démontre l'impact réel de la défaillance et justifie sa pertinence du point de vue de la sécurité offensive et défensive.
L'étude de CVE-2025-5548 montre clairement comment une ancienne application, dépourvue de mécanismes de protection modernes, peut être vulnérable à des techniques d'exploitation classiques basées sur la corruption mémoire.
Tout au long du laboratoire, plusieurs étapes fondamentales ont été parcourues : la préparation de l'environnement, l'observation initiale de la défaillance, la validation du débordement, le contrôle du registre d'exécution, le débogage de la charge et la vérification du résultat final.
Au-delà du test technique, ce cas sert à comprendre pourquoi l'utilisation de fonctions non sécurisées et l'absence de mesures de protection restent un risque important dans les logiciels hérités. C'est pourquoi ce type d'exercices est particulièrement utile pour consolider les connaissances en rétro-ingénierie, analyse de vulnérabilités et exploitation dans des environnements contrôlés.