Estudio técnico de la vulnerabilidad CVE-2025-5548
Neste trabalho analisa-se a vulnerabilidade CVE-2025-5548, associada a um estouro de buffer na pilha presente no FreeFloat FTP Server v1.0. O objetivo principal do laboratório é entender como uma aplicação vulnerável se comporta diante de entradas manipuladas e observar, em um ambiente controlado, como uma falha de validação pode acabar afetando o fluxo de execução do programa.
O desenvolvimento do repositório não se limita a mostrar o resultado final, mas sim a recolher o processo completo de investigação: preparação do ambiente, seleção de ferramentas, observação da falha, análise de memória e validação do impacto real da vulnerabilidade.
O trabalho está dividido em dois blocos distintos.
Nesta seção explica-se como o ambiente de prática foi montado, qual sistema operacional foi utilizado, qual é a aplicação vulnerável e quais ferramentas foram consideradas necessárias para realizar a análise.
A segunda parte foca na parte prática. Aqui descreve-se o processo seguido para detectar a falha, confirmar a corrupção de memória, estudar a sobrescrita de registradores e verificar como a vulnerabilidade pode ser explorada.
A prática foi realizada em uma máquina virtual com Windows 11 Pro 25H2 (Build 26200.6584). O software vulnerável selecionado foi FreeFloat FTP Server v1.0, uma aplicação antiga que se mostra adequada para este tipo de exercício por carecer de muitas das proteções comuns em programas atuais.
A rede da máquina virtual foi configurada em modo NAT, o que permitiu acesso à Internet para instalar dependências, baixar ferramentas e manter a conectividade básica do laboratório.
Para cobrir todas as fases da análise foi necessário apoiar-se em várias utilidades. Algumas foram utilizadas para preparar o ambiente, outras para revisar o binário e outras para observar o comportamento do processo quando a falha ocorria.
Foi usado para baixar repositórios, manter organizados determinados recursos e facilitar a gestão do material utilizado durante a investigação.
Foi utilizado como apoio para verificar conectividade, identificar o serviço exposto e confirmar que o alvo estava respondendo corretamente na porta esperada.
Foi instalado para dispor de bibliotecas, cabeçalhos e ferramentas úteis em tarefas de depuração e análise de baixo nível dentro do sistema Windows.
Foi utilizado para edições rápidas, revisão de scripts e manipulação simples de strings ou dados de teste.
Serviu como ambiente confortável para escrever scripts, testar automações e trabalhar com código de forma mais organizada.
Foi útil especialmente quando houve necessidade de revisar scripts mais longos ou depurar lógica relacionada à construção de cargas.
Foram consideradas duas versões:
Foi necessário para executar Ghidra, já que esta ferramenta é desenvolvida sobre Java.
Foi utilizado para observar o estado do programa durante a execução, verificar registradores, revisar memória e analisar o ponto exato onde a falha ocorre.
Foi empregado na fase de análise estática para revisar o binário e localizar funções que se mostravam suspeitas do ponto de vista da segurança.
Foi usado como apoio para descompilar e entender melhor a lógica interna do programa vulnerável.
Este complemento facilitou tarefas como a criação de padrões, o cálculo do offset e a identificação de caracteres problemáticos na carga.
O componente principal do laboratório foi FreeFloat FTP Server v1.0, que atua como sistema alvo dentro da prova de conceito. Seu interesse reside no fato de incorporar uma vulnerabilidade clássica de estouro na pilha, o que o torna um caso muito apropriado para análise formativa.
Embora existam máquinas virtuais já preparadas para este tipo de exercício, neste caso optou-se por documentar o ambiente e justificar as ferramentas utilizadas. Isto permite compreender melhor por que cada aplicação faz parte do laboratório e qual papel desempenha durante a análise.
O primeiro passo consistiu em verificar se o serviço FTP estava acessível e funcionando corretamente. Uma vez confirmada a conectividade, o binário foi revisado por meio de ferramentas de análise estática para localizar possíveis pontos fracos relacionados ao gerenciamento de strings.
Durante esta revisão apareceram funções inseguras como strcpy e strcat, o que reforçou a suspeita de que o serviço poderia ser vulnerável a entradas excessivamente longas. Também foram examinados vários comandos do protocolo FTP suscetíveis de receber dados controlados pelo usuário, selecionando um deles como candidato principal para os testes.
Com esta base, o processo foi carregado em um depurador para observar seu comportamento durante a execução.
A fase seguinte consistiu em enviar strings cada vez mais longas para verificar se o programa deixava de responder corretamente. Este procedimento permitiu confirmar que, a partir de certo tamanho, o serviço falhava e acabava provocando uma alteração na memória.
Esse comportamento confirmou que não se tratava de um simples erro de validação superficial, mas sim de uma corrupção real que afetava o fluxo do processo.
Após provocar a falha, foi necessário calcular com precisão quantos bytes eram necessários para alcançar o endereço de retorno. Para isso, utilizou-se uma sequência não repetitiva, de modo que o valor refletido em EIP no momento do crash pudesse ser relacionado a uma posição exata dentro da entrada enviada.
Graças a este procedimento, obteve-se o deslocamento concreto necessário para sobrescrever o registrador de controle.
Com o offset já conhecido, preparou-se um novo teste no qual o endereço de retorno foi substituído por um valor facilmente reconhecível. O objetivo era verificar se o programa permitia modificar EIP de forma controlada.
O teste foi satisfatório, já que o depurador mostrou que o registrador continha exatamente o valor introduzido. Isto demonstrava que era possível alterar o fluxo de execução e redirecioná-lo para um endereço escolhido.
Uma vez alcançado esse ponto, analisou-se quais bytes poderiam interferir na carga útil. Neste tipo de vulnerabilidade é comum que certos caracteres provoquem truncamentos, mudanças inesperadas ou finalização prematura da string.
Por meio de comparações sucessivas na memória, identificaram-se vários bad characters, entre eles:
\x00\x0a\x0dDetectá-los foi importante para construir uma carga final estável e compatível com o comportamento do programa vulnerável.
O passo seguinte consistiu em encontrar um endereço adequado que permitisse redirecionar a execução para a zona de memória onde a carga seria alojada. Esta análise devia ser feita levando em conta o sistema operacional e as proteções ativas, já que alguns endereços não são estáveis entre execuções.
Dentro do laboratório, localizou-se uma referência válida que permitia ligar a sobrescrita do fluxo com a entrada controlada pelo atacante.
Com o controle do fluxo já validado, construiu-se uma shellcode compatível com as restrições descobertas previamente. Além disso, adicionou-se uma zona anterior de instruções neutras para facilitar que a CPU chegasse de forma segura ao início da carga, mesmo se houvesse um ligeiro desvio na posição esperada.
Este passo foi importante para aumentar a confiabilidade da execução.
Na última fase, a carga completa foi lançada contra o serviço vulnerável enquanto um listener era mantido à escuta na máquina atacante. O resultado foi o estabelecimento de uma conexão remota com o sistema alvo, o que confirmou que a vulnerabilidade não só permite causar uma queda do programa, mas também obter execução controlada.
Isto demonstra o impacto real da falha e justifica sua relevância do ponto de vista da segurança ofensiva e defensiva.
O estudo de CVE-2025-5548 mostra claramente como uma aplicação antiga, sem mecanismos modernos de proteção, pode ser vulnerável a técnicas clássicas de exploração baseadas em corrupção de memória.
Ao longo do laboratório, percorreram-se várias etapas fundamentais: a preparação do ambiente, a observação inicial da falha, a validação do estouro, o controle do registrador de execução, a depuração da carga e a verificação do resultado final.
Além do teste técnico, este caso serve para entender por que o uso de funções inseguras e a ausência de medidas de proteção continuam sendo um risco importante em software legado. Por isso, este tipo de exercício é especialmente útil para consolidar conhecimentos de engenharia reversa, análise de vulnerabilidades e exploração em ambientes controlados.