मैंने एक गुप्त इंजेक्शन (Stealthy Injection) को कैसे ट्रैक किया और वातावरण को कैसे सुरक्षित (Harden) बनाया
आप एक मालवेयर स्कैन चलाते हैं। आप कोर फाइलों को बदल देते हैं। आप प्लगइन्स को अपडेट करते हैं और पासवर्ड बदल देते हैं। साइट साफ दिखती है।
दो दिन बाद, क्लाइंट का फोन आता है। नए एडमिन अकाउंट वापस आ गए हैं। विज़िटर्स को दुर्भावनापूर्ण (malicious) साइटों पर रीडायरेक्ट किया जा रहा है।
यह 'परसिस्टेंस' (persistence) का दुःस्वप्न है।
मानक सुरक्षा प्लगइन्स अक्सर विफल हो जाते हैं। परिष्कृत हमलावर केवल एक पेलोड नहीं छोड़ते हैं। वे नेस्टेड बैकडोर (nested backdoors) बनाते हैं जो वैध फाइलों के अंदर छिपे रहते हैं।
मैंने हाल ही में एक ऐसा मामला संभाला जहाँ सफाई के तीन प्रयास विफल रहे। लक्षण विशिष्ट थे:
• घोस्ट एडमिन्स (Ghost Admins): हर 48 घंटे में रैंडम नामों वाले नए अकाउंट दिखाई देते थे। • कंडीशनल रीडायरेक्ट्स (Conditional Redirects): केवल सर्च इंजन से आने वाले नए विज़िटर्स को ही दुर्भावनापूर्ण साइट दिखाई देती थी। डेवलपर्स को कुछ भी दिखाई नहीं देता था।
टीम पहले ही WordPress कोर को ओवरराइट कर चुकी थी और प्लगइन्स अपडेट कर दिए थे। स्कैनर्स में कुछ भी नहीं दिखा। मालवेयर हाइड्रा (hydra) की तरह फिर से पैदा हो रहा था।
हमलावर के पास डेटाबेस में या क्रॉन जॉब (cron job) में एक परसिस्टेंस मैकेनिज्म था। ऑटोमेटेड स्कैनर्स इसे नहीं पकड़ पाए क्योंकि कोड कस्टम था।
मैंने सच्चाई का पता लगाने के लिए कमांड लाइन का उपयोग किया।
सबसे पहले, मैंने चेकसम (checksums) का उपयोग करके कोर फाइलों को सत्यापित किया:
wp core verify-checksums
कोर साफ था। बैकडोर wp-content या डेटाबेस में था।
मैंने पिछले 7 दिनों में संशोधित (modified) फाइलों को खोजा:
find . -type f -mtime -7 -name "*.php"
फिर, मैंने eval() या base64_decode() जैसे संदिग्ध फंक्शन्स को खोजा:
grep -rnw './wp-content/' -e 'eval(' -e 'base64_decode('
मुझे एक पुराने प्रीमियम प्लगइन में एक दबी हुई फाइल मिली। लेकिन प्लगइन को डिलीट करने से संक्रमण (infection) नहीं रुका।
हमलावर ने wp_options टेबल में cron विकल्प के तहत एक ट्रिगर छोड़ दिया था। हर बार जब WordPress cron चलता था, तो यह एक नया पेलोड प्राप्त कर लेता था। सफाई के कुछ ही मिनटों बाद यह कोर फाइलों को फिर से संक्रमित कर देता था।
इसे ठीक करने के लिए, आपको एक सख्त क्रम का पालन करना चाहिए:
- डेटाबेस स्क्रबिंग (Database Scrubbing)
- दुर्भावनापूर्ण ऑटोलोड डेटा के लिए
wp_optionsमें खोजें। - अज्ञात URL के लिए
wp_cronकी जाँच करें। - अनधिकृत उपयोगकर्ताओं को सीधे हटाने के लिए SQL का उपयोग करें।
- फ़ाइल सिस्टम पर्ज (File System Purge)
wp-config.phpऔरwp-content/uploads/को छोड़कर बाकी सब कुछ डिलीट कर दें।- सब कुछ आधिकारिक रिपॉजिटरी (official repository) से नई फाइलों के साथ बदल दें।
uploadsफोल्डर के अंदर की किसी भी PHP फाइल को डिलीट कर दें।
- क्रेडेंशियल रोटेशन (Credential Rotation)
wp-config.phpमें सभी ऑथेंटिकेशन साल्ट्स (authentication salts) को फिर से जेनरेट करें।- सभी डेटाबेस, SSH और होस्टिंग पासवर्ड रीसेट करें।
मैंने दोबारा ऐसा होने से रोकने के लिए तीन गार्डरेल्स (guardrails) भी लागू किए:
• एज प्रोटेक्शन: मैंने संवेदनशील डायरेक्टरीज़ पर संदिग्ध POST रिक्वेस्ट को ब्लॉक करने के लिए Cloudflare WAF का उपयोग किया।
• फ़ाइल परमिशन्स: मैंने डायरेक्टरी स्ट्रक्चर को लॉक कर दिया। डायरेक्टरीज़ को 755 और फ़ाइलों को 644 कर दिया गया। मैंने wp-config.php को read-only पर सेट कर दिया।
• एडिटिंग डिसेबल करें: मैंने wp-config.php में DISALLOW_FILE_EDIT और DISALLOW_FILE_MODS जोड़ दिया। यह किसी को भी डैशबोर्ड के माध्यम से कोड बदलने से रोकता है।
किसी प्लगइन के ग्रीन चेकमार्क पर भरोसा न करें। मान लें कि सुरक्षा में सेंध (breach) लग चुकी है। अपनी साइट को अंदर से बाहर तक सुरक्षित करें।
स्रोत: https://dev.to/jahidshah/how-i-tracked-a-stealthy-injection-and-hardened-the-environment-4clm