هک وردپرس با فایل htaccess یکی از حملاتی است که می‌تواند با ایجاد یا تغییر فایل‌های متعدد در سرور، امنیت سایت را به خطر بیندازد. در این مقاله یک نمونه واقعی از این حمله را بررسی می‌کنم که طی آن بیش از 200 فایل مشکوک در مسیرهای مختلف یک سایت وردپرسی ایجاد شده بود.

در این مقاله قصد دارم یک نمونه واقعی از هک وردپرس با فایل .htaccess را بررسی کنم که روی یکی از سایت‌های وردپرسی من اتفاق افتاد. در جریان بررسی، بیش از 200 فایل .htaccess مشکوک در مسیرهای مختلف سایت پیدا شد و در کنار آن نشانه‌هایی از Japanese SEO Spam نیز در Google Search Console مشاهده شد.

در ادامه مرحله‌به‌مرحله توضیح می‌دهم که حمله چگونه شناسایی شد، چه نشانه‌هایی داشت، چطور فایل‌های آلوده را پیدا کردم و در نهایت چه تغییراتی برای افزایش امنیت WordPress و WooCommerce انجام دادم.

اولین نشانه حمله؛ صفحات و محصولات ژاپنی در گوگل

اولین نشانه جدی زمانی دیده شد که Google Search Console و Merchant Listings اطلاعاتی درباره محصولاتی با عنوان‌های ژاپنی نمایش می‌دادند؛ محصولاتی که اصلاً در سایت وجود نداشتند.

این نوع حمله معمولاً با عنوان Japanese SEO Spam شناخته می‌شود. مهاجم تلاش می‌کند صفحات، Structured Data یا محتوای مخفی ایجاد کند تا سایت قربانی برای عبارت‌های اسپم در گوگل ایندکس شود.

نکته مهم این بود که هنگام بررسی مستقیم سایت، بسیاری از این محتواها دیگر دیده نمی‌شدند. بنابراین احتمال وجود فایل‌های مخرب قدیمی، Cloaking یا تغییرات قبلی در فایل‌های سایت وجود داشت.

بررسی فایل‌های اصلی وردپرس

اولین مرحله این بود که مطمئن شوم فایل‌های Core وردپرس تغییر نکرده‌اند. برای این کار از WP-CLI استفاده کردم:

wp core verify-checksums --include-root

نتیجه بررسی نشان داد فایل‌های رسمی WordPress Core با نسخه اصلی مطابقت دارند. این موضوع بسیار مهم بود، زیرا احتمال آلودگی مستقیم فایل‌هایی مانند wp-settings.php، wp-load.php و فایل‌های اصلی وردپرس کمتر شد.

البته سالم بودن Core به این معنا نیست که کل سایت سالم است. بدافزار می‌تواند داخل Theme، Plugin، Uploads، Cache یا حتی فایل‌های سفارشی قرار گرفته باشد.

کشف بیش از 200 فایل .htaccess مشکوک

در مرحله بعد تمام فایل‌های .htaccess سایت بررسی شدند. نتیجه بسیار غیرعادی بود.

صدها فایل .htaccess در مسیرهایی وجود داشتند که در حالت عادی اصلاً نیازی به چنین فایلی نداشتند.

برای مثال فایل‌های مشکوک در مسیرهایی مانند موارد زیر دیده شدند:

  • پوشه‌های مختلف Theme
  • زیرپوشه‌های WooCommerce
  • Uploads سال‌ها و ماه‌های مختلف
  • پوشه‌های Font و Asset
  • WP Rocket Cache
  • Wordfence Logs
  • Slider Templates

محتوای بسیاری از این فایل‌ها کاملاً یکسان بود:

<FilesMatch '.(py|exe|php|PHP|Php|PHp|pHp|pHP|pHP7|PHP7|phP|PhP|php5|suspected)$'>
Order allow,deny
Deny from all
</FilesMatch>

در نگاه اول ممکن است چنین کدی حتی شبیه یک قانون امنیتی به نظر برسد، اما نکته مهم این بود که این فایل‌ها بدون اجازه ایجاد شده بودند و تعداد بسیار زیادی از آن‌ها تقریباً در یک زمان ساخته شده بودند.

استفاده از SHA256 برای شناسایی فایل‌های آلوده

برای اینکه مطمئن شوم فقط فایل‌های آلوده حذف می‌شوند، به جای حذف تمام فایل‌های .htaccess، از Hash استفاده کردم.

SHA256 فایل مخرب مشخص شد و سپس تمام فایل‌هایی که دقیقاً همان Hash را داشتند پیدا شدند.

sha256sum .htaccess

بعد از اسکن کل سایت مشخص شد حدود 210 فایل دقیقاً همان Hash را دارند. این الگو تقریباً تأیید می‌کرد که یک Script یا Dropper به صورت Recursive فایل‌ها را در کل ساختار سایت ایجاد کرده است.

چرا Permission سایت مشکل امنیتی بزرگی ایجاد کرده بود؟

یکی از مهم‌ترین یافته‌های بررسی، مربوط به Linux Permission و Ownership فایل‌ها بود.

بخش بزرگی از WordPress با کاربر زیر اجرا و مالکیت آن نیز متعلق به همان کاربر بود:

www-data:www-data

حتی مسیرهایی مانند موارد زیر نیز توسط www-data قابل نوشتن بودند:

/wp-content/plugins
/wp-content/themes
/wp-content
/var/www/html

این موضوع بسیار خطرناک است.

اگر مهاجم بتواند از طریق یک Plugin آسیب‌پذیر یا Endpoint ناامن PHP Code Execution دریافت کند، همان Process می‌تواند فایل‌های Plugin، Theme و حتی بخش‌هایی از WordPress را تغییر دهد.

چرا Permission 444 همیشه کافی نیست؟

یکی از نکات جالب این Incident این بود که بعضی فایل‌ها Permission برابر 444 داشتند و در ظاهر Read Only بودند.

اما اگر Parent Directory برای کاربر PHP قابل نوشتن باشد، مهاجم می‌تواند فایل را حذف کرده و فایل جدیدی با همان نام ایجاد کند.

بنابراین فقط Read Only کردن یک فایل کافی نیست؛ مالکیت و Permission خود Directory نیز باید درست تنظیم شود.

ساختار امن‌تر برای Permission وردپرس

بعد از پاکسازی، ساختار Permission تغییر کرد. کد اصلی سایت فقط توسط Root قابل تغییر شد:

WordPress Core    root:root
Plugins           root:root
Themes            root:root
wp-config.php     root:www-data

اما مسیرهایی که WordPress واقعاً نیاز دارد در Runtime روی آن‌ها بنویسد، برای www-data باز ماندند:

wp-content/uploads
wp-content/cache
wp-content/wflogs

این روش باعث می‌شود اگر یک Plugin در آینده آسیب‌پذیر شود، PHP نتواند به راحتی کل Theme یا Pluginهای سایت را Rewrite کند.

جلوگیری از اجرای PHP داخل Uploads

یکی از مهم‌ترین اقدامات امنیتی، جلوگیری از اجرای PHP در پوشه Uploads بود.

فایل زیر در مسیر:

wp-content/uploads/.htaccess

قرار گرفت:

Options -Indexes

<FilesMatch "\.(?:php[0-9]?|phtml|phar)(?:\..*)?$">
    Require all denied
</FilesMatch>

با این تنظیم، حتی اگر مهاجم بتواند یک فایل PHP در Uploads آپلود کند، Apache اجازه اجرای آن را نخواهد داد.

محافظت از فایل‌های حساس وردپرس

در فایل اصلی .htaccess نیز دسترسی به فایل‌های حساس محدود شد.

برای مثال درخواست مستقیم به فایل‌هایی مانند موارد زیر مسدود شد:

.env
.git
wp-config.php
wp-config.php.bak
.htpasswd
.user.ini
php.ini
composer.json
debug.log

همچنین اجرای PHP در پوشه‌های Upload و Cache نیز در سطح Root مسدود شد.

بررسی Pluginها با WP-CLI

برای اینکه مطمئن شوم فایل‌های Pluginهای رسمی تغییر نکرده‌اند، Checksum آن‌ها نیز بررسی شد:

wp plugin verify-checksums --all

Pluginهایی که از WordPress.org نصب شده بودند با نسخه اصلی مقایسه شدند و فایل تغییرکرده مشکوکی در آن‌ها مشاهده نشد.

البته Pluginهای Premium یا Custom معمولاً Checksum عمومی WordPress.org ندارند و باید به صورت جداگانه با نسخه اصلی یا Backup معتبر مقایسه شوند.

بررسی WooCommerce و امنیت سفارش‌ها

از آنجایی که سایت از WooCommerce استفاده می‌کرد، حفظ اطلاعات سفارش‌ها اهمیت زیادی داشت.

قبل از هرگونه Update، Backup کامل دیتابیس گرفته شد:

wp db export backup.sql

سپس تعداد کاربران، محصولات، پست‌ها، صفحات و سفارش‌ها قبل از Update ثبت شد.

در این سایت HPOS یا High-Performance Order Storage فعال بود و سفارش‌ها در جدول‌های اختصاصی WooCommerce ذخیره می‌شدند.

WooCommerce از نسخه 9.4.4 به 11.0.1 ارتقا داده شد و Database Migrationهای WooCommerce نیز اجرا شدند.

بعد از Migration تعداد تمام سفارش‌ها، کاربران، محصولات و پست‌ها دوباره بررسی شد و هیچ داده‌ای از بین نرفته بود.

WP Rocket و Permissionهای امنیتی

یکی از اثرات Hardening این بود که WP Rocket دیگر نمی‌توانست همیشه روی پوشه wp-content/wp-rocket-config بنویسد.

در چنین شرایطی WP Rocket ممکن است در پنل وردپرس پیام عدم دسترسی Write نمایش دهد.

برای امنیت بیشتر می‌توان این Directory را در حالت عادی Read Only برای PHP نگه داشت و فقط هنگام تغییر تنظیمات WP Rocket به صورت موقت Write Permission ایجاد کرد.

بررسی درخواست‌های مشکوک در Access Log

Access Log سایت نیز بررسی شد. تعداد زیادی درخواست Random از Botها و Scannerهای اینترنتی مشاهده شد.

برای مثال درخواست‌هایی به URLهای تصادفی ارسال می‌شدند که بیشتر آن‌ها HTTP Status برابر 404 دریافت می‌کردند.

وجود چنین Requestهایی به تنهایی نشانه هک نیست. تقریباً هر سایت عمومی روی اینترنت دائماً توسط Scannerها، Crawlerها و Botها بررسی می‌شود.

مسئله زمانی جدی می‌شود که یک Request مشکوک بتواند پاسخ موفق دریافت کند یا باعث ایجاد، تغییر یا اجرای فایل روی سرور شود.

مهم‌ترین درس این حمله چه بود؟

مهم‌ترین نکته‌ای که از این Incident می‌توان یاد گرفت این است که امنیت WordPress فقط به آپدیت Plugin یا نصب Wordfence محدود نمی‌شود.

حتی اگر WordPress Core کاملاً سالم باشد، Permission اشتباه می‌تواند باعث شود یک آسیب‌پذیری کوچک تبدیل به دسترسی گسترده روی کل سایت شود.

در این مورد، مهاجم توانسته بود تعداد زیادی فایل .htaccess در مسیرهای مختلف ایجاد کند، زیرا PHP روی بخش بزرگی از Webroot دسترسی Write داشت.

چک‌لیست امنیتی بعد از هک وردپرس

  • از دیتابیس و فایل‌های سایت Backup بگیرید.
  • Checksum فایل‌های WordPress Core را بررسی کنید.
  • Checksum Pluginهای رسمی را بررسی کنید.
  • تمام فایل‌های .htaccess را Audit کنید.
  • PHPهای موجود در Uploads را بررسی کنید.
  • Permission و Ownership فایل‌ها را اصلاح کنید.
  • اجرای PHP در Uploads را مسدود کنید.
  • اکانت‌های Administrator را بررسی کنید.
  • Passwordهای WordPress، Hosting و Database را تغییر دهید.
  • WordPress Saltها را Rotate کنید.
  • Pluginها و Themeهای قدیمی را بروزرسانی کنید.
  • Access Log و WAF Log را بررسی کنید.
  • بعد از پاکسازی، سایت را برای Reinfection مانیتور کنید.

چگونه متوجه شویم سایت دوباره آلوده شده است؟

بعد از حذف Malware باید سایت برای مدتی Monitor شود.

برای مثال اگر Hash یک فایل مخرب مشخص شده باشد، می‌توان به صورت دوره‌ای بررسی کرد که فایل مشابه دوباره ایجاد نشده باشد.

همچنین تغییرات غیرعادی در موارد زیر اهمیت زیادی دارند:

  • ساخته شدن PHP جدید در Uploads
  • ایجاد فایل .htaccess در مسیرهای غیرعادی
  • تغییر Owner فایل‌ها به www-data
  • ساخته شدن Administrator جدید
  • نمایش صفحات ناشناس در Google Search Console
  • افزایش غیرعادی مصرف CPU یا RAM

آیا Wordfence به تنهایی برای امنیت وردپرس کافی است؟

خیر. Wordfence و سایر WAFها ابزارهای بسیار مفیدی هستند، اما نباید تنها لایه امنیتی سایت باشند.

مدل امن‌تر، استفاده از چند لایه دفاعی است:

  • WordPress و Pluginهای به‌روز
  • WAF
  • Permission صحیح Linux
  • محدود کردن PHP Write Access
  • Backup منظم
  • Log Monitoring
  • جلوگیری از اجرای PHP در Uploads

سوالات متداول درباره هک WordPress

آیا وجود فایل .htaccess زیاد در وردپرس طبیعی است؟

خیر. بعضی Pluginها ممکن است در Directoryهای مشخص فایل .htaccess ایجاد کنند، اما وجود صدها فایل مشابه در تمام زیرپوشه‌های Theme، Uploads و Assets بسیار مشکوک است.

آیا Permission 644 برای فایل PHP امن است؟

Permission 644 به تنهایی کافی نیست. Owner فایل و Permission پوشه والد نیز اهمیت دارد. اگر PHP مالک Directory باشد ممکن است بتواند فایل را حذف و جایگزین کند.

آیا پاک کردن فایل‌های مخرب برای پاکسازی وردپرس کافی است؟

خیر. اگر نقطه ورود مهاجم یا Permission اشتباه اصلاح نشود، Malware ممکن است دوباره ایجاد شود.

Japanese SEO Spam چیست؟

Japanese SEO Spam نوعی حمله SEO است که در آن مهاجم صفحات یا Structured Data جعلی با کلمات ژاپنی یا فروشگاهی ایجاد می‌کند تا از اعتبار دامنه قربانی برای گرفتن رتبه در گوگل استفاده کند.

بعد از هک وردپرس باید Passwordها تغییر کنند؟

بله. Password حساب‌های Administrator، Hosting، Database و سایر Credentialهای حساس باید بعد از پاکسازی تغییر داده شوند.

جمع‌بندی

این حمله نشان داد که حتی زمانی که WordPress Core سالم است، یک Permission اشتباه می‌تواند سطح حمله بسیار بزرگی ایجاد کند.

در این Incident بیش از 200 فایل .htaccess غیرمجاز در مسیرهای مختلف سایت ایجاد شده بود. پس از شناسایی Hash مشترک، فایل‌های آلوده حذف شدند، Permissionها اصلاح شدند، دسترسی Write PHP محدود شد و مسیرهای حساس مانند Uploads و WAF Logs محافظت شدند.

همچنین WooCommerce و Database آن با Backup کامل و کنترل تعداد سفارش‌ها بروزرسانی شدند تا هیچ اطلاعاتی از کاربران، محصولات و سفارش‌ها از بین نرود.

اگر سایت وردپرسی مدیریت می‌کنید، پیشنهاد می‌کنم فقط به نصب افزونه امنیتی اکتفا نکنید. Permission صحیح، Backup، Monitoring و محدود کردن دسترسی PHP به فایل‌ها از مهم‌ترین بخش‌های امنیت WordPress هستند.