PHP2Shell؛ تحلیل جامع آسیب‌پذیری بحرانی PHP، روش‌های نفوذ، شناسایی حملات و راهکارهای پیشرفته مقابله و پیشگیری

چکیده

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

اصطلاح PHP2Shell به‌تنهایی نام یک شناسه استاندارد و یکتای آسیب‌پذیری از نوع CVE نیست؛ معنای دقیق آن به پروژه، گزارش امنیتی یا مؤلفه‌ای بستگی دارد که این عنوان در آن استفاده شده است. در مفهوم فنی، این اصطلاح می‌تواند به زنجیره‌ای از ضعف‌ها اشاره کند که از یک نقطه ورودی در برنامه PHP آغاز می‌شود و در نهایت به اجرای فرمان سیستم‌عامل یا ایجاد یک پوسته فرمان (Shell) منجر می‌شود. برای انتساب دقیق این عنوان به یک آسیب‌پذیری مشخص، لازم است نام پروژه، نسخه آسیب‌پذیر، شناسه CVE یا منبع اولیه گزارش بررسی شود.

از دیدگاه مهندسی امنیت، تحلیل PHP2Shell باید سه مسئله مستقل را پوشش دهد:

• ریشه آسیب‌پذیری: چگونه داده غیرقابل‌اعتماد به یک عملیات اجرایی خطرناک تبدیل می‌شود؟

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

• مهار و پیشگیری: چگونه می‌توان احتمال وقوع، سطح دسترسی و پیامدهای یک رخداد را به‌صورت هم‌زمان کاهش داد؟

این مقاله با رویکرد دفاعی و مبتنی بر اصول امنیت نرم‌افزار، مدل تهدید، مسیرهای رایج سوءاستفاده، روش‌های شناسایی و کنترل‌های پیشگیرانه را بررسی می‌کند. از آنجا که عنوان PHP2Shell بدون یک مرجع فنی مشخص مبهم است، تحلیل زیر ناظر بر الگوی عمومی تبدیل ورودی PHP به اجرای فرمان است، نه ادعای تأییدشده درباره یک CVE خاص.

۱.وضعیت تهدید در اکتبر ۲۰۲۶: آنچه درباره PHP2Shell تأیید شده است

برخلاف برداشت اولیه‌ای که ممکن است از نام PHP2Shell ایجاد شود، این عنوان در گزارش‌های امنیتی اکتبر ۲۰۲۶ به مجموعه‌ای از دو آسیب‌پذیری واقعی در هسته PHP اشاره دارد؛ بنابراین، برای بررسی وضعیت جاری، نباید آن را صرفاً با آسیب‌پذیری‌های تزریق فرمان در کد برنامه اشتباه گرفت.

 

این نسخه‌ها حداقل نسخه‌های اصلاح‌شده هستند؛ در محیط عملیاتی، باید آخرین به‌روزرسانی امنیتی سازگار با شاخه مورد استفاده نصب شود.

هشدار مهم: نسخه‌های قدیمی‌تر از 8.2 ممکن است خارج از چرخه پشتیبانی رسمی باشند. در چنین شرایطی، ارتقا به شاخه پشتیبانی‌شده یا استفاده از بسته‌ای که اصلاح امنیتی آن به‌طور مستند توسط توزیع‌کننده پشتیبانی می‌شود، ضروری است. صرف تغییر رشته نسخه یا استفاده از یک WAF جایگزین وصله معتبر نیست.

۲. معماری فنی آسیب‌پذیری و مدل تهدید

برای درک علمی PHP2Shell، ابتدا باید میان سه مفهوم تمایز قائل شد:

• تزریق فرمان (Command Injection): ورودی مهاجم به‌گونه‌ای وارد فرمان سیستم‌عامل می‌شود که مرز میان داده و دستور از بین می‌رود.

• اجرای کد از راه دور (RCE): مهاجم قادر می‌شود کد دلخواه را در زمینه اجرایی هدف اجرا کند؛ این مفهوم الزاماً به ایجاد Shell نیاز ندارد.

• خرابی حافظه (Memory Corruption): خطایی در مدیریت حافظه می‌تواند کنترل جریان اجرا یا داده‌های داخلی برنامه را مختل کند و در شرایط خاص به RCE منتهی شود.

PHP2Shell مورد بحث در سال ۲۰۲۶ در دسته سوم قرار می‌گیرد؛ در حالی که آسیب‌پذیری‌های متداول PHP که از ساخت رشته فرمان ناامن ناشی می‌شوند، معمولاً در دسته اول قرار دارند. هر دو مسیر ممکن است به اجرای کد منجر شوند، اما سازوکار و روش اصلاح آن‌ها متفاوت است.

۲.۱. چرا مرز اعتماد در پردازش درخواست اهمیت دارد؟

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

اگر نقصی در این لایه وجود داشته باشد، اعتبارسنجی ورودی در کنترلرهای برنامه الزاماً از آن جلوگیری نمی‌کند؛ زیرا کنترلر ممکن است پس از عبور درخواست از مسیر آسیب‌پذیر اجرا شود.

این ویژگی یکی از تفاوت‌های اساسی آسیب‌پذیری‌های Runtime با خطاهای رایج اعتبارسنجی در کد برنامه است.

۲.۲. نقش Out-of-Memory در فساد حافظه

شرایط کمبود حافظه معمولاً باید به شکست کنترل‌شده عملیات، بازگرداندن خطا و پاک‌سازی صحیح منابع منتهی شوند. اگر یک مسیر خطا وضعیت داخلی را به‌صورت ناقص باقی بگذارد، عملیات پاک‌سازی بعدی ممکن است با اشاره‌گر یا ساختاری کار کند که به‌درستی مقداردهی نشده است.

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

۲.۳. Use-After-Free و چرخه عمر حافظه

در آسیب‌پذیری Use-After-Free، حافظه‌ای که آزاد شده است همچنان از طریق یک مرجع قدیمی مورد استفاده قرار می‌گیرد. اگر آن ناحیه حافظه دوباره به داده‌ای دیگر اختصاص پیدا کند، عملیات بعدی ممکن است داده یا ساختار نامرتبطی را بخواند یا تغییر دهد.

این نقص به‌تنهایی معادل اجرای کد نیست؛ تبدیل آن به RCE به امکان کنترل یا تأثیرگذاری بر وضعیت حافظه و سایر شرایط اجرایی وابسته است. با این حال، شدت اعلام‌شده PHP2Shell نشان می‌دهد که این مسیرها را باید تهدیدی جدی در سطح Runtime تلقی کرد.

۳. روش‌های نفوذ و مسیرهای بهره‌برداری

در تحلیل نفوذ، بهتر است مسیر حمله را به مراحل قابل‌مشاهده و قابل‌اندازه‌گیری تقسیم کنیم. این روش به تیم امنیت کمک می‌کند تا بدون نیاز به اجرای اکسپلویت روی سامانه عملیاتی، نقاط ضعف و نشانه‌های احتمالی بهره‌برداری را شناسایی کند.

۳.۱. بهره‌برداری از پردازش درخواست‌های HTTP

در این سناریو، مهاجم تلاش می‌کند با ارسال درخواست‌هایی که ساختار یا اندازه آن‌ها غیرعادی است، مسیرهای حساس پردازش درخواست در PHP را درگیر کند.

مؤلفه‌های قابل بررسی از دید دفاعی عبارت‌اند از:

• پردازش بدنه درخواست‌های multipart/form-data.

• تعداد فیلدها، بخش‌ها و هدرهای ورودی.

• محدودیت اندازه درخواست و تعداد فیلدهای ورودی.

• رفتار Runtime هنگام کمبود حافظه یا وقوع خطای مرگبار.

• نحوه مدیریت و بازیابی Workerها پس از شکست درخواست.

نکته امنیتی: در آسیب‌پذیری‌های PHP2Shell، الزاماً نیازی به وجود یک صفحه مشخص با کد PHP ناامن نیست. در برخی مسیرهای بهره‌برداری، درخواست ممکن است پیش از رسیدن به کد برنامه باعث ورود Runtime به مسیر آسیب‌پذیر شود.

۳.۲. سوءاستفاده از وضعیت باقی‌مانده میان درخواست‌ها

در برخی معماری‌ها، چند درخواست متوالی توسط یک Worker پردازش می‌شوند. اگر وضعیت داخلی یک درخواست پس از پایان عمر آن به‌درستی پاک‌سازی نشود، درخواست بعدی ممکن است با وضعیت نامعتبر یا قدیمی مواجه شود.

این موضوع به‌ویژه برای بررسی رفتار چرخه عمر حافظه و داده‌های داخلی اهمیت دارد. از منظر دفاعی، باید موارد زیر ارزیابی شوند:

• آیا خطاهای یک درخواست باعث توقف یا خرابی Worker می‌شوند؟

• آیا درخواست‌های متوالی با خطاهای حافظه یا پاک‌سازی غیرعادی همراه هستند؟

• آیا قابلیت‌هایی نظیر Session Upload Progress فعال‌اند؟

• آیا پس از اصلاح تنظیمات، تمام Workerهای قدیمی راه‌اندازی مجدد شده‌اند؟

مسیر مربوط به CVE-2026-109619 با وضعیت داخلی باقی‌مانده پس از آزادسازی حافظه مرتبط است.

۳.۳. تبدیل اجرای کد به دسترسی عملیاتی

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

مهاجم ممکن است در پی دستیابی به اهدافی مانند موارد زیر باشد:

1. خواندن فایل‌های پیکربندی و استخراج اعتبارنامه‌ها.

2. دسترسی به پایگاه داده یا سرویس‌های داخلی.

3. تغییر فایل‌های برنامه یا ایجاد سازوکار ماندگاری.

4. ایجاد ارتباط خروجی با زیرساخت تحت کنترل مهاجم.

5. حرکت جانبی به سایر سرویس‌های قابل‌دسترسی.

این موارد پیامدهای بالقوه RCE هستند و به معنی تأیید وقوع تمام آن‌ها در هر بهره‌برداری از PHP2Shell نیستند.

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

۳.۴. یک مسیر مجزای تهدید: تزریق فرمان در کد PHP

اگرچه PHP2Shell سال ۲۰۲۶ به آسیب‌پذیری‌های هسته PHP اشاره دارد، بررسی امنیتی برنامه‌های PHP باید مسیر مستقل تزریق فرمان را نیز پوشش دهد.

کد زیر نمونه‌ای ناامن از ساخت فرمان است:

<?php
$filename = $_GET['file'] ?? '';
system("some-tool " . $filename);

مشکل اصلی این است که داده ورودی مستقیماً در رشته فرمان قرار می‌گیرد. در نتیجه، رفتار ابزار و مفسر فرمان ممکن است تحت تأثیر ورودی کاربر قرار گیرد.

راهکار مطلوب، استفاده از توابع داخلی PHP یا کتابخانه‌های امنی است که اصلاً به اجرای فرمان سیستم‌عامل نیاز ندارند. اگر اجرای ابزار خارجی اجتناب‌ناپذیر باشد، باید نام اجرایی و آرگومان‌های مجاز محدود و مشخص باشند و ورودی کاربر به‌صورت داده مستقل مدیریت شود. توابع فراردهی به‌تنهایی همه خطرهای مربوط به آرگومان‌های خاص برنامه را حذف نمی‌کنند.

این تمایز در ارزیابی امنیتی حیاتی است: وصله PHP2Shell خطاهای Runtime را اصلاح می‌کند، اما جایگزین اصلاح تزریق فرمان در کد اختصاصی برنامه نمی‌شود.

۴. راهبرد مقابله با PHP2Shell

۴.۱. اقدام اول: شناسایی و نصب اصلاحیه رسمی

اولویت نخست، شناسایی تمام محیط‌هایی است که PHP را اجرا می‌کنند؛ نه فقط وب‌سایت‌هایی که مستقیماً با PHP نوشته شده‌اند.

این بررسی باید موارد زیر را در بر بگیرد:

• سرورهای Apache با mod_php.

• سرویس‌های PHP-FPM و PHP-CGI.

• محیط‌های FrankenPHP و LiteSpeed.

• کانتینرها، Imageهای پایه، محیط‌های توسعه و Runnerهای CI/CD.

• برنامه‌های شخص ثالث و سرویس‌هایی که PHP را به‌عنوان مؤلفه جانبی اجرا می‌کنند.

سپس نسخه واقعی Runtime در حال اجرا را با بسته اصلاح‌شده تأییدشده توسط توزیع‌کننده مقایسه کنید. ممکن است نسخه‌های توزیع‌شده لینوکس وصله امنیتی را به‌صورت Backport دریافت کرده باشند؛ بنابراین، شماره نسخه به‌تنهایی همیشه معیار کافی نیست.

نمونه بررسی اولیه:

php -v
php --ini

این دستورات اطلاعات PHP مربوط به محیط خط فرمان را نشان می‌دهند. نسخه PHP خط فرمان الزاماً همان نسخه سرویس وب نیست. نسخه‌های PHP-FPM، ماژول Apache، کانتینرهای در حال اجرا و بسته‌های نصب‌شده باید جداگانه بررسی شوند.

۴.۲. اقدام دوم: کاهش موقت سطح حمله

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

محدودیت	هدف	کنترل موقت
همه مسیرهای بهره‌برداری را نمی‌بندد	مسدودکردن مسیر تأییدشده مرتبط با وضعیت داخلی	غیرفعال‌سازی Session Upload Progress
شکست واقعی تخصیص حافظه همچنان ممکن است	کاهش مواجهه با برخی مسیرهای مرتبط با کمبود حافظه	محدودیت اندازه بدنه POST
نیازمند اعمال در لایه مناسب زیرساخت است	محدودکردن ورودی‌های غیرعادی	محدودکردن تعداد فیلدها و بخش‌های Multipart
مانع قطعی اجرای کد نیست	مهار اثر خرابی و حفظ دسترس‌پذیری میزبان	محدودیت منابع در سطح Container یا cgroup
جایگزین اصلاح Runtime نیست	شناسایی و مسدودسازی برخی درخواست‌های مخرب	WAF و پایش ترافیک

راهنمای رسمی PHP برای مسیر CVE-2026-109618 به محدودیت post_max_size اشاره می‌کند؛ مقادیر پیشنهادی موقت آن برای برنامه‌های بدون نیاز به آپلود ۸ مگابایت و برای برنامه‌های نیازمند آپلود ۳۲ مگابایت است. این اعداد باید متناسب با نیاز عملیاتی سرویس تنظیم شوند و محدودیت‌ها باید در پراکسی یا وب‌سرور نیز اعمال شوند، از جمله برای درخواست‌هایی که هدر Content-Length قابل‌اتکایی ندارند.

۴.۳. اقدام سوم: تنظیم Session Upload Progress

در ۲۳ اکتبر ۲۰۲۶، PHP درباره یک مسیر مرتبط دیگر با شناسه CVE-2026-115560 نیز هشدار داده است. این مسئله می‌تواند در ترکیب غیرمعمولی از تنظیمات مربوط به session.serialize_handler و Session Upload Progress رخ دهد و حتی در نسخه‌های اصلاح‌شده PHP2Shell مطرح شده است.

راهنمای فعلی PHP پیشنهاد می‌کند تا انتشار اصلاحیه مربوط، قابلیت مذکور غیرفعال شود.

در پیکربندی سرور، در صورت امکان، تنظیمات زیر را اعمال کنید:

session.upload_progress.enabled = 0

این تنظیم باید در لایه‌ای اعمال شود که پیش از پردازش درخواست مؤثر باشد. برای مثال، تنظیمات مدیریتی PHP-FPM یا پیکربندی مناسب سرور می‌توانند گزینه‌های قابل‌اتکاتری از تنظیمات دیرهنگام در کد برنامه باشند. پس از اعمال تغییر، تمام Workerهای مرتبط را راه‌اندازی مجدد کنید.

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

۴.۴. اقدام چهارم: محدودسازی دسترسی فرایند PHP

حتی پس از نصب اصلاحیه، محدودکردن اختیارات فرایند وب ضروری است.

اصول پیشنهادی:

• اجرای PHP با کاربر اختصاصی و غیرممتاز.

• جلوگیری از نوشتن در کد برنامه و فایل‌های اجرایی توسط فرایند وب، مگر در مسیرهای ضروری.

• نگهداری فایل‌های آپلود خارج از Document Root و جلوگیری از اجرای آن‌ها.

• جداسازی فرایندهای وب از پایگاه داده و سرویس‌های حساس.

• محدودسازی دسترسی شبکه خروجی و ارتباط با سرویس‌های مدیریتی.

• استفاده از Container، پروفایل‌های امنیتی سیستم‌عامل و محدودیت‌های مناسب دسترسی به فایل‌ها.

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

این کنترل‌ها از اصل Least Privilege پیروی می‌کنند و باعث می‌شوند در صورت رخداد یک نقص ناشناخته نیز دامنه آسیب کاهش یابد.

۵. شناسایی تلاش‌های بهره‌برداری و تحلیل شواهد

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

۵.۱. شاخص‌های قابل بررسی در لاگ‌ها

لاگ وب‌سرور و پراکسی:

بررسی درخواست‌های POST غیرعادی، الگوهای غیرمعمول Multipart، حجم‌های نامتعارف درخواست و افزایش خطاهای HTTP. به یاد داشته باشید که نبود یک URL خاص در لاگ، این آسیب‌پذیری را رد نمی‌کند.

لاگ PHP و PHP-FPM:

بررسی خطاهای کمبود حافظه، خروج غیرمنتظره Workerها، Crashهای متوالی و توقف‌های غیرعادی فرایندهای PHP.

تله‌متری EDR و سیستم‌عامل:

بررسی ایجاد فرایندهای فرزند غیرمعمول توسط PHP یا وب‌سرور، اجرای Shell و ابزارهای دانلود، ارتباطات خروجی ناشناخته و تغییرات غیرمنتظره فایل‌ها.

بررسی ماندگاری و دسترسی به اسرار:

جست‌وجوی فایل‌های PHP ناشناس یا تغییرکرده، وظایف زمان‌بندی‌شده جدید، حساب‌های غیرمجاز، تغییرات افزونه‌ها و دسترسی مشکوک به فایل‌های پیکربندی.

---

این نشانه‌ها به‌تنهایی اثبات‌کننده بهره‌برداری نیستند؛ باید در کنار هم و با توجه به خط زمانی رخداد تحلیل شوند. همچنین، اجرای موفق کد لزوماً به ایجاد Shell یا فرایند فرزند منجر نمی‌شود؛ بنابراین، نبود هشدار EDR به معنای سالم‌بودن قطعی سرور نیست.

۵.۲. بررسی‌های دفاعی قابل خودکارسازی

تیم امنیت می‌تواند با ابزارهای مدیریت دارایی و SIEM، موارد زیر را به‌صورت دوره‌ای پایش کند:

• فهرست تمام Runtimeهای PHP و نسخه‌های آن‌ها.

• ارتباط میان نسخه نصب‌شده و وضعیت اصلاحیه توزیع‌کننده.

• تعداد Crashهای PHP-FPM و Apache در بازه‌های زمانی کوتاه.

• تغییرات غیرمنتظره در فایل‌های برنامه.

• ایجاد فرایندهای فرزند غیرمنتظره برای PHP.

• ارتباط خروجی از میزبان‌های وب به مقصدهای جدید یا غیرمجاز.

• رخدادهای دسترسی به فایل‌های حاوی اسرار.

در محیط‌های بزرگ، بهتر است برای هر دارایی شناسه، مالک، نسخه Runtime، روش نصب، وضعیت وصله و زمان آخرین بررسی ثبت شود. این اطلاعات، اولویت‌بندی پاسخ به آسیب‌پذیری را بسیار دقیق‌تر می‌کند.

۶. پیشگیری از تزریق فرمان در برنامه‌های PHP

این بخش به آسیب‌پذیری‌های عمومی اجرای فرمان می‌پردازد؛ نقص‌هایی که با PHP2Shell هسته PHP تفاوت دارند، اما می‌توانند پیامد مشابهی ایجاد کنند.

۶.۱. حذف وابستگی غیرضروری به Shell

اگر هدف، ایجاد پوشه یا کار با فایل است، از APIهای داخلی PHP استفاده کنید:

<?php

$directory = __DIR__ . '/storage/reports';

if (!is_dir($directory)) {
    if (!mkdir($directory, 0750, true) && !is_dir($directory)) {
        throw new RuntimeException(
            'Directory creation failed.'
        );
    }
}

در این نمونه، برای ایجاد پوشه از mkdir() استفاده شده است و هیچ فرمان سیستم‌عاملی ساخته نمی‌شود. مسیر نیز ثابت و تحت کنترل برنامه است.

۶.۲. اعتبارسنجی ورودی بر اساس نوع داده

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

برای مثال، اگر یک شناسه فقط باید شامل ارقام باشد:

<?php

$id = $_GET['id'] ?? '';

if (!is_string($id) ||
    !preg_match('/\A[0-9]{1,10}\z/', $id)) {
    http_response_code(400);
    exit('Invalid identifier');
}

این کنترل ورودی را به قالب مورد انتظار محدود می‌کند. بااین‌حال، اعتبارسنجی به‌تنهایی جایگزین کنترل دسترسی، استفاده از API امن یا وصله Runtime نیست.

۶.۳. استفاده صحیح از escapeshellarg

اگر اجرای ابزار خارجی اجتناب‌ناپذیر است، escapeshellarg() می‌تواند برای حفاظت از مرز یک آرگومان در Shell مفید باشد. بااین‌حال، این تابع نباید به‌عنوان راه‌حل کامل برای تمام انواع تزریق فرمان یا آرگومان در نظر گرفته شود.

برای نمونه، ابزار مقصد ممکن است آرگومان‌هایی را به‌عنوان گزینه‌های اجرایی تفسیر کند؛ حتی اگر آرگومان از نظر نحوی به‌درستی Escape شده باشد. به همین دلیل، نام برنامه و گزینه‌های آن باید ثابت باشند و ورودی‌ها فقط از مجموعه مقادیر مجاز انتخاب شوند.

۷. برنامه واکنش به رخداد (Incident Response)

اگر یک سرور PHP پیش از نصب اصلاحیه در معرض اینترنت بوده است، به‌ویژه اگر نسخه آسیب‌پذیر داشته یا نشانه‌های غیرعادی ثبت کرده باشد، باید احتمال رخداد امنیتی بررسی شود.

1. مهار: در صورت مشاهده نشانه‌های معتبر بهره‌برداری، میزبان را طبق برنامه واکنش به رخداد از شبکه جدا کنید یا دسترسی ورودی آن را محدود سازید.

2. حفظ شواهد: لاگ‌های وب‌سرور، PHP، سیستم‌عامل، EDR و اطلاعات فرایندها را پیش از پاک‌سازی یا بازسازی جمع‌آوری کنید.

3. اصلاح: نسخه PHP را به نسخه اصلاح‌شده ارتقا دهید و تمام Workerها، کانتینرها و نمونه‌های فعال را بررسی کنید.

4. بررسی نفوذ: فایل‌های تغییرکرده، حساب‌های جدید، وظایف زمان‌بندی‌شده، ارتباطات خروجی و دسترسی به پایگاه داده و اسرار را ارزیابی کنید.

5. ابطال اعتبارنامه‌ها: اگر احتمال دسترسی غیرمجاز به اسرار وجود دارد، کلیدها، توکن‌ها، رمزهای عبور و اعتبارنامه‌های مرتبط را از یک محیط سالم تعویض کنید.

6. بازیابی و اعتبارسنجی: در صورت تأیید نفوذ، از نسخه سالم و قابل‌اعتماد بازیابی کنید و پس از آزمون امنیتی، سرویس را مجدداً در دسترس قرار دهید.

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

۸. چک‌لیست اجرایی برای مدیران امنیت و تیم‌های DevSecOps

شناسایی و اصلاح
[ ] شناسایی تمام Runtimeهای PHP در سرورها، کانتینرها و سرویس‌های جانبی
[ ] تأیید نسخه اصلاح‌شده از طریق بسته رسمی یا توزیع‌کننده
[ ] بررسی و به‌روزرسانی شاخه‌های قدیمی و خارج از پشتیبانی
[ ] راه‌اندازی مجدد Workerها و تأیید نسخه واقعی در حال اجرا

کاهش سطح حمله
[ ] بررسی تنظیم session.upload_progress.enabled و توصیه تکمیلی PHP
[ ] اعمال محدودیت مناسب اندازه درخواست و تعداد بخش‌های Multipart
[ ] محدودسازی مجوز فایل‌ها، دسترسی شبکه و اختیارات فرایند PHP
[ ] فعال‌سازی کنترل‌های WAF و بررسی پوشش مسیرهای ورودی

کشف و پاسخ
[ ] پایش خطاهای حافظه و Crashهای غیرعادی
[ ] بررسی فرایندهای فرزند و ارتباطات خروجی مشکوک
[ ] بازبینی فایل‌های تغییریافته و احتمال ماندگاری
[ ] حفظ شواهد، ارزیابی نفوذ و تعویض اسرار در صورت لزوم

۹. جمع‌بندی علمی

1. اصلاح فوری PHP: استفاده از نسخه اصلاح‌شده و تأیید وضعیت تمام نمونه‌های در حال اجرا.

2. بررسی رخدادهای پیشین: ارزیابی نشانه‌های بهره‌برداری در سرورهایی که پیش از اصلاح در معرض اینترنت بوده‌اند.

3. کاهش سطح حمله: اعمال تنظیمات موقت رسمی، محدودیت منابع و کنترل دسترسی شبکه.

4. دفاع چندلایه: جداسازی فرایندها، حداقل‌سازی مجوزها، پایش رفتاری و محافظت در لایه ورودی.

5. مدیریت مستمر آسیب‌پذیری: ثبت دارایی‌ها، پیگیری اطلاعیه‌های امنیتی و آزمون مداوم کنترل‌های دفاعی.

هیچ WAF، قاعده اعتبارسنجی ورودی یا تنظیم منفردی جایگزین وصله معتبر نمی‌شود. در مورد PHP2Shell، این موضوع اهمیت ویژه‌ای دارد، زیرا نقص در مسیر پردازش درخواست می‌تواند پیش از اجرای منطق برنامه فعال شود.