میں نے ایک خفیہ انجیکشن (Stealthy Injection) کو کیسے ٹریک کیا اور ماحول کو کیسے محفوظ بنایا
آپ مالویئر اسکین چلاتے ہیں۔ آپ کور فائلز کو تبدیل کرتے ہیں۔ آپ پلگ انز اپ ڈیٹ کرتے ہیں اور پاس ورڈز تبدیل کرتے ہیں۔ سائٹ بالکل صاف نظر آتی ہے۔
دو دن بعد، کلائنٹ کا فون آتا ہے۔ نئے ایڈمن اکاؤنٹس واپس آ چکے ہوتے ہیں۔ وزٹرز کو نقصان دہ سائٹس پر ری ڈائریکٹ کیا جا رہا ہوتا ہے۔
یہ 'پرسسٹنس' (persistence) کا ڈراونا خواب ہے۔
عام سیکیورٹی پلگ انز اکثر ناکام ہو جاتے ہیں۔ ماہر حملہ آور صرف ایک پے لوڈ (payload) نہیں چھوڑتے۔ وہ ایسے پیچیدہ بیک ڈورز (backdoors) بناتے ہیں جو جائز فائلوں کے اندر چھپے ہوتے ہیں۔
میں نے حال ہی میں ایک ایسا کیس سنبھالا جہاں صفائی کی تین کوششیں ناکام ہو گئیں۔ اس کی علامات مخصوص تھیں:
• گھوسٹ ایڈمنز (Ghost Admins): ہر 48 گھنٹے بعد بے ترتیب ناموں والے نئے اکاؤنٹس نمودار ہو جاتے۔ • کنڈیشنل ری ڈائریکٹس (Conditional Redirects): صرف سرچ انجنوں سے آنے والے نئے وزٹرز کو نقصان دہ سائٹ نظر آتی تھی۔ ڈویلپرز کو کچھ نظر نہیں آتا تھا۔
ٹیم پہلے ہی ورڈپریس کور (WordPress core) کو اوور رائٹ کر چکی تھی اور پلگ انز اپ ڈیٹ کر دیے تھے۔ اسکینرز میں کچھ نظر نہیں آ رہا تھا۔ مالویئر ایک ہائیڈرا (hydra) کی طرح دوبارہ پیدا ہو رہا تھا۔
حملہ آور نے ڈیٹا بیس میں یا ایک کرون جاب (cron job) میں ایک 'پرسسٹنس میکانزم' رکھا ہوا تھا۔ خودکار اسکینرز اسے پکڑ نہیں سکے کیونکہ کوڈ کسٹم (custom) تھا۔
میں نے حقیقت جاننے کے لیے کمانڈ لائن کا استعمال کیا۔
سب سے پہلے، میں نے چیک سمز (checksums) کا استعمال کرتے ہوئے کور فائلز کی تصدیق کی:
wp core verify-checksums
کور فائلز صاف تھیں۔ بیک ڈور wp-content یا ڈیٹا بیس میں موجود تھا۔
میں نے گزشتہ 7 دنوں میں تبدیل شدہ فائلوں کو تلاش کیا:
find . -type f -mtime -7 -name "*.php"
اس کے بعد، میں نے eval() یا base64_decode() جیسے مشکوک فنکشنز کو تلاش کیا:
grep -rnw './wp-content/' -e 'eval(' -e 'base64_decode('
مجھے ایک پرانے پریمیم پلگ ان میں ایک چھپی ہوئی فائل ملی۔ لیکن پلگ ان کو ڈیلیٹ کرنے سے انفیکشن نہیں رکا۔
حملہ آور نے wp_options ٹیبل میں cron آپشن کے تحت ایک ٹرگر چھوڑ دیا تھا۔ جب بھی ورڈپریس کرون (WordPress cron) چلتا، یہ ایک نیا پے لوڈ حاصل کر لیتا۔ صفائی کے چند منٹ بعد ہی یہ دوبارہ کور فائلز کو انفیکٹ کر دیتا تھا۔
اسے ٹھیک کرنے کے لیے، آپ کو ایک سخت ترتیب پر عمل کرنا ہوگا:
- ڈیٹا بیس کی صفائی (Database Scrubbing)
wp_optionsمیں نقصان دہ autoload ڈیٹا تلاش کریں۔- نامعلوم URLs کے لیے
wp_cronکو چیک کریں۔ - غیر مجاز صارفین کو براہ راست حذف کرنے کے لیے SQL کا استعمال کریں۔
- فائل سسٹم کی صفائی (File System Purge)
wp-config.phpاورwp-content/uploads/کے علاوہ ہر چیز ڈیلیٹ کر دیں۔- ہر چیز کو آفیشل ریپوزٹری سے تازہ فائلوں کے ساتھ تبدیل کریں۔
- اپ لوڈز فولڈر کے اندر موجود تمام PHP فائلیں ڈیلیٹ کر دیں۔
- کریڈنشلز کی تبدیلی (Credential Rotation)
wp-config.phpمیں تمام آتھنٹیکیشن سالٹس (authentication salts) کو دوبارہ جنریٹ کریں۔- تمام ڈیٹا بیس، SSH، اور ہوسٹنگ پاس ورڈز ری سیٹ کریں۔
میں نے دوبارہ ایسا ہونے سے روکنے کے لیے تین حفاظتی اقدامات (guardrails) بھی نافذ کیے:
• ایج پروٹیکشن (Edge Protection): میں نے حساس ڈائریکٹریز پر مشکوک POST درخواستوں کو روکنے کے لیے Cloudflare WAF کا استعمال کیا۔ • فائل پرمیشنز (File Permissions): میں نے ڈائریکٹری اسٹرکچر کو لاک کر دیا۔ ڈائریکٹریز کو 755 اور فائلوں کو 644 پر سیٹ کر دیا۔ میں نے wp-config.php کو read-only پر سیٹ کر دیا۔ • ایڈیٹنگ کو غیر فعال کرنا (Disable Editing): میں نے 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