zbyszkok/cve-2025-49844-redishell-ai-made-revshellCompletamento non testato del PoC Redishell realizzato dall'IA
PoC di Revshell realizzato da IA
Completamento non testato del PoC RediShell realizzato da IA.
PoC originale:
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
Pezzo coreano:
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
In seguito abbiamo usato GDB - siamo riusciti a ottenere l'indirizzo base e a scoprire alcune altre cose, ma soprattutto sembra che questa non sia una semplice vulnerabilità Heap. Qualunque cosa provassimo, era impossibile ottenere l'esecuzione di codice. Crash? Sì. Comandi? No.
Non siamo più ferrati nel reverse engineering, quindi non possiamo esserne certi, ma da tutto ciò che abbiamo scoperto in ore di lavoro con l'aiuto di alcuni dei modelli IA più potenti, non è possibile ottenere l'esecuzione di codice attraverso questa vulnerabilità (oppure è una possibilità su mille tentativi, ma sarebbe pura speculazione).
Dopo numerosi tentativi, siamo sempre finiti al massimo qui:
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
Curiosi di vedere il vero PoC con l'esecuzione di codice.
LEGGETE ATTENTAMENTE PER FAVORE: abbiamo detto, DA TUTTO QUELLO CHE SAPPIAMO / ABBIAMO VISTO FINORA. Non è un'affermazione assoluta, potrebbe esserci un trucco o un'astuzia che non abbiamo considerato, ci sono esperti di Binary Exploitation molto più bravi di noi.
Nota: il server Redis è rimasto stabile - lo abbiamo estratto da docker per i test. Puoi innescare il crash lanciando l'exploit un paio di migliaia di volte e non abbiamo ancora provato a combinare questo metodo brute-force con tentativi di esecuzione di codice, potrebbe essere la soluzione.
Come puoi vedere, il PoC originale sembra avere gli stessi problemi, afferma di essere "semplificato" ma non è del tutto chiaro quale dovrebbe essere il risultato.
Ancora niente...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
Misteriosamente, nelle note di patch di Redis è elencata una CVE completamente diversa - anch'essa presumibilmente un exploit binario, ma molto più semplice, un buffer overflow basato su stack con presunta RCE:
XACKDEL può portare a stack overflow e potenziale RCEAbbiamo trovato ancora meno informazioni su questa. È già difficile trovare una versione non backportata senza compilare da sé, ma forse sarà la strada da intraprendere.
Tutte queste POTENZIALITÀ - io ho potenziale. Ora ho 2 potenzialità.
62507 è la strada giusta... non ho ancora la RCE, ma sembra facile e promettente...
Quindi CVE-2025-49844 era solo un inganno? Il puzzle coreano non ha ancora prodotto un crash - ma produce un output completamente diverso contro la nostra 8.2.2 compilata da noi. Devo ammettere che anch'io ho pensato "sì, il crash, più che plausibile, probabilmente facile..." e ho semplicemente dato per scontato che la parte del crash di CVE-2025-49844 funzionasse. Ma non ha mai funzionato. Mi scuso per aver detto male prima, ma ora è chiarito, si spera. CVE-2025-49844 non crasha, CVE-2025-62507 crasha.
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
Vi suona familiare? Non so cosa abbiano fatto lì... o se nessun altro ha controllato oltre a me? Il mondo è diventato un posto piuttosto strano ultimamente.