
CVE-2018-10933 libSSH प्रमाणीकरण बायपास का शोषण करने वाली CTF चुनौती। इसमें Docker सेटअप, शोषण स्क्रिप्ट, और प्रतीकात्मक लिंक के माध्यम से छिपे हुए फ्लैग्स की खोज के लिए वॉकथ्रू शामिल हैं।
CVE-2018-10933 पर आधारित
CVE-2018-10933 एक कमजोरी है जो libSSH के चुनिंदा संस्करणों में खोजी गई है, जो संभावित रूप से असीमित मशीन एक्सेस की अनुमति दे सकती है। यह कमजोरी प्रमाणीकरण प्रक्रिया के दौरान पैकेट हेडर्स के अनुचित हैंडलिंग से उत्पन्न होती है, जहाँ MSG_USERAUTH_SUCCESS बाइट के साथ एक तैयार पैकेट भेजने से कोई भी प्रमाणीकरण को बायपास कर सकता है। फिर उनके पास मशीन तक पूर्ण पहुंच होती है।
इस चुनौती का आधार, तब, प्रतियोगियों को प्रदान की गई डॉकर इमेज में चारों ओर देखने, इस कमजोरी की खोज करने, पहुंच प्राप्त करने के लिए इसका शोषण करने, और फिर मशीन पर एक सिमलिंक में छिपी कुंजी खोजने की आवश्यकता है।
Someone got into my machine via port 22...
It looks like they didnt even know my credentials.
Anyways, they made a file with an odd name, but it's gone now,
I wonder if there's still some trace of the filename -
it might be something symbolic of the attacker...
Can you figure out how they got in and help me find the filename?
निम्नलिखित इच्छित समाधान का विस्तृत मार्गदर्शन है:
चुनौती विवरण से ध्यान दें कि हमलावर ने पोर्ट 22 के माध्यम से पहुंच प्राप्त की, जो आमतौर पर SSH के लिए आरक्षित पोर्ट है। यह भी ध्यान दें कि हमलावर ने पहुंच प्राप्त करने के लिए क्रेडेंशियल्स का उपयोग नहीं किया।
इससे, यदि आप क्रेडेंशियल्स के बिना SSH के माध्यम से मशीन तक पहुंच प्राप्त करने के पिछले बग्स के बारे में देखते हैं, तो MSG_USERAUTH_SUCCESS बाइट के साथ समस्या काफी संभावित है। वैकल्पिक रूप से, पोर्ट 22 पर कनेक्शन शुरू करके, कोई यह निर्धारित कर सकता है कि libSSH का कौन सा संस्करण चल रहा है, और फिर उस संस्करण के लिए सामान्य शोषण खोज सकता है।
विवरण से कोई यह भी देख सकता है कि वे जिस फ़ाइल नाम की तलाश कर रहे हैं (फ़्लैग) केवल एक प्रतीकात्मक लिंक के लक्ष्य के रूप में मौजूद है।
अब यह जानते हुए कि इस कमजोरी का शोषण करके पहुंच प्राप्त की जा सकती है, कोई अपना स्वयं का स्क्रिप्ट लिख सकता है, या एक उदाहरण स्क्रिप्ट कॉपी कर सकता है जो इस शोषण को चला सकता है, और लक्ष्य मशीन पर एक कमांड चला सकता है। मैंने इस समाधान के लिए एक शोषण स्क्रिप्ट अनुकूलित की है, और इसे libsshauthbypass.py नाम दिया है।
इस स्क्रिप्ट को चलाने और मशीन से फ़्लैग प्राप्त करने के लिए, डेमो इमेज के मामले में, कोई निम्नलिखित के समान एक कमांड चला सकता है:
./libsshauthbypass.py --host localhost -p 1337 -c 'find / -type l -exec stat {} + | grep "File:" | sed -E "s/.*\-> (.*)$/\1/g" | grep "definitelyarealCTF"'
जो तब इसके समान आउटपुट देता है
sspringer-fedora-CVE: ./libsshauthbypass.py --host localhost -p 1337 -c 'find / -type l -exec stat {} + | grep "File:" | sed -E "s/.*\-> (.*)$/\1/g" | grep "definitelyarealCTF"'
INFO:paramiko.transport:Connected (version 2.0, client libssh_0.8.1)
definitelyarealCTF{totally_a_REAL_flag}
अपने स्वयं के CTF के लिए इस चुनौती के एक संस्करण का उपयोग करने के लिए, यह अत्यधिक अनुशंसा की जाती है कि Dockerfile को डिफ़ॉल्ट प्रदान किए गए से भिन्न पथ का उपयोग करने के लिए बदलें, flag.txt में फ़्लैग बदलें (हालांकि यह अभी भी एक पंक्ति होना चाहिए), और फिर इमेज को पुनर्निर्माण करें। ध्यान दें कि प्रत्येक कनेक्शन प्रयास के लिए एक नया कंटेनर होस्ट करना आवश्यक हो सकता है ताकि किसी को विनाशकारी कमांड चलाने और सभी प्रतियोगियों को प्रभावित करने से रोका जा सके।
नए फ़्लैग (और इसका परीक्षण) के साथ डॉकर इमेज को पुनर्निर्माण करने के लिए
flag.txt अपडेट करें./build_run <image name>[:<version number] <port number> चलाएँ./libsshauthbypass.py या अपने स्वयं के स्क्रिप्ट का उपयोग करेंbuild_run स्क्रिप्ट द्वारा प्रदान किए गए शेल से exit करने पर, कंटेनर बंद और हटा दिया जाएगा, लेकिन इमेज बनी रहेगी और <image name> के रूप में टैग की जाएगीProof of Concept: https://youtu.be/ELrOBm02ANg
Walkthrough of challenge https://youtu.be/Ii121piSZR0