𝗛𝗼𝘄 𝗜 𝗧𝗿𝗮𝗰𝗸𝗲𝗱 𝗮 𝗦𝘁𝗲𝗮𝗹𝘁𝗵𝘆 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻 𝗮𝗻𝗱 𝗛𝗮𝗿𝗱𝗲𝗻𝗲𝗱 𝘁𝗵𝗲 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁
ਤੁਸੀਂ ਮਾਲਵੇਅਰ ਸਕੈਨ ਚਲਾਉਂਦੇ ਹੋ। ਤੁਸੀਂ ਕੋਰ ਫਾਈਲਾਂ ਨੂੰ ਬਦਲਦੇ ਹੋ। ਤੁਸੀਂ ਪਲੱਗਇਨ ਅਪਡੇਟ ਕਰਦੇ ਹੋ ਅਤੇ ਪਾਸਵਰਡ ਬਦਲਦੇ ਹੋ। ਸਾਈਟ ਸਾਫ਼ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।
ਦੋ ਦਿਨਾਂ ਬਾਅਦ, ਕਲਾਇੰਟ ਦਾ ਫ਼ੋਨ ਆਉਂਦਾ ਹੈ। ਨਵੇਂ ਐਡਮਿਨ ਖਾਤੇ ਵਾਪਸ ਆ ਗਏ ਹਨ। ਵਿਜ਼ਿਟਰਜ਼ ਨੂੰ ਮਾਲੀਸ਼ੀਅਸ (malicious) ਸਾਈਟਾਂ 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ।
ਇਹ 'ਪਰਸਿਸਟੈਂਸ' (persistence) ਦਾ ਇੱਕ ਡਰਾਉਣਾ ਸੁਪਨਾ ਹੈ।
ਸਟੈਂਡਰਡ ਸੁਰੱਖਿਆ ਪਲੱਗਇਨ ਅਕਸਰ ਅਸਫਲ ਰਹਿੰਦੇ ਹਨ। ਸੋਸ਼ਲ (sophisticated) ਹਮਲਾਵਰ ਸਿਰਫ਼ ਇੱਕ ਪੇਲੋਡ (payload) ਨਹੀਂ ਛੱਡਦੇ। ਉਹ ਅੰਦਰੂਨੀ ਬੈਕਡੋਰ (backdoors) ਬਣਾਉਂਦੇ ਹਨ ਜੋ ਜਾਇਜ਼ ਫਾਈਲਾਂ ਦੇ ਅੰਦਰ ਲੁਕੇ ਹੁੰਦੇ ਹਨ।
ਮੈਂ ਹਾਲ ਹੀ ਵਿੱਚ ਇੱਕ ਅਜਿਹਾ ਮਾਮਲਾ ਸੰਭਾਲਿਆ ਜਿੱਥੇ ਸਫਾਈ ਦੇ ਤਿੰਨ ਯਤਨ ਅਸਫਲ ਰਹੇ। ਲੱਛਣ ਖਾਸ ਸਨ:
• Ghost Admins: ਹਰ 48 ਘੰਟਿਆਂ ਬਾਅਦ ਰੈਂਡਮ ਨਾਵਾਂ ਵਾਲੇ ਨਵੇਂ ਖਾਤੇ ਦਿਖਾਈ ਦੇ ਰਹੇ ਸਨ। • Conditional Redirects: ਸਿਰਫ਼ ਸਰਚ ਇੰਜਣਾਂ ਤੋਂ ਆਉਣ ਵਾਲੇ ਨਵੇਂ ਵਿਜ਼ਿਟਰਜ਼ ਨੂੰ ਹੀ ਮਾਲੀਸ਼ੀਅਸ ਸਾਈਟ ਦਿਖਾਈ ਦਿੰਦੀ ਸੀ। ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਕੁਝ ਵੀ ਦਿਖਾਈ ਨਹੀਂ ਦੇ ਰਿਹਾ ਸੀ।
ਟੀਮ ਪਹਿਲਾਂ ਹੀ WordPress core ਨੂੰ ਓਵਰਰਾਈਟ ਕਰ ਚੁੱਕੀ ਸੀ ਅਤੇ ਪਲੱਗਇਨ ਅਪਡੇਟ ਕਰ ਦਿੱਤੇ ਸਨ। ਸਕੈਨਰਾਂ ਨੇ ਕੁਝ ਨਹੀਂ ਦਿਖਾਇਆ। ਮਾਲਵੇਅਰ ਇੱਕ ਹਾਈਡਰਾ (hydra) ਵਾਂਗ ਦੁਬਾਰਾ ਪੈਦਾ ਹੋ ਰਿਹਾ ਸੀ।
ਹਮਲਾਵਰ ਕੋਲ ਡੇਟਾਬੇਸ ਵਿੱਚ ਜਾਂ ਇੱਕ cron job ਵਿੱਚ ਪਰਸਿਸਟੈਂਸ ਮਕੈਨਿਜ਼ਮ ਸੀ। ਆਟੋਮੇਟਿਡ ਸਕੈਨਰਾਂ ਨੇ ਇਸਨੂੰ ਮਿਸ ਕਰ ਦਿੱਤਾ ਕਿਉਂਕਿ ਕੋਡ ਕਸਟਮ ਸੀ।
ਮੈਂ ਸੱਚਾਈ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕਮਾਂਡ ਲਾਈਨ (command line) ਦੀ ਵਰਤੋਂ ਕੀਤੀ।
ਪਹਿਲਾਂ, ਮੈਂ 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 ਚੱਲਦਾ ਸੀ, ਇਹ ਇੱਕ ਨਵਾਂ ਪੇਲੋਡ (payload) ਲਿਆਉਂਦਾ ਸੀ। ਸਾਫ਼ ਕੀਤੇ ਜਾਣ ਤੋਂ ਕੁਝ ਮਿੰਟਾਂ ਬਾਅਦ ਹੀ ਇਹ ਕੋਰ ਫਾਈਲਾਂ ਨੂੰ ਦੁਬਾਰਾ ਇਨਫੈਕਟ ਕਰ ਦਿੰਦਾ ਸੀ।
ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇੱਕ ਸਖ਼ਤ ਕ੍ਰਮ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:
- Database Scrubbing
- ਮਾਲੀਸ਼ੀਅਸ autoload ਡੇਟਾ ਲਈ wp_options ਵਿੱਚ ਖੋਜ ਕਰੋ।
- ਅਣਜਾਣ URLs ਲਈ wp_cron ਦੀ ਜਾਂਚ ਕਰੋ।
- ਅਣਅਧਿਕਾਰਤ (unauthorized) ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਡਿਲੀਟ ਕਰਨ ਲਈ SQL ਦੀ ਵਰਤੋਂ ਕਰੋ।
- File System Purge
- wp-config.php ਅਤੇ wp-content/uploads/ ਨੂੰ ਛੱਡ ਕੇ ਸਭ ਕੁਝ ਡਿਲੀਟ ਕਰ ਦਿਓ।
- ਸਭ ਕੁਝ ਅਧਿਕਾਰਤ ਰਿਪੋਜ਼ਟਰੀ (official repository) ਤੋਂ ਤਾਜ਼ੀਆਂ ਫਾਈਲਾਂ ਨਾਲ ਬਦਲ ਦਿਓ।
- uploads ਫੋਲਡਰ ਦੇ ਅੰਦਰ ਕਿਸੇ ਵੀ PHP ਫਾਈਲਾਂ ਨੂੰ ਡਿਲੀਟ ਕਰ ਦਿਓ।
- Credential Rotation
- wp-config.php ਵਿੱਚ ਸਾਰੇ authentication salts ਨੂੰ ਦੁਬਾਰਾ ਬਣਾਓ (regenerate)।
- ਸਾਰੇ ਡੇਟਾਬੇਸ, 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