وردپرس ۷.۰.۴ روز ۲۱ مرداد ۱۴۰۵ منتشر شد و فقط یک چیز را عوض کرد: یک فایل. حفره ای که بست، اجرای کد از راه دور بود، اما نه روی هر سایتی. فقط سرورهایی درگیر بودند که هم افزونه Imagick را روی PHP داشتند و هم Ghostscript را روی سیستم عامل.
ما سرور خودمان را چک کردیم و دقیقا همان ترکیب را داشت. نتیجه چک را پایین می آوریم، چون جالب ترین بخش ماجرا آن جاست، نه در خود خبر.
در ۷.۰.۴ دقیقا چه چیزی وصله شد
تیم امنیت وردپرس یک مورد را فهرست کرده است: اجرای کد از راه دور توسط کاربر احراز هویت شده با سطح دسترسی نویسنده یا بالاتر، از طریق آپلود فایل مخرب، روی سایت هایی که از Imagick و Ghostscript استفاده می کنند. گزارش دهنده تیم pwn.ai بوده است.
در صفحه نسخه، فهرست فایل های تغییر کرده یک خط بیشتر نیست:
/wp-includes/class-wp-image-editor-imagick.php
هیچ پکیجی هم به روز نشده. یعنی این یک انتشار امنیتی تک منظوره است، نه یک نسخه نگهداری با چهل رفع اشکال. همین باعث می شود ریسک به روزرسانی فوری تقریبا صفر باشد؛ چیزی که معمولا نگرانی اصلی مدیر یک سایت فروشگاهی است.
چرا این وصله تا وردپرس ۴.۷ عقب برده شد
وردپرس این رفع را روی ۲۳ شاخه قدیمی هم منتشر کرد، تا نسخه ۴.۷.۳۵. یعنی سایتی که هنوز روی وردپرس ۵.۲ مانده هم نسخه وصله شده دارد. ۴.۶ و پایین تر دیگر به روزرسانی امنیتی نمی گیرند.
این تصمیم به خودی خود چیزی درباره شدت مسئله می گوید. وردپرس هر باگی را تا هشت سال عقب بک پورت نمی کند.
سرور شما درگیر بود یا نه: سه دستور
ترتیبش مهم است. اول نسخه، بعد Imagick، بعد Ghostscript. اگر یکی از دو مورد آخر نبود، شما اصلا در دامنه این آسیب پذیری نبودید.
wp core version
php -r 'echo extension_loaded("imagick") ? Imagick::getVersion()["versionString"] : "no imagick";'
gs --version
خروجی سرور ما در ۲۴ مرداد ۱۴۰۵ این بود:
7.0.4
ImageMagick 6.9.12-98 Q16 x86_64 18038
10.02.1
هر سه شرط برقرار. تنها چیزی که ما را زودتر از انتشار خبر پوشش داد، به روزرسانی خودکار هسته بود که پیش فرض وردپرس است و ما خاموشش نکرده بودیم.
تله ای که وقت ما را گرفت: policy.xml
هر راهنمای سخت سازی ImageMagick به شما می گوید فایل policy.xml را ببندید تا کدک های PostScript و PDF غیرفعال شوند. توصیه درستی است. مشکل جای دیگری است.
روی نصب استاندارد ImageMagick 6 در دبیان و اوبونتو، آن خط ها داخل بلوک توضیحات فایل هستند، نه داخل تنظیمات. ما با grep دنبال خط گشتیم، پیدایش کردیم و یک لحظه خیالمان راحت شد. بعد اثرش را تست کردیم و معلوم شد فعال نیست.
تفاوت را با این دو دستور می بینید. اولی سیاست های واقعا اعمال شده را می دهد، دومی ثابت می کند Ghostscript هنوز صدا زده می شود:
identify -list policy
convert sample.pdf out.png
اگر در خروجی اول هیچ ردیفی با عنوان Coder ندیدید، محدودیت کدک ندارید، هر چه در فایل نوشته باشد. و اگر دستور دوم خطای Ghostscript داد و نه خطای مجوز، یعنی مسیر باز است. روی سرور ما همین اتفاق افتاد.
پس بشمارید چند نفر دسترسی نویسنده به پیشخوان شما دارند. وردپرس به صورت پیش فرض به نویسنده اجازه آپلود این فرمت ها را می دهد: pdf، psd، xps و oxps. همان هایی که سر از Ghostscript در می آورند.
افزونه امنیتی این را نمی گرفت
این جمله برای کسی که افزونه امنیتی می فروشد گران تمام می شود، ولی درست است.
وردفنس و همتاهایش روی لایه درخواست کار می کنند: ورودی مشکوک، آی پی بد، تلاش ورود ناموفق. این جا آپلود کاملا مجاز بود، توسط کاربری که واقعا حق آپلود داشت، و پردازش در یک فایل هسته انجام می شد. هیچ قاعده ای در فایروال برنامه چنین چیزی را ناهنجار نمی بیند.
چیزی که واقعا اثر داشت سه چیز بود و هر سه رایگان اند: به روزرسانی خودکار هسته روشن، تعداد کاربران سطح نویسنده حداقلی، و یک ImageMagick که واقعا محدود شده باشد.
و حالا اندازه واقعی خطر
اگر تنها کاربر سایت شما خودتان هستید، ریسک عملی شما در این مورد نزدیک صفر بود. آسیب پذیری احراز هویت شده با سطح نویسنده یعنی مهاجم اول باید یک حساب داشته باشد.
خطر واقعی جای دیگری است: سایت هایی که ثبت نام باز دارند، سایت های چند نویسنده، وبلاگ های شرکتی که ده نفر دسترسی انتشار دارند و مدت هاست کسی فهرست کاربران را مرور نکرده. اگر شما در این دسته اید، وصله فقط نیمی از کار است؛ نیم دیگر مرور همان فهرست است.
ما همین منطق را در نشانه هایی که قبل از هک شدن سایت دیده می شوند باز کرده ایم، و اگر می خواهید یک نفر بیرون از تیم خودتان سطح دسترسی ها و پیکربندی سرور را نگاه کند، بازبینی امنیتی سرور و سطح دسترسی ها دقیقا از همین فهرست شروع می شود.
یک نکته پایانی که به خبر ربط ندارد ولی به شما دارد: سایتی که روی هاست مشترک با پیکربندی دست نخورده نشسته، این تصمیم ها را خودش نمی گیرد. تفاوتش را در رابطه پیکربندی هاست با عملکرد سایت نوشته ایم، و اگر سایت را از پایه می سازید، ساخت سایتی که از روز اول پیکربندی سرورش مشخص باشد ارزان تر از رفع همین موارد بعد از راه اندازی است.
منابع
- اعلان انتشار وردپرس ۷.۰.۴ برای تاریخ، شرح آسیب پذیری و گزارش دهنده
- صفحه نسخه ۷.۰.۴ برای فهرست فایل تغییر کرده و شاخه های بک پورت شده
هر دو منبع و همه دستورهای بالا در ۲۴ مرداد ۱۴۰۵ روی سرور خودمان اجرا و بررسی شده اند.
دیدگاه ها و پرسش ها
سوالی درباره این مطلب دارید؟ بپرسید؛ پاسخ می دهیم.
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید.