खतरनाक हैक: Oracle डेटाबेस को पोस्ट-एक्सप्लॉइटेशन प्लेटफॉर्म में कैसे बदला गया?

वहां से, हैकर्स ने अंतर्निहित Windows ऑपरेटिंग सिस्टम (OS) तक पहुंच बनाई, पूर्ण SYSTEM-स्तरीय रिमोट कोड एक्जीक्यूशन (RCE) हासिल किया, पासवर्ड हैश वाले रजिस्ट्री हाइव्स निकाले, और उन्हें ऑफलाइन एक्सफिल्ट्रेट कर लिया । हंट्रेस ने हमलावर के इंफ्रास्ट्रक्चर को IP 178.162.151[.]229 पर ट्रेस किया ।

हमला कैसे हुआ: ऑटोकम्प्लीट सर्च के ज़रिए SQL इंजेक्शन

हमले का शुरुआती रास्ता Apache Tomcat पर चल रहे एक सार्वजनिक Java एप्लिकेशन में SQL इंजेक्शन की कमजोरी थी । एप्लिकेशन का ऑटोकम्प्लीट सर्च फीचर यूजर इनपुट को ठीक से वैलिडेट करने में विफल रहा, जिससे हैकर्स Oracle डेटाबेस के JDBC कनेक्शन के माध्यम से SQL कमांड इंजेक्ट करने में सफल हो गए । हंट्रेस के शोधकर्ताओं के अनुसार, यह कोई नई कमजोरी नहीं थी—SQL इंजेक्शन हमले दशकों से मौजूद हैं और आमतौर पर SQL सर्वर को भेजे जाने वाले यूजर इनपुट को गलत तरीके से हैंडल करने का परिणाम होते हैं । एक साधारण सर्च फील्ड को सैनिटाइज़ न करना ही पूरे सिस्टम से समझौता करने के लिए काफी था।

द खंट टूलकिट: डेटाबेस के अंदर Java ऑब्जेक्ट के रूप में

पारंपरिक मैलवेयर फाइलों को तैनात करने के बजाय, हैकर्स ने Oracle के बिल्ट-इन JVM और CREATE JAVA SOURCE स्टेटमेंट का उपयोग करके पूरी पोस्ट-एक्सप्लॉइटेशन टूलकिट को Oracle डेटाबेस के अंदर Java स्कीमा ऑब्जेक्ट के रूप में कंपाइल और स्टोर किया । यह तरीका मानक OS-स्तरीय सुरक्षा से अदृश्य था क्योंकि EDR और एंटीवायरस टूल्स ऑपरेटिंग सिस्टम पर प्रोसेसेस, बाइनरी और फाइलों पर ध्यान केंद्रित करते हैं—वे आमतौर पर Oracle के अंदर स्टोर Java क्लासेस और PL/SQL रैपर्स की जांच नहीं करते ।

खंट टूलकिट में ये कंपोनेंट शामिल थे, जिनमें से प्रत्येक एक डेटाबेस ऑब्जेक्ट के रूप में स्टोर किया गया था:

पूर्ण सिस्टम कंट्रोल: डेटाबेस से Windows OS तक का सफर

हैकर्स सिर्फ डेटाबेस-स्तरीय एक्सेस तक नहीं रुके। उन्होंने खंट टूलकिट का उपयोग करके बहु-चरणीय प्रक्रिया में डेटाबेस लेयर से अंतर्निहित Windows ऑपरेटिंग सिस्टम तक पहुंच बनाई:

1. KhuntCmd के माध्यम से OS कमांड निष्पादन: उन्होंने cmd.exe /c whoami चलाने के लिए KhuntCmd मॉड्यूल का उपयोग किया, जिससे पुष्टि हुई कि वे Windows सर्वर पर SYSTEM-स्तरीय विशेषाधिकारों के साथ चल रहे थे, जिसने डेटाबेस से OS तक RCE स्थापित कर दिया ।
2. क्रेडेंशियल चोरी: उन्होंने PowerShell का उपयोग करके reg.exe को इनवोक किया और SECURITY और SYSTEM रजिस्ट्री हाइव्स की कॉपी बनाई, उन्हें F:\Oracle\ में khuntSECURITY.hiv और khuntSYSTEM.hiv के रूप में सेव किया ।
3. सर्विस एन्यूमरेशन: उन्होंने tasklist /svc चलाया और आउटपुट को khunttasks.txt के रूप में सेव किया ।
4. अतिरिक्त हाइव निष्कर्षण: उन्होंने SAM और SECURITY हाइव्स की दूसरी कॉपी को कॉपी करने के लिए esentutl.exe का उपयोग किया, उन्हें khuntSAM.hiv और khunt_SECURITY.hiv के रूप में सेव किया ।

एक्सफिल्ट्रेट किए गए रजिस्ट्री हाइव्स का उपयोग ऑफलाइन होकर सिस्टम पर सभी स्थानीय खातों के पासवर्ड हैश निकालने और डीकोड करने के लिए किया जा सकता था ।

डिफेंस ब्लाइंड स्पॉट्स: हंट्रेस के प्रमुख निष्कर्ष

हंट्रेस की जांच ने कई महत्वपूर्ण ब्लाइंड स्पॉट्स का खुलासा किया, जिन्होंने इस हमले को सफल होने और पकड़ में न आने में मदद की:

• डेटाबेस-ए-बीचहेड शिफ्ट: डेटाबेस एक निष्क्रिय डेटा स्टोर से एक सक्रिय अटैक प्लेटफॉर्म में बदल गया था, जिसमें दुर्भावनापूर्ण टूलकिट डिस्क या मेमोरी के बजाय डेटाबेस के अंदर रहता था ।
• EDR/AV बाईपास: पारंपरिक EDR और एंटीवायरस टूल्स आमतौर पर Oracle के अंदर स्टोर Java क्लासेस और PL/SQL रैपर्स की जांच नहीं करते, जिससे टूलकिट मानक OS-स्तरीय सुरक्षा के लिए अदृश्य हो गया ।
• क्लासिक कमजोरी, नवीन डिलीवरी: शुरुआती SQL इंजेक्शन एक जानी-मानी बग क्लास थी। किसी जीरो-डे की जरूरत नहीं थी। ऑटोकम्प्लीट सर्च फीचर PL/SQL और फिर OS तक पहुंचने के लिए काफी था, जो दिखाता है कि बुनियादी इनपुट वैलिडेशन की विफलता गहरे समझौते का कारण बन सकती है जब डेटाबेस इंजन में OS-स्तरीय क्षमताएं हों ।
• ओवरप्रूविज़न्ड डेटाबेस अकाउंट्स: SQL इंजेक्शन के सफल होने के बाद भी, नुकसान सीमित होता है अगर डेटाबेस यूजर अकाउंट के पास Java सोर्स बनाने या स्टोर्ड प्रोसीज़र निष्पादित करने के विशेषाधिकार न हों। संगठन अक्सर डेटाबेस अकाउंट्स को ओवरप्रूविज़न कर देते हैं, जिससे हैकर्स को खंट को तैनात करने के लिए अतिरिक्त अनुमतियां मिल जाती हैं ।

हंट्रेस द्वारा अनुशंसित उपाय

इस हमले के आधार पर, हंट्रेस ने कई उपायों की सिफारिश की :

• सभी वेब इनपुट के लिए उचित इनपुट सैनिटाइज़ेशन और क्वेरी पैरामीटराइज़ेशन
• डेटाबेस यूजर विशेषाधिकारों को प्रतिबंधित करना ताकि इंजेक्टेड क्वेरी भी Java सोर्स न बना सकें या मनमानी स्टोर्ड प्रोसीज़र निष्पादित न कर सकें
• केवल OS-स्तरीय आर्टिफैक्ट्स के बजाय डेटाबेस ऑब्जेक्ट्स (Java क्लासेस, PL/SQL रैपर्स) को शामिल करने के लिए मॉनिटरिंग का दायरा बढ़ाना

यह हमला एक कड़ी चेतावनी है कि बिल्ट-इन प्रोग्रामिंग एनवायरनमेंट (जैसे Oracle का JVM) वाले डेटाबेस इंजन, एक भी अनवैलिडेटेड इनपुट फील्ड के साथ मिलकर, चुपके से हमले का मंच बन सकते हैं। सुरक्षा टीमों को अपनी निगरानी ऑपरेटिंग सिस्टम से आगे बढ़ाकर डेटाबेस ऑब्जेक्ट लेयर तक करनी चाहिए।