WP-CLI और SQL के साथ वर्डप्रेस बैकडोर खोजने का तरीका
makedream٣٠ يوليو ٢٠٢٦
0
Internet Technology
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
आउटसोर्स की गई वर्डप्रेस साइट पर 'कोर अपडेट' बटन दबाने से पहले कोई भी हिचकिचाएगा। थीम या कस्टम प्लगइन्स के बिगड़ने और स्क्रीन के सफेद होने (White Screen of Death) के डर से टालते-टालते, साइट सुरक्षा खामियों (vulnerabilities) से भर जाती है। जब यह डर सताने लगे कि साइट पहले ही हैक हो चुकी हो सकती है, तो डेटाबेस और सर्वर की तुरंत जाँच करने की व्यावहारिक प्रक्रिया यहाँ दी गई है।
हमलावर आमतौर पर बिना कोई ध्यान आकर्षित किए प्रवेश करते हैं। वे डेटाबेस की wp_usermeta टेबल को सीधे संशोधित करके मौजूदा खातों को चुपके से एडमिनिस्ट्रेटर (प्रशासक) अनुमतियाँ दे देते हैं। यह सामान्य लॉगिन सूची में आसानी से नहीं दिखाई देता है, लेकिन DB को सीधे क्वेरी करने पर तुरंत सामने आ जाता है।
`sql
SELECT
u.ID,
u.user_login,
u.user_email,
u.user_registered,
m.meta_value AS capabilities
FROM
wp_users u
INNER JOIN
wp_usermeta m ON u.ID = m.user_id
WHERE
m.meta_key = 'wp_capabilities'
AND (
m.meta_value LIKE '%"administrator"%'
OR m.meta_value LIKE '%"administrator":true%'
)
ORDER BY
u.user_registered DESC;
`
अगला कदम फ़ाइल सिस्टम की जाँच करना है। यदि wp-content/uploads डायरेक्टरी में, जहाँ केवल चित्र या दस्तावेज़ होने चाहिए, कोई PHP फ़ाइल मिलती है, तो यह 10 में से 9 बार बैकडोर ही होती है। SSH टर्मिनल खोलें और खतरनाक फ़ाइलों की खोज करें।
`bash
find wp-content/uploads/ -type f -name "*.php" -ls
find . -type f -name "*.php" -exec grep -HnE "(eval(|base64_decode(|gzinflate(|passthru(|shell_exec()" {} ;
wp core verify-checksums --include-root
`
लॉग्स की भी जाँच की जानी चाहिए। REST API को लक्षित करने वाले हमले आमतौर पर कम समय में कई POST अनुरोध भेजते हैं और 200 या 201 प्रतिक्रियाएँ प्राप्त करते हैं। Nginx access.log से संदिग्ध व्यवहार दिखाने वाले अनुरोध निकालें।
`bash
grep -E "POST|PUT" /var/log/nginx/access.log | grep -E "/wp-json/|rest_route=" | awk '/ {print $1, $4, $6, $7, $9}' | sort | uniq -c | sort -nr | head -n 30
`
लाइव (운영 중인) साइट पर सीधे पैच लगाना साहस नहीं, बल्कि लापरवाही है। पहले एक स्टेजिंग वातावरण बनाएं जो पूरे डेटाबेस और फ़ाइल सिस्टम को क्लोन करता हो।
`bash
wp db export production_backup.sql --add-drop-table
rsync -avz --exclude='wp-content/cache' /var/www/html/ staging:/var/www/staging/
wp db import production_backup.sql
wp search-replace 'https://example.com' 'https://staging.example.com' --skip-columns=guid
wp plugin list --update=available --fields=name,version,update_version,requires_php --format=table
`
क्लोनिंग पूरी होने के बाद, अपडेट चलाएँ और केवल 5 मिनट के लिए मुख्य सुविधाओं का परीक्षण करें। मन की शांति के लिए सदस्य पंजीकरण, लॉगिन, कार्ट में जोड़ना, भुगतान विंडो खोलना और पूछताछ फ़ॉर्म सबमिट करना स्वयं करके देखें।
ऐसी स्थितियाँ भी होती हैं जहाँ प्लगइन डेवलपर अपडेट प्रदान नहीं करता है, जिससे आप तुरंत कोर को अपडेट करने में असमर्थ होते हैं। ऐसे मामलों में, सर्वर स्तर या WAF पर कुछ मार्गों (paths) तक पहुँच को अवरुद्ध करके समय प्राप्त करें। यदि आप Nginx का उपयोग कर रहे हैं, तो अपने स्वयं के IP को छोड़कर REST API उपयोगकर्ता निर्माण और बैच प्रोसेसिंग एंडपॉइंट्स को nginx.conf में ब्लॉक कर दें।
`nginx
location ~* ^/wp-json/(batch/v1|wp/v2/users) {
limit_except GET {
allow 192.0.2.1;
deny all;
}
try_files $uri args;
}
`
किसी भी अप्रत्याशित स्थिति के लिए, अतिरिक्त सुरक्षा के रूप में DB और अपलोड फ़ोल्डर को S3 पर अपलोड करने वाली एक बैकअप स्क्रिप्ट भी सेट करें।
`bash
#!/bin/bash
WP_PATH="/var/www/html"
BACKUP_DIR="/tmp/wp_backups"
DATE=$(date +%Y%m%d_%H%M%S)
S3_BUCKET="s3://my-wordpress-secure-backups"
mkdir -p $BACKUP_DIR
wp db export BACKUP_DIR/db_DATE.sql --path=$WP_PATH --quiet
tar -czf BACKUP_DIR/files_DATE.tar.gz -C $WP_PATH wp-content/uploads/
aws s3 cp BACKUP_DIR/db_DATE.sql S3_BUCKET/db_DATE.sql
aws s3 cp BACKUP_DIR/files_DATE.tar.gz S3_BUCKET/files_DATE.tar.gz
find $BACKUP_DIR -type f -mtime +7 -delete
`
दुर्भावनापूर्ण कोड को हटाने और सुरक्षा पैच लागू करने के बाद भी काम पूरा नहीं होता है, क्योंकि हमलावर चोरी की गई सेशन कुकीज़ का उपयोग करके फिर से प्रवेश कर सकता है। सभी सत्रों को समाप्त करें और wp-config.php की साल्ट कुंजियों (salt keys) को पूरी तरह बदल दें।
`bash
wp user list --field=ID | xargs -n 1 wp user session destroy --all
wp config shuffle-salts
`
एडमिन पैनल के भीतर से सीधे प्लगइन या थीम फ़ाइलों को संपादित करने की सुविधा को भी अक्षम (disable) कर दें। यह एक न्यूनतम सुरक्षा उपाय है जो हमलावर के पास अनुमतियाँ होने पर भी कोड इंजेक्शन को रोकता है। wp-config.php में निम्नलिखित दो पंक्तियाँ जोड़ें:
`php
define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );
`
अंत में, गैर-लॉग-इन उपयोगकर्ताओं को REST API के माध्यम से उपयोगकर्ता सूची चुराने से रोकने के लिए mu-plugins डायरेक्टरी में एक समर्पित फ़िल्टर जोड़ें।
`php
<?php
/**
`