Studio tecnico della vulnerabilità CVE-2025-5548
In questo lavoro viene analizzata la vulnerabilità CVE-2025-5548, associata a un overflow del buffer nello stack presente in FreeFloat FTP Server v1.0. L'obiettivo principale del laboratorio è comprendere come si comporta un'applicazione vulnerabile di fronte a input manipolati e osservare, in un ambiente controllato, come un errore di validazione possa finire per influenzare il flusso di esecuzione del programma.
Lo sviluppo del repository non si limita a mostrare il risultato finale, ma raccoglie l'intero processo di ricerca: preparazione dell'ambiente, selezione degli strumenti, osservazione del fallimento, analisi della memoria e validazione dell'impatto reale della vulnerabilità.
Il lavoro è strutturato in due blocchi distinti.
In questa sezione viene spiegato come è stato allestito l'ambiente di pratica, quale sistema operativo è stato utilizzato, qual è l'applicazione vulnerabile e quali strumenti sono stati ritenuti necessari per condurre l'analisi.
La seconda parte si concentra sulla parte pratica. Qui viene descritto il processo seguito per rilevare l'errore, confermare la corruzione della memoria, studiare la sovrascrittura dei registri e verificare come la vulnerabilità possa essere sfruttata.
La pratica è stata realizzata su una macchina virtuale con Windows 11 Pro 25H2 (Build 26200.6584). Il software vulnerabile selezionato è stato FreeFloat FTP Server v1.0, un'applicazione datata che risulta adatta per questo tipo di esercizi per la mancanza di molte delle protezioni abituali nei programmi attuali.
La rete della macchina virtuale è stata configurata in modalità NAT, che ha permesso l'accesso a Internet per installare dipendenze, scaricare strumenti e mantenere la connettività di base del laboratorio.
Per coprire tutte le fasi dell'analisi è stato necessario avvalersi di diverse utilità. Alcune sono state utilizzate per preparare l'ambiente, altre per esaminare il binario e altre ancora per osservare il comportamento del processo quando si verificava l'errore.
È stato utilizzato per scaricare repository, mantenere organizzate determinate risorse e facilitare la gestione del materiale utilizzato durante la ricerca.
È stato impiegato come supporto per verificare la connettività, identificare il servizio esposto e controllare che l'obiettivo rispondesse correttamente sulla porta prevista.
È stato installato per disporre di librerie, header e strumenti utili in attività di debug e analisi a basso livello all'interno del sistema Windows.
È stato utilizzato per modifiche rapide, revisione di script e manipolazione semplice di stringhe o dati di test.
È servito come ambiente comodo per scrivere script, testare automazioni e lavorare con il codice in modo più ordinato.
È stato utile soprattutto quando è stato necessario rivedere script più lunghi o fare debug della logica relativa alla costruzione dei payload.
Sono state considerate due versioni:
È stato necessario per eseguire Ghidra, poiché questo strumento è sviluppato su Java.
È stato utilizzato per osservare lo stato del programma durante l'esecuzione, controllare i registri, esaminare la memoria e analizzare il punto esatto in cui si verifica l'errore.
È stato impiegato nella fase di analisi statica per esaminare il binario e individuare funzioni sospette dal punto di vista della sicurezza.
È stato usato come supporto per decompilare e comprendere meglio la logica interna del programma vulnerabile.
Questo plugin ha facilitato compiti come la creazione di pattern, il calcolo dell'offset e l'identificazione di caratteri problematici nel payload.
Il componente principale del laboratorio è stato FreeFloat FTP Server v1.0, che funge da sistema obiettivo all'interno della prova di concetto. Il suo interesse risiede nel fatto che incorpora una vulnerabilità classica di overflow nello stack, rendendolo un caso molto appropriato per l'analisi formativa.
Sebbene esistano macchine virtuali già pronte per questo tipo di esercizi, in questo caso si è scelto di documentare l'ambiente e giustificare gli strumenti utilizzati. Ciò consente di comprendere meglio perché ogni applicazione fa parte del laboratorio e che ruolo svolge durante l'analisi.
Il primo passo è stato verificare che il servizio FTP fosse accessibile e funzionante correttamente. Una volta confermata la connettività, è stato esaminato il binario tramite strumenti di analisi statica per individuare potenziali punti deboli legati alla gestione delle stringhe.
Durante questa revisione sono emerse funzioni insicure come strcpy e strcat, rafforzando il sospetto che il servizio potesse essere vulnerabile a input eccessivamente lunghi. Sono stati anche esaminati diversi comandi del protocollo FTP suscettibili di ricevere dati controllati dall'utente, selezionandone uno come candidato principale per i test.
Con questa base, il processo è stato caricato in un debugger per osservare il suo comportamento durante l'esecuzione.
La fase successiva è consistita nell'inviare stringhe sempre più lunghe per verificare se il programma smettesse di rispondere correttamente. Questa procedura ha permesso di verificare che, a partire da una certa dimensione, il servizio falliva e finiva per provocare un'alterazione in memoria.
Questo comportamento ha confermato che non si trattava di un semplice errore di validazione superficiale, ma di una corruzione reale che influenzava il flusso del processo.
Dopo aver provocato l'errore, è stato necessario calcolare con precisione quanti byte fossero necessari per raggiungere l'indirizzo di ritorno. A tal fine è stata utilizzata una sequenza non ripetitiva, in modo che il valore riflesso in EIP al momento del crash potesse essere correlato a una posizione esatta all'interno dell'input inviato.
Grazie a questa procedura è stato ottenuto lo spostamento concreto necessario per sovrascrivere il registro di controllo.
Con l'offset ormai noto, è stato preparato un nuovo test in cui l'indirizzo di ritorno è stato sostituito con un valore facilmente riconoscibile. L'obiettivo era verificare se il programma permettesse di modificare EIP in modo controllato.
Il test è stato soddisfacente, poiché il debugger ha mostrato che il registro conteneva esattamente il valore inserito. Ciò dimostrava che era possibile alterare il flusso di esecuzione e reindirizzarlo verso un indirizzo scelto.
Una volta raggiunto questo punto, è stato analizzato quali byte potessero interferire con il payload. In questo tipo di vulnerabilità è comune che certi caratteri provochino troncamenti, cambiamenti inaspettati o terminazione prematura della stringa.
Tramite confronti successivi in memoria sono stati identificati diversi bad characters, tra cui:
\x00\x0a\x0dRilevarli è stato importante per costruire un payload finale stabile e compatibile con il comportamento del programma vulnerabile.
Il passo successivo è consistito nel trovare un indirizzo adatto che permettesse di reindirizzare l'esecuzione verso l'area di memoria dove sarebbe stato allocato il payload. Questa analisi doveva essere effettuata tenendo conto del sistema operativo e delle protezioni attive, poiché alcuni indirizzi non sono stabili tra le esecuzioni.
All'interno del laboratorio è stato individuato un riferimento valido che permetteva di collegare la sovrascrittura del flusso con l'input controllato dall'attaccante.
Una volta validato il controllo del flusso, è stata costruita una shellcode compatibile con le restrizioni scoperte in precedenza. Inoltre, è stata aggiunta un'area precedente di istruzioni neutre (NOP sled) per facilitare il raggiungimento sicuro dell'inizio del payload da parte della CPU, anche in caso di lieve deviazione nella posizione attesa.
Questo passo è stato importante per aumentare l'affidabilità dell'esecuzione.
Nell'ultima fase è stato lanciato il payload completo contro il servizio vulnerabile, mentre un listener rimaneva in ascolto sulla macchina attaccante. Il risultato è stato l'instaurazione di una connessione remota con il sistema obiettivo, confermando che la vulnerabilità non solo consente di causare un crash del programma, ma anche di ottenere un'esecuzione controllata.
Ciò dimostra l'impatto reale del fallimento e ne giustifica la rilevanza dal punto di vista della sicurezza offensiva e difensiva.
Lo studio di CVE-2025-5548 mostra chiaramente come un'applicazione datata, priva di meccanismi moderni di protezione, possa essere vulnerabile a tecniche classiche di sfruttamento basate sulla corruzione della memoria.
Durante il laboratorio sono state percorse diverse fasi fondamentali: la preparazione dell'ambiente, l'osservazione iniziale dell'errore, la validazione dell'overflow, il controllo del registro di esecuzione, il debug del payload e la verifica del risultato finale.
Al di là della prova tecnica, questo caso serve a comprendere perché l'uso di funzioni insicure e l'assenza di misure di protezione rimangano un rischio importante nel software legacy. Per questo motivo, questo tipo di esercizi è particolarmente utile per consolidare le conoscenze di reversing, analisi delle vulnerabilità e sfruttamento in ambienti controllati.