फ़ाइल एन्क्रिप्शन ट्रोजन के खिलाफ लड़ाई का इतिहास - प्रमुख नियंत्रण केंद्र की यात्रा

परिचय

कहानी तब शुरू हुई जब दिन की शुरुआत में एक कॉल आई। ग्राहक की उत्साहित आवाज़ ने कहा कि कंप्यूटर लोड नहीं करता है, दस्तावेज़ नहीं खुलते हैं, और स्क्रीन पर सामान्य डेस्कटॉप के बजाय एक अनुमानित अर्थ के साथ एक धमकी भरा शिलालेख है: "हमें पैसे का भुगतान करें और हम आपको डेस्कटॉप और दस्तावेज़ वापस कर देंगे"। स्थिति कई से परिचित है: सबसे अधिक संभावना है कि कंप्यूटर पर एक और winlocker है, फिरौती काटने पर काम करने में अधिकतम 10 मिनट लगेंगे।

विजेता को हटाने के लिए, 10 मिनट में मैं शहर के दूसरे छोर पर नहीं जाना चाहता था, इसलिए हम सहमत थे कि वे मेरे लिए सिस्टम लाएंगे, मैं इसे क्रम में रखूंगा और इसे वापस कर दूंगा।

मुझे सिस्टम मिल गया, इसे चालू कर दिया। XP को बूट किया। एक डेस्कटॉप दिखाई दिया - एक विजेता का कोई संकेत नहीं, पहली नज़र में सब कुछ ठीक है। हालाँकि, डेस्कटॉप से ​​आए पहले दस्तावेज़ को खोलने की कोशिश करने पर, मुझे प्रतिक्रिया में एक "डरावना" संदेश मिला:



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

इसलिए, संदेश जो फ़ाइलों को एन्क्रिप्ट किया गया था वह शुद्ध सत्य निकला। एक्सटेंशन डॉक, xls, dbf, avi, jpg, txt, rar, zip के साथ आकार में 2 गीगाबाइट से कम की सभी फ़ाइलों को एन्क्रिप्ट किया गया था - सामान्य तौर पर, वह सब कुछ जो जानकारी के स्वामी के लिए मूल्य का हो सकता है। एन्क्रिप्टेड फ़ाइलों में से - 1 सी आधार और महत्वपूर्ण दस्तावेज। यदि 1C को अभी भी एक ताजा बैकअप से बहाल किया जा सकता है, तो मूल्यवान दस्तावेजों और फ़ोटो का नुकसान ग्राहक के स्वास्थ्य को बहुत प्रभावित कर सकता है। इस प्रकार, कोई विकल्प नहीं था - मुझे डेटा के डिक्रिप्शन से निपटना था।

स्टेज 1. एन्क्रिप्शन एल्गोरिथ्म के लिए खोज

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

विश्लेषण के लिए, हम दो डीबीएफ फाइलें लेते हैं: एक संक्रमित सिस्टम से एन्क्रिप्टेड, दूसरा एक ताजा बैकअप से अछूता और एक दूसरे से उनकी तुलना करता है। स्रोत dbf फ़ाइल के क्षेत्र में समान समरूप बाइट्स से भरा हुआ है, उदाहरण के लिए 0 के मान के साथ, प्राइमर रिप्लेसमेंट सिफर को इंगित कर सकता है। सौभाग्य से, dbf फाइलें संग्रहीत जानकारी के उच्च घनत्व में भिन्न नहीं होती हैं, और उनमें बहुत सारे शून्य बाइट्स होते हैं।



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

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

तो, एल्गोरिथ्म ज्ञात है। केवल एक चीज बची है जो चाबी ढूंढना है।

चरण 2. प्रमुख खोज

कुंजी की खोज करने के लिए, हम सबसे पहले दुर्भावनापूर्ण प्रोग्राम के शरीर (या इस शरीर का क्या बचा है) को ढूंढते हैं। % SYSTEMROOT% \ System32 निर्देशिका में हमें 2 "अतिरिक्त" exe फाइलें मिलती हैं: system.exe और एक यादृच्छिक नाम (H3w2DWg.exe) के साथ एक और निष्पादन योग्य फ़ाइल। दोनों फाइलें ट्रोजन का एक हिस्सा हैं जो सिस्टम को संक्रमित करती हैं, हालांकि, डिटेक्शन (अप्रैल 2012) के समय की कोई भी फाइल एंटीवायरस द्वारा दुर्भावनापूर्ण नहीं मानी गई थी। फिलहाल, कुछ एंटीवायरस ट्रोजन को ट्रोजन के रूप में सही ढंग से पहचानते हैं। Encoder.136 (DrWeb) या Win32 / Filecoder.AF (ESET-NOD32) के रूप में, हालांकि, सबसे एंटीवायरस को लगता है कि यह सिर्फ थोड़ा संदिग्ध फ़ाइल है। यहाँ virustotal का लिंक दिया गया है।

एक बार ट्रोजन को एंटीवायरस द्वारा मान्यता प्राप्त नहीं होने पर, आपको इसे स्वयं विच्छेद करना होगा। Hiew32, OllyDbg और एक आभासी मशीन के साथ सशस्त्र, वह एक शव परीक्षा में आगे बढ़ा। एक शव परीक्षा से पता चला कि ट्रोजन की फाइलें पैक नहीं की गईं, एन्क्रिप्ट नहीं की गईं और बोरलैंड डेल्फी में लिखी गईं। अंदर, एन्क्रिप्टेड account.cfg, config.cfg और lock.cfg फ़ाइलों के लिंक भी पाए गए, जो% SYSTEMROOT% \ System32 में भी निहित हैं। Exe फ़ाइलों के आंत्रों में डिबगिंग करके, एक निश्चित कुंजी 32-वर्ण स्ट्रिंग "1kv9yha029v9vi71xioa7h812ga811n9" के रूप में भी पाई गई थी। इस कुंजी का उपयोग करके, ट्रोजन ने lock.cfg फ़ाइल को लॉक कर दिया।
यह समझना बाकी है कि यह स्ट्रिंग RC6 कुंजी में कैसे परिवर्तित होती है। RC6 कुंजी की लंबाई 128 बिट्स या अधिक से है। पहले प्रयास के रूप में, हम ASCII कोड का उपयोग करके प्रत्येक वर्ण को 8-बिट प्रतिनिधित्व में बदलने का प्रयास करेंगे। नतीजतन, हम लंबाई 32 * 8 = 256 बिट्स की कुंजी प्राप्त करते हैं। हम C ++ में एक प्रोग्राम लिखते हैं, इनपुट प्रोग्राम के लिए key और lock.cfg फाइल सबमिट करते हैं। हम डिक्रिप्शन प्रक्रिया शुरू करते हैं। असफल। फ़ाइल को डिक्रिप्ट नहीं किया गया था।

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

हम Google में चढ़ते हैं और डेल्फी RC6 कीवर्ड के साथ कुछ खोजते हैं। हमें लिंक http://www.delphi-club.ru/delphi/rc6_enc एन्क्रिप्शन . html मिल गया है। तो यह डेल्फी पर एक मॉड्यूल है, जो बिना फाइल के ब्लॉक वाली फाइल को एन्क्रिप्ट करता है और पिछले ब्लॉक को 16 बाइट्स से कम बिना लाइसेंस के छोड़ देता है। हम कार्यान्वयन से प्रमुख पीढ़ी की विशेषताओं को लेते हैं, उन्हें C ++ में फिर से लिखते हैं, डिक्रिप्शन प्रोग्राम को संकलित करते हैं। हम प्रोग्राम को 32-कैरेक्टर की कुंजी खिलाते हैं, लॉक.फग फ़ाइल को डिक्रिप्ट करने की कोशिश करते हैं। फिर से असफलता।

ओलीडबग और ट्रोजन के शरीर के साथ एक विकल्प था। मैं उस गुप्त एल्गोरिथ्म को प्राप्त करने के विवरण के साथ बोर नहीं होगा जिसके द्वारा कुंजी का गठन किया गया था, खासकर जब से प्रक्रिया खुद ही इतना समय नहीं लेती थी। रहस्य सरल था। ASCII एन्कोडिंग (32 वर्ण = 32 बाइट) में फ़ाइल के संसाधनों से कुंजी के साथ वर्णों की एक स्ट्रिंग को पढ़ा गया था, तब (जाहिर तौर पर डेल्फी द्वारा ही) UTF-16LE में परिवर्तित कर दिया गया था - 64 बाइट्स प्राप्त हुए थे (व्यवहार में, बाइट्स को केवल जीरो से पतला किया गया था)। और यह परिणाम पहले से ही प्रसिद्ध को खिलाया गया था, डॉल्फिन पर स्रोत कोड के लिए धन्यवाद, कुंजी प्राप्त करने के लिए एल्गोरिथ्म। आउटपुट पर कुंजी की लंबाई 512 बिट्स है।

Lock.cfg फ़ाइल को सफलतापूर्वक प्राप्त की के साथ डिक्रिप्ट किया गया था। फ़ाइल के अंदर, config.cfg और account.cfg के साथ-साथ होस्ट की फ़ाइल के माध्यम से ब्लॉक की जाने वाली साइटों के डोमेन नामों की एक सूची और "हानिकारक" प्रक्रियाओं (एंटीवायरस, फायरवॉल) की सूची के लिए एक कुंजी थी, जो ट्रोजन के अनुसार अवरुद्ध होने की संभावना है।

Account.cfg फ़ाइल में कुछ अतिरिक्त कुंजियाँ (उसी 32-लाइन स्ट्रिंग प्रारूप में), Money@Mail.ru के लिए खाता संख्या, किसी का ई-मेल पता, संक्रमित कंप्यूटर के बारे में जानकारी और कुछ अन्य छोटी जानकारी होती है। Config.cfg फ़ाइल में, अन्य बातों के अलावा, कंप्यूटर का एक आईपी-पता था, जो सभी संकेतों से, दुर्भावनापूर्ण प्रोग्राम का नियंत्रण सर्वर था।

हालाँकि, दुख की बात है कि फ़ाइलों में से कोई भी कुंजी संक्रमित कंप्यूटर के डिस्क पर फ़ाइलों को डिक्रिप्ट करने के लिए उपयुक्त नहीं थी। हमलावरों का एक और बयान सच निकला: फ़ाइलों को डिक्रिप्ट करने की कुंजी वास्तव में कंप्यूटर पर संग्रहीत नहीं है। आखिरी उम्मीद बनी रही - दुर्भावनापूर्ण प्रोग्राम के नियंत्रण सर्वर से कुंजी को हिला देना। ट्रोजन के लेखकों के संदेश के अनुसार, कुंजी 7 दिनों के लिए वहां संग्रहीत की जाती है, यह उस समय है कि इसे प्राप्त करने की आवश्यकता है, अन्यथा फ़ाइलों को डिक्रिप्ट नहीं किया जा सकता है - ऊपरी और निचले मामले में संख्याओं और लैटिन अक्षरों के संयोजन से 32-वर्ण की कुंजी का चयन करने में दशकों लगेंगे, और मूल्यवान के साथ फाइलें। दस्तावेजों की तत्काल आवश्यकता है।

स्टेज 3. प्रमुख नियंत्रण केंद्र के लिए

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

वर्चुअल मशीन पर एक साफ ऑपरेटिंग सिस्टम स्थापित किया गया था, वायरशर्क को मुख्य मशीन पर लॉन्च किया गया था, और वर्चुअल मशीन पर एक ट्रोजन। यह पता चला कि कनेक्शन टीसीपी पोर्ट 80 के माध्यम से एक अनएन्क्रिप्टेड कनेक्शन का उपयोग करता है। प्रारंभिक संक्रमण के दौरान, कंप्यूटर डेटा (ओएस, प्रोसेसर, मेमोरी) सर्वर पर भेजा जाता है, और अतिरिक्त ट्रोजन मॉड्यूल सर्वर से डाउनलोड किए जाते हैं, साथ ही एसएसएलवाई सीएल फाइलें, जो तब उपयोग की जाती हैं। साइट Money@Mail.ru के साथ काम करें।

सबसे अधिक संभावना है, जब सर्वर पर कंप्यूटर डेटा भेजते हैं, तो सर्वर पर एक कंप्यूटर खाता बनाया जाता है (यह ऑपरेटिंग सिस्टम को फिर से स्थापित करने पर अनुभाग में लेखकों के एक संदेश में संकेत था)। खाते के साथ, एक अद्वितीय कुंजी माना जाता है, जो बाद में हार्ड ड्राइव पर डेटा को एन्क्रिप्ट करता है। यह कुंजी आपको प्राप्त करने की आवश्यकता है।

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

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

परिणामस्वरूप, मैंने C ++ में एक प्रोग्राम जोड़ा, जो डिस्क पर सभी फाइलों को डिक्रिप्ट करता है। क्लाइंट को अपनी सभी फाइलें और डेस्कटॉप इसके अलावा वापस मिल गए।

निष्कर्ष

मैं अपने आप को एक वायरस विश्लेषक नहीं मानता और मुझे लगता है कि इस मामले में, जीत के रास्ते पर, हमलावरों की कई स्पष्ट गलतियों ने मेरी मदद की। सबसे पहले, मैलवेयर के लेखकों ने स्वयं उपयोगकर्ता को अपने संदेश में कई महत्वपूर्ण जानकारी दी: एन्क्रिप्शन एल्गोरिथ्म और तथ्य यह है कि कुंजी सर्वर पर संग्रहीत है। दूसरे, सर्वर के साथ आदान-प्रदान खुले चैनलों के माध्यम से एक काफी सरल पाठ प्रोटोकॉल का उपयोग करके किया गया था - इससे कुंजी प्राप्त करने की प्रक्रिया में काफी तेजी आई। तीसरा, ट्रोजन के लेखकों ने अपने उत्पाद को अपघटन और डिबगिंग से बचाने के बारे में बहुत परेशान नहीं किया, जिसने अंततः एन्क्रिप्शन और कुंजी रिसेप्शन एल्गोरिदम के विश्लेषण को सरल बनाया। और सामान्य धारणा: कोई व्यक्ति सिर्फ पैसे कम करना चाहता था, वास्तव में अपने उत्पाद को हैकिंग से बचाने की चिंता नहीं करता।

यह आशा की जाती है कि भविष्य में इस तरह के दुर्भावनापूर्ण कार्यक्रम व्यापक लोकप्रियता हासिल नहीं करेंगे। ऐसे हानिरहित विजेताओं से बेहतर हानिरहित विजेता हैं, जिनके लिए आप अपनी फ़ाइलों को हमेशा के लिए खो सकते हैं।