𝗛𝗼𝘄 𝗜 𝗧𝗿𝗮𝗰𝗸𝗲𝗱 𝗮 𝗦𝘁𝗲𝗮𝗹𝘁𝗵𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗛𝗮𝗿𝗱𝗲𝗻𝗲𝗱 𝘁𝗵𝗲 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁

तुम्ही मालवेअर स्कॅन करता. तुम्ही कोअर फाइल्स बदलता. तुम्ही प्लगइन्स अपडेट करता आणि पासवर्ड बदलता. साइट स्वच्छ दिसते.

दोन दिवसांनंतर, क्लायंटचा फोन येतो. नवीन ॲडमिन अकाउंट्स परत आले आहेत. व्हिजिटर्सना (Visitors) घातक साइट्सवर रिडायरेक्ट केले जात आहे.

ही 'पर्सिस्टन्स'ची (persistence) भीतीदायक स्थिती आहे.

मानक सुरक्षा प्लगइन्स अनेकदा अपयशी ठरतात. प्रगत हल्लेखोर केवळ एकच पेलोड (payload) सोडत नाहीत. ते वैध फाइल्समध्ये लपलेले नेस्टेड बॅकडोअर्स (nested backdoors) तयार करतात.

मी अलीकडेच अशा एका प्रकरणाची हाताळणी केली जिथे तीन वेळा स्वच्छता (cleanup) करण्याचा प्रयत्न करूनही तो अयशस्वी ठरला. त्याची लक्षणे विशिष्ट होती:

• घोस्ट ॲडमिन्स (Ghost Admins): दर ४८ तासांनी यादृच्छिक नावांची नवीन अकाउंट्स तयार होत होती. • कंडिशनल रिडायरेक्ट्स (Conditional Redirects): केवळ सर्च इंजिनवरून येणाऱ्या नवीन व्हिजिटर्सनाच ती घातक साइट दिसत होती. डेव्हलपर्सना काहीही दिसत नव्हते.

टीमने आधीच वर्डप्रेस कोअर (WordPress core) ओव्हरराईट केले होते आणि प्लगइन्स अपडेट केले होते. स्कॅनर्समध्ये काहीही दिसून आले नाही. मालवेअर एखाद्या 'हायड्रा'प्रमाणे (hydra) पुन्हा पुन्हा तयार होत होते.

हल्लेखोराकडे डेटाबेसमध्ये किंवा क्रॉन जॉबमध्ये (cron job) एक 'पर्सिस्टन्स मेकॅनिझम' होते. कोड कस्टम असल्यामुळे ऑटोमेटेड स्कॅनर्सनी ते ओळखले नाही.

सत्य शोधण्यासाठी मी कमांड लाईनचा (command line) वापर केला.

प्रथम, मी चेकसमचा (checksums) वापर करून कोअर फाइल्सची पडताळणी केली: wp core verify-checksums

कोअर स्वच्छ होते. बॅकडोअर wp-content किंवा डेटाबेसमध्ये होता.

मी गेल्या ७ दिवसांत बदललेल्या फाइल्स शोधल्या: find . -type f -mtime -7 -name "*.php"

मग, मी eval() किंवा base64_decode() सारख्या संशयास्पद फंक्शन्सचा शोध घेतला: grep -rnw './wp-content/' -e 'eval(' -e 'base64_decode('

मला एका जुन्या प्रीमियम प्लगइनमध्ये एक लपलेली फाईल सापडली. पण प्लगइन डिलीट केल्याने संसर्ग थांबला नाही.

हल्लेखोराने wp_options टेबलमध्ये cron ऑप्शन अंतर्गत एक ट्रिगर सोडला होता. प्रत्येक वेळी जेव्हा वर्डप्रेस क्रॉन (WordPress cron) चालत असे, तेव्हा तो एक नवीन पेलोड मिळवत असे. कोअर फाइल्स स्वच्छ केल्याच्या काही मिनिटांतच तो पुन्हा संसर्ग पसरवत असे.

हे दुरुस्त करण्यासाठी, तुम्ही खालील कडक क्रम पाळला पाहिजे:

  1. डेटाबेस स्क्रबिंग (Database Scrubbing)
  1. फाईल सिस्टम पर्ज (File System Purge)
  1. क्रेडेंशियल रोटेशन (Credential Rotation)

पुनरावृत्ती टाळण्यासाठी मी तीन सुरक्षा उपाय (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