Linux / Cdorked.A: नए Apache पिछले दरवाजे के क्रोनिकल्स

पिछले हफ्ते, सुकुरी के सहयोगियों ने हमें अपाचे वेब सर्वर के लिए द्विआधारी फ़ाइल का एक संशोधित संस्करण भेजा, जिसने ब्लैकहोल एक्सप्लॉइट किट को संबोधित कुछ अनुरोधों को पुनर्निर्देशित किया। हमारे एंटीवायरस लैब के विशेषज्ञों द्वारा किए गए विश्लेषण से पता चला कि लिनक्स / Cdorked.A नामक इस लिनक्स खतरे को ट्रैफिक को दुर्भावनापूर्ण साइटों पर पुनर्निर्देशित करने के लिए डिज़ाइन किया गया है। इस घटना के बारे में सुकुरी को जानकारी।

विश्लेषण की प्रक्रिया में, हम इस निष्कर्ष पर पहुंचे कि लिनक्स / Cdorked.A सबसे जटिल लिनक्स बैकडोर है जो हम पहले देख चुके हैं। हमारे ईएसईटी लाइव ग्रिड क्लाउड तकनीक का उपयोग करके, हमने सैकड़ों समझौता किए गए वेब सर्वरों पर आंकड़े प्राप्त किए हैं। इसी तरह के अन्य खतरों के विपरीत, पिछले दरवाजे एक समझौता किए गए मेजबान की हार्ड ड्राइव पर अपनी गतिविधियों का कोई निशान नहीं छोड़ता है, जो इसकी पहचान को काफी जटिल करता है। इसके बजाय, यह हार्ड ड्राइव को शामिल किए बिना, मेमोरी में उपयोग की जाने वाली सभी जानकारी संग्रहीत करता है। इसके अलावा, हमलावर दुर्भावनापूर्ण कोड में सेवा की जानकारी स्थानांतरित करने के लिए obfuscated HTTP अनुरोधों का उपयोग करते हैं, जो अपाचे लॉग फ़ाइल में दर्ज नहीं किए जाते हैं। इस प्रकार, सी एंड सी सर्वर के साथ बातचीत करने वाले दुर्भावनापूर्ण कोड के कोई निशान भी नहीं हैं।



Linux / Cdorked बाइनरी फ़ाइल में एन्क्रिप्टेड रूप में सभी महत्वपूर्ण लाइनें शामिल हैं, एक स्थिर कुंजी के साथ प्रसिद्ध XOR योजना का उपयोग करते हुए। लिनक्स / Cdorked संस्करण जो हमने विश्लेषण किया है, उसमें लगभग 70 ऐसी लाइनें हैं, जो नीचे स्क्रीनशॉट में दिखाई गई कुंजी (27A4E2DADAF183B51E3DA7F6C9E6239CDFC8A2D50A60E05F) का उपयोग करती हैं।


अंजीर। स्ट्रिंग डिक्रिप्शन कोड।


अंजीर। डिक्रिप्शन कुंजी।

जैसा कि ऊपर उल्लेख किया गया है, पिछले दरवाजे आधिकारिक उद्देश्यों के लिए डिस्क पर फ़ाइलों का उपयोग नहीं करते हैं। इसके बजाय, यह अपने डेटा और कॉन्फ़िगरेशन जानकारी को संग्रहीत करने के लिए लगभग 6 एमबी साझा मेमोरी आवंटित करता है। यह मेमोरी ब्लॉक, जिसे POSIX साझा मेमोरी कहा जाता है, का उपयोग सभी अपाचे बाल प्रक्रियाओं द्वारा किया जाता है, और इसे सिस्टम में किसी अन्य प्रक्रिया द्वारा एक्सेस किया जा सकता है, क्योंकि दुर्भावनापूर्ण कोड के लेखक एक्सेस अधिकारों का उपयोग करके इसके उपयोग को प्रतिबंधित नहीं करते हैं। नीचे दिया गया स्क्रीनशॉट साझा मेमोरी के इस क्षेत्र के एक्सेस अधिकारों को दिखाता है (सभी के लिए पढ़ें और लिखें)।


अंजीर। साझा मेमोरी ब्लॉक तक पहुंच प्राप्त करना।

दो तरीके हैं जिनमें एक हमलावर एक समझौता किए गए सर्वर के व्यवहार को नियंत्रित कर सकता है: कमांड लाइन का उपयोग करके और विशेष कमांड का उपयोग करके रिवर्स कनेक्शन के माध्यम से। इन दोनों विधियों को HTTP अनुरोधों के माध्यम से सक्रिय किया जाता है। कमांड लाइन का उपयोग करने वाली पहली विधि को GET HTTP प्रोटोकॉल अनुरोध के माध्यम से कहा जाता है। यह निष्पादित किया जाता है जब एक विशेष पथ का अनुरोध किया जाता है, और स्ट्रिंग का एक विशिष्ट प्रारूप होता है और इसमें कनेक्शन के लिए होस्ट नाम और पोर्ट होता है। क्लाइंट आईपी एड्रेस को ट्रांसमिटेड स्ट्रिंग को डिक्रिप्ट करने के लिए एक कुंजी के रूप में उपयोग किया जाता है, अर्थात, 4-बाइट XOR कुंजी। इसके अतिरिक्त, पैकेट हेडर X-Real_IP या X-Redirected_on में निर्दिष्ट IP पता क्लाइंट IP को डिक्रिप्शन कुंजी के रूप में बदल देगा। इसका मतलब यह है कि हम X-Real_IP के लिए एक हेडर बना सकते हैं, जो कुंजी "\ x00 \ x00 \ x00 \ x00" के रूप में कार्य करेगा। भेजने से पहले क्वेरी स्ट्रिंग को हेक्स प्रारूप में होना चाहिए।


अंजीर। कमांड निष्पादन उदाहरण।

जब तक हमलावर के पास कमांड लाइन तक पहुंच होती है, तब तक सक्रिय HTTP कनेक्शन को डिस्कनेक्ट नहीं किया जाएगा। इसका अर्थ है कि यदि आप उन HTTP कनेक्शनों की जांच करते हैं जो समय में लंबे होते हैं तो दुर्भावनापूर्ण कोड गतिविधि देखी जा सकती है। दूसरी ओर, अपाचे लॉग इस कनेक्शन के बारे में कोई जानकारी प्रदान नहीं करता है, क्योंकि दुर्भावनापूर्ण कोड इस जानकारी की उपस्थिति को नियंत्रित करता है।

एक समझौता किया गया वेब सर्वर क्लाइंट को दुर्भावनापूर्ण वेब पेजों पर पुनर्निर्देशित करता है, इसके लिए पिछले दरवाजे कोड में एक आधार 64 एनकोडेड अनुरोध स्ट्रिंग शामिल होता है जिसमें मूल URL के बारे में जानकारी होती है और क्या अनुरोध जेएस फाइल को संबोधित किया गया था ताकि सर्वर सही उपयोगी प्रदान कर सके लोड।



ऐसी रेखा का एक उदाहरण:

hxxp: // dcb84fc82e1f7b01 xxxxxxgsm.be/index.php?j=anM9MSZudmNiaW11Zj1jY3
Zja3FqdSZ0aW1lPTEzMDQxNjE4MjctMzYwNDUzNjUwJnNyYz0yMzImc3VybD13d3cuaW5mZWN0ZWRzZXJ2ZXIuY29tJnNwb3J0PTgwJmtleT0xM0Q5MDk1MCZzdXJpPS9mb3J1bS93Y2YvanMvM3JkUGFydHkvcHJvdG9hY3Vsb3VzLjEuOC4yLm1pbi5qcw ==

डिक्रिप्टेड रूप में, हम निम्नलिखित पैरामीटर देखते हैं:

js = 1 & nvcbimuf = ccvckqju & time = 1304161827-360453650 और src = 232 & surl = www.infectedserver.com & sport = 80 & key = 13D90550 और suri = / forum / wcf / js / 3GParty / protoaculous.1min.1.1min

पैरामीटर "surl" एक समझौता किए गए (संक्रमित) होस्ट को इंगित करता है, और "suri" एक मूल अनुरोध को दर्शाता है।

पुनर्निर्देशन के बाद, क्लाइंट के ब्राउज़र के लिए कुकीज़ सेट की जाती हैं, ताकि भविष्य में यह फिर से अप्रत्यक्ष न हो। यह कुकी भी सेट की गई है यदि सर्वर प्रशासन पृष्ठ के समान वेब पेज अनुरोध किया गया है। दुर्भावनापूर्ण कोड निम्न तर्जों के लिए URL, सर्वर नाम, रेफ़रर फ़ील्ड जैसे तर्कों की जाँच करता है: "* प्रशंसा *", "* वेबमास्टर *", "* सबमिट *", "* स्टेट *", "* मर्टग *", "" webmin * "," * cpanel * "," * membrane * "," * bucks * "," * bill * "," * host * "," * secur * "," * support * "। शायद इस तरह के चेक वेबसाइट के प्रशासकों को दुर्भावनापूर्ण सामग्री भेजने से बचने के लिए किए जाते हैं, इसलिए समझौते के तथ्य का पता लगाना अधिक कठिन होगा। नीचे दिए गए स्क्रीनशॉट में कुकीज़ को संसाधित करने के लिए जिम्मेदार कोड का हिस्सा दिखाया गया है।



सफलतापूर्वक पुनर्निर्देशित करने के लिए, दुर्भावनापूर्ण कोड कुछ अन्य अनुरोध तर्कों की भी जांच करता है, उदाहरण के लिए, स्वीकार-भाषा, स्वीकार-एन्कोडिंग, संदर्भ फ़ील्ड की उपस्थिति के लिए चेक।

हमने 23 आदेशों की खोज की, जो लिनक्स / Cdorked.A एक विशेष रूप से तैयार किए गए URL का उपयोग करके HTTP POST अनुरोध के माध्यम से सर्वर को भेज सकते हैं। अनुरोध में कुकी फ़ील्ड होना चाहिए जो " SECID = " टोकन से शुरू होता है। अनुरोध स्ट्रिंग में दो हेक्स बाइट्स होने चाहिए, जो क्लाइंट आईपी पते का उपयोग करके एन्क्रिप्ट किए गए मान हैं। SECID पैरामीटर का उपयोग कुछ अन्य आदेशों में एक तर्क के रूप में भी किया जाता है। हम मानते हैं कि पिछले दरवाजे द्वारा पुनर्निर्देशित आगंतुकों द्वारा उपयोग किए गए URL इस विशेष विधि का उपयोग करते हैं। इन पतों के बारे में जानकारी साझा मेमोरी का उपयोग करके एन्क्रिप्टेड रूप में संग्रहीत की जाएगी। यह भी स्पष्ट है कि पुनर्निर्देशन के लिए शर्तें निम्नानुसार हैं: उपयोगकर्ता एजेंटों की एक सफेद सूची जिसके लिए पुनर्निर्देशन पूर्व-कॉन्फ़िगर किया जा सकता है और आईपी पते की एक काली सूची जिसके लिए पुनर्निर्देशन नहीं किया गया है।

आदेशों की एक पूरी सूची जो पिछले दरवाजे "DU", "ST", "T1", "L1", "D1", "L2", "D2", "L3", "D3", "L4", "D4" समर्थन , "L5", "D5", "L6", "D6", "L7", "D7", "L8", "D8", "L9", "D9", "LA", "DA"।

नीचे दिए गए स्क्रीनशॉट में दिखाए अनुसार पिछले दरवाजे HTTP हैडर के ETag पैरामीटर का उपयोग करके अपनी स्थिति बनाए रखता है। हम अभी भी इनमें से प्रत्येक टीम के उद्देश्य पर शोध कर रहे हैं और जैसे ही हमारा विश्लेषण पूरा होगा, उन्हें प्रकाशित करेंगे। संक्षेप में, उन सभी का उद्देश्य या तो साझा मेमोरी ब्लॉक में कॉन्फ़िगरेशन की सामग्री को जोड़ना है, या इसे वहां से हटाना है।



जैसा कि पहले उल्लेख किया गया है, साझा मेमोरी ब्लॉक तक पहुंच अधिकार सिस्टम में चल रही किसी भी प्रक्रिया तक पहुंच की अनुमति देता है। हमने एक नि: शुल्क उपकरण ( डंप_कॉर्केड_कॉन्फिडैम ) विकसित किया है जो सिस्टम प्रशासक को मेमोरी के ऐसे ब्लॉक के अस्तित्व को सत्यापित करने और इसे एक फाइल में सहेजने में मदद करेगा। हमारे विशेषज्ञ डेबियन और उबंटू सिस्टम के लिए डीबसम उपकरण का उपयोग करने की भी सलाह देते हैं, साथ ही आरपीएम-आधारित लिनक्स सिस्टम के लिए "आरपीएम -वर्इज़" कमांड का उपयोग करते हैं, जो आपके अपाचे सर्वर के मॉड्यूल की अखंडता की जांच करेगा। एक साझा मेमोरी ब्लॉक की जाँच करना यह सुनिश्चित करने का अनुशंसित तरीका है कि आप संक्रमित नहीं हैं। हमारी एंटी-वायरस प्रयोगशाला आगे के विश्लेषण के लिए ऐसी मेमोरी डंप प्राप्त करने में रुचि रखती है।

लेखन के समय, ईएसईटी लाइव ग्रिड का खतरा ट्रैकिंग सिस्टम सैकड़ों वेब सर्वर दिखाता है जो इस पिछले दरवाजे से समझौता किया गया है। उसी समय, इन सर्वरों के हजारों आगंतुक दुर्भावनापूर्ण सामग्री पर पुनर्निर्देशित कर दिए गए थे। निकट भविष्य में हम लिनक्स / Cdorked.A के साथ स्थिति के बारे में अधिक जानकारी प्रकाशित करेंगे।