
Redishell PoC का अप्रयुक्त पूर्णता, AI द्वारा निर्मित
AI-निर्मित Revshell PoC
AI द्वारा बनाए गए 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 को जोड़ा - हम बेस एड्रेस प्राप्त करने और कुछ और चीजें पता लगाने में सफल रहे, लेकिन सबसे बढ़कर, ऐसा प्रतीत होता है कि यह कोई साधारण हीप भेद्यता नहीं है। हमने चाहे जो भी कोशिश की, कोड निष्पादन प्राप्त करना असंभव था। क्रैश? हाँ। कमांड? नहीं।
अब हम रिवर्सिंग में उतने पक्के नहीं हैं, इसलिए हम निश्चित नहीं हो सकते, लेकिन कुछ सबसे मजबूत AI मॉडलों की मदद से हमने घंटों में जो कुछ भी पाया, उससे यह संभव नहीं है कि इस भेद्यता के माध्यम से कोड निष्पादन प्राप्त किया जा सके (या यह एक हज़ार प्रयासों में से एक है, लेकिन यह पूरी तरह से अनुमान है)।
कई प्रयासों के बाद, हम हमेशा अधिक से अधिक यहाँ तक पहुँचे:
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 सूचीबद्ध है - जो कथित तौर पर एक बाइनरी एक्सप्लॉइट भी है, लेकिन कहीं अधिक सरल, एक स्टैक-आधारित बफर ओवरफ्लो जिसमें संभावित RCE है:
XACKDEL में बग स्टैक ओवरफ्लो और संभावित RCE का कारण बन सकता हैhttps://github.com/redis/redis/compare/8.2.2...8.2
हमें इस पर और भी कम जानकारी मिली। बिना स्व-संकलन के एक नॉन-बैकपोर्टेड संस्करण खोजना पहले से ही चुनौतीपूर्ण है, लेकिन शायद हमें फिर वही रास्ता अपनाना पड़ेगा।
ये सारे POTENTIALS - मेरे पास क्षमता है। अब मेरे पास 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.
परिचित लगता है? मुझे नहीं पता कि उन्होंने वहाँ क्या किया... या क्या मेरे अलावा किसी और ने जाँच नहीं की? दुनिया हाल ही में एक अजीब जगह बन गई है।