zbyszkok/cve-2025-49844-redishell-ai-made-revshellإكمال غير مُختبر لإثبات المفهوم Redishell الذي صنعه الذكاء الاصطناعي
Revshell PoC من صنع الذكاء الاصطناعي
استكمال غير مُختبر لـ Redishell PoC صُنع بواسطة الذكاء الاصطناعي.
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 - وتمكّنّا من الحصول على العنوان الأساسي (Base address) واكتشاف بضعة أمور إضافية، لكن الأهم من ذلك كلّه، يبدو أن هذه ليست ثغرة Heap بسيطة. مهما حاولنا، كان من المستحيل الحصول على تنفيذ أكواد. تعطّل؟ نعم. أوامر؟ لا.
لم نعد أقوياء في الهندسة العكسية (reversing)، لذا لا يمكننا الجزم، لكن من كل ما وجدناه على مدى ساعات بمساعدة بعض من أقوى نماذج الذكاء الاصطناعي، ليس من الممكن الحصول على تنفيذ أكواد عبر هذه الثغرة (أو أنها محاولة واحدة من ألف لكن هذا مجرد تخمين خالص).
عبر محاولات عديدة، كنا نصل دائمًا في أفضل الحالات إلى شيء هنا:
Script attempted to access nonexistent global variable 'print' script: 67dfac1cecac4f99df897c7a0713f1d6fcef69a4, on @user_script:21.
متحمسون لرؤية الـ PoC الحقيقي مع تنفيذ الأكواد.
اقرأوا جيدًا من فضلكم: قلنا، بناءً على كل ما نعرفه / رأيناه حتى الآن. هذا ليس تصريحًا مطلقًا، فقد تكون هناك خدعة أو حل لم نفكر فيه، فهناك متخصصون في استغلال الثنائيات (BinExers) أفضل بكثير.
لاحظ أن Redis Server ظل مستقرًا - أخرجناه من docker للاختبار. يمكنك إحداث التعطّل عبر إطلاق الاستغلال بضعة آلاف من المرات، ولم نجرب بعد دمج هذه الطريقة بالقوة الغاشمة مع محاولات تنفيذ الأكواد، فقد يكون ذلك هو الحل.
كما ترى، يبدو أن الـ PoC الأصلي يعاني من المشكلات نفسها، فهو يدّعي أنه "مُبسّط" في حين أنه ليس واضحًا تمامًا ما يفترض أن تكون عليه النتيجة.
لا شيء بعد...
$ while redis-cli -h localhost -p 6380 --eval korean.lua; do printf '.'; done
بشكل غامض، في ملاحظات تصحيح Redis، تم إدراج CVE مختلفة تمامًا - يُفترض أيضًا أنها استغلال ثنائي، لكنها أبسط بكثير، وهي تجاوز سعة مخزن مؤقت (Buffer Overflow) قائم على المكدس مع RCE محتمل:
XACKDEL قد يؤدي إلى تجاوز سعة المكدس وRCE محتملوجدنا معلومات أقل حتى عن هذا. من الصعب أصلًا العثور على نسخة غير مُعاد ترقيعها (non-backported) دون التجميع الذاتي، لكن ربما هذا هو الطريق الذي سيتعين علينا سلوكه حينها.
كل هذه POTENTIALS - لديّ إمكانات. الآن لديّ احتمالان.
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.
هل يبدو مألوفًا؟ لا أعرف ماذا فعلوا هناك... أو ما إذا لم يتحقق أحد غيري؟ لقد أصبح العالم مكانًا غريبًا إلى حد ما مؤخرًا.