zbyszkok/cve-2025-49844-redishell-ai-made-revshellConclusão não testada do PoC Redishell feito por IA
PoC de Revshell feito por IA
Completamento não testado do PoC Redishell feito por IA.
PoC Original:
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
Peça Coreana:
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
Mais tarde, fomos em frente e conectamos o GDB – conseguimos obter o endereço base e descobrir mais algumas coisas, mas, no geral, parece que essa não é uma vulnerabilidade simples de heap. Não importa o que tentássemos, era impossível obter execução de código. Travamento? Sim. Comandos? Não.
Não somos mais firmes em engenharia reversa, então não podemos ter certeza, mas por tudo que descobrimos ao longo de horas com a ajuda de alguns dos modelos de IA mais fortes, não é possível obter execução de código através dessa vulnerabilidade (ou é uma em mil tentativas, mas isso é pura suposição).
Através de inúmeras tentativas, sempre chegávamos a isto no máximo:
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
Curioso para ver o PoC real com execução de código.
LEIA CORRETAMENTE POR FAVOR: Dissemos, DO QUE SABEMOS / VIMOS ATÉ AGORA. Isso não é uma afirmação absoluta, pode haver um truque ou golpe que não consideramos, existem especialistas em BinEx muito melhores por aí.
Observe que o Redis Server permaneceu estável – nós o retiramos do docker para teste. Você pode disparar o travamento executando o exploit algumas milhares de vezes e ainda não tentamos combinar esse método de força bruta com tentativas de execução de código, pode ser a solução.
Como você vê, o PoC original parece sofrer dos mesmos problemas, ele afirma ser "simplificado" enquanto não está totalmente claro qual deveria ser o resultado.
Nada ainda...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
Misteriosamente, nas notas de patch do Redis, um CVE completamente diferente é listado – também supostamente uma exploração binária, mas muito mais simples, um buffer overflow baseado em pilha com suposta RCE:
XACKDEL pode levar a estouro de pilha e potencial RCEEncontramos ainda menos informações sobre isso. Já é desafiador encontrar uma versão não backportada sem compilar manualmente, mas talvez esse seja o caminho que teremos que seguir.
Todos esses POTENCIAIS – eu tenho potencial. Agora tenho 2 potenciais.
62507 é o caminho... ainda não tenho RCE, mas parece fácil e promissor...
Então o CVE-2025-49844 era apenas um engodo? A Peça Coreana ainda não produziu um travamento – mas produz uma saída completamente diferente contra nosso 8.2.2 compilado manualmente. Tendo que admitir, até eu caí na ideia de "sim, travamento, mais que plausível, provavelmente fácil..." e simplesmente assumi que a parte do travamento do CVE-2025-49844 funcionaria. Mas nunca funcionou. Desculpe por ter dito errado antes, mas agora está esclarecido, espero. CVE-2025-49844 não trava, CVE-2025-62507 trava.
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
Parece familiar? Não sei o que fizeram lá... ou se ninguém verificou além de mim? O mundo se tornou um lugar bastante estranho ultimamente.