
CVE-2025-49844를 대상으로 한 Redis 힙 취약점에 대한 개념 증명 익스플로잇으로, GDB를 이용한 충돌 분석 및 코드 실행을 달성하기 위한 퍼징 시도를 포함합니다.
AI가 만든 Revshell PoC
AI가 만든 Redishell PoC의 테스트되지 않은 완성본.
Original PoC:
https://github.com/raminfp/redis_exploit/blob/main/exploit_poc.py
한국어 조각:
https://github.com/dwisiswant0/CVE-2025-49844/blob/master/CVE-2025-49844.lua
나중에 GDB를 연결했습니다. 베이스 주소를 알아내고 몇 가지를 더 찾았지만, 무엇보다도 이것이 단순한 힙 취약점이 아닌 것으로 보입니다. 우리가 무엇을 시도하든 코드 실행을 얻는 것은 불가능했습니다. 충돌? 네. 명령어 실행? 아니요.
더 이상 리버싱에 확신이 없어서 확실할 수는 없지만, 가장 강력한 AI 모델들의 도움으로 몇 시간 동안 찾은 모든 것에서 이 취약점을 통한 코드 실행은 불가능합니다 (또는 수천 번 시도 중 한 번 가능할 수도 있지만, 이는 순전한 추측입니다).
수많은 시도 끝에, 우리는 항상 이 지점에 도달했습니다:
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
코드 실행이 가능한 실제 PoC를 보고 싶습니다.
제대로 읽어주세요: 우리가 아는/지금까지 본 모든 것에서 말한 것입니다. 절대적인 주장이 아닙니다. 우리가 고려하지 않은 트릭이 있을 수 있습니다. 더 나은 BinExer 분들이 많이 계십니다.
Redis 서버는 안정적으로 유지되었습니다. 테스트를 위해 Docker에서 꺼냈습니다. 익스플로잇을 수천 번 실행하여 충돌을 유발할 수 있으며, 아직 이 무차별 대입 방법을 코드 실행 시도와 결합해 보지 않았습니다. 이것이 해결책일 수도 있습니다.

보시다시피 원본 PoC도 같은 문제를 겪고 있는 것 같습니다. "단순화"되었다고 주장하지만, 결과가 무엇이어야 하는지 명확하지 않습니다.
아직 없음...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
신비롭게도 Redis 패치 노트에는 완전히 다른 CVE가 나열되어 있습니다. 또한 바이너리 익스플로잇으로 추정되지만 훨씬 간단한, 스택 기반 버퍼 오버플로우로 RCE가 가능하다고 합니다:
XACKDEL 버그로 인해 스택 오버플로우 및 잠재적 RCE 발생 가능이에 대한 정보는 더 적었습니다. 자체 컴파일 없이 백포트되지 않은 버전을 찾는 것 자체가 어렵지만, 아마 그 길을 가야 할 것입니다.
이 모든 가능성 - 나도 가능성이 있어. 이제 2개의 가능성이 생겼다.
62507이 가야 할 길입니다... 아직 RCE는 없지만, 쉽고 유망해 보입니다...
그렇다면 CVE-2025-49844는 단지 속임수였을까요? 한국어 퍼즐은 아직 충돌을 일으키지 않았습니다. 하지만 자체 컴파일한 8.2.2에 대해 완전히 다른 출력을 생성합니다. 인정하건대, 저도 "네, 충돌, 그럴듯하고 아마 쉬울 거야..."라고 생각하며 CVE-2025-49844의 충돌 부분이 작동할 것이라고 무심코 가정했습니다. 하지만 전혀 작동하지 않았습니다. 이전에 잘못 말해서 죄송합니다만, 이제는 명확해졌길 바랍니다. CVE-2025-49844는 충돌하지 않습니다. CVE-2025-62507은 충돌합니다.
.(error) ERR user_script:16: Script attempted to access nonexistent global variable 'newproxy' script: 859491190bfb66357ec83aee16eb0554967c9c38, on @user_script:16.
익숙해 보이나요? 그들이 거기서 뭘 했는지 모르겠습니다... 아니면 나 말고는 아무도 확인하지 않은 건가요? 요즘 세상이 좀 이상해졌습니다.