open-flaw/cve-2025-49844Proof-of-concept exploit per CVE-2025-49844 che mira a una vulnerabilità heap di Redis, con analisi del crash assistita da GDB e tentativi di fuzzing per ottenere l'esecuzione di codice.
Revshell PoC creato dall'IA
Completamento non testato del PoC Redishell realizzato dall'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 approfondito e collegato GDB - siamo riusciti a ottenere l'indirizzo di base e a scoprire qualche altra cosa, ma soprattutto sembra che questa non sia una semplice vulnerabilità heap. Qualunque cosa tentassimo, 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 tramite questa vulnerabilità (o è un tentativo su mille, ma questa è pura speculazione).
Attraverso numerosi tentativi, siamo sempre arrivati al massimo a qualcosa del genere:
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, IN BASE A TUTTO QUELLO CHE SAPPIAMO / ABBIAMO VISTO FINORA. Non è un'affermazione assoluta, potrebbe esserci qualche trucco o sorpresa che non abbiamo considerato, ci sono esperti di binary exploitation molto più bravi in giro.
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 vedi, il PoC originale sembra avere gli stessi problemi; afferma di essere "semplificato" ma non è del tutto chiaro quale dovrebbe essere il risultato.
Niente ancora...
$ 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 binary exploit, ma molto più semplice, un buffer overflow basato su stack con presunta RCE:
XACKDEL may lead to stack overflow and potential RCEhttps://github.com/redis/redis/compare/8.2.2...8.2
Abbiamo trovato ancora meno informazioni su questa. È già difficile trovare una versione non backportata senza compilare da soli, ma forse è la strada che dovremo prendere.
Tutti questi POTENZIALI - io ho potenziale. Ora ho 2 potenziali.
La 62507 è la strada giusta... non ho ancora la RCE, ma sembra facile e promettente...
Quindi la 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, anche io sono caduto nel pensiero "sì, il crash, più che plausibile, probabilmente facile..." e ho semplicemente dato per scontato che la parte del crash della CVE-2025-49844 funzionasse. Ma non è mai successo. Scusate se prima l'ho detto male, ma ora è chiarito, si spera. La CVE-2025-49844 non crasha, la CVE-2025-62507 crasha.
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
Ti sembra familiare? NON SO cosa abbiano fatto lì... o se nessun altro ha controllato oltre a me? Il mondo è diventato un posto piuttosto strano ultimamente.