در تاریخ 6 ژانویه 2022، تیم اصلی وردپرس نسخه 5.8.3 را منتشر کرد که شامل پچ های امنیتی برای رفع 4 آسیب پذیری مهم است. این پچ ها در نسخه های وردپرس 3.7 به بعد پشتیبانی می شوند.
از زمان انتشار نسخه 3.7، بروزرسانی خودکار هسته وردپرس برای دریافت نسخه‌های امنیتی، فعال شد و اکثر سایت های وردپرسی این پچ ها را به صورت اتوماتیک دریافت کرده‌اند و دیگر آسیب‌پذیر نیستند.
ممکن است سایت هایی که فایل های سیستمی read-only دارند یا بروزرسانی خودکار هسته وردپرس را غیر فعال کرده اند، هنوز آپدیت نشده باشند لذا پیشنهاد می شود مدیران این وب سایت ها نیز در اسرع وقت اقدام به این کار نمایند.
تجزیه و تحلیل آسیب پذیری ها
خوشبختانه، بیشتر آسیب پذیری‌های موجود در هسته وردپرس که در این بروزرسانی اخیر اصلاح شده‌اند، به شرایط خاصی برای سوء استفاده نیاز دارند و در اکثر موارد بعید است که موجب به خطر افتادن وب‌سایتی شوند.
جالب است که بدانید این آسیب پذیری‌ها حداقل از سال 2013 که نسخه 3.7 منتشر شد در هسته وردپرس وجود داشته اند. یکی از آسیب پذیری های رفع شده در این پچ تنها نسخه‌های بسیار قدیمی وردپرس را تحت تأثیر قرار می‌دهد که به سال 2009 بازمی گردد.
آسیب پذیری تزریق کد SQL از طریق WP_Query
امکان سو استفاده از هسته وردپرس به وسیله این آسیب پذیری وجود ندارد اما برخی از افزونه ها و قالب ها ممکن است WP_Query را به گونه ای بکار ببرند که امکان تزریق SQL را به وجود آورند.
تغییراتی در کد های وردپرس رخ داده که به نظر می رسد، تابع clean_query تغییر کرده است. این تابع قبلاً همه عبارت‌های منحصربه فرد را از متغیر آرایه ['query['terms$ استخراج می‌کرد، در حال حاضر، این تغییر موجب شده تا فقط در صورتی که نام فیلد query برابر با Slug یا name باشد، مقادیر منحصر به فرد آرایه را استخراج کند و در غیر این صورت، مقدار عددی ثابت (شناسه یا ID) همه مقادیر آرایه منحصر به فرد را دریافت می کند.
(تصویر1)
آسیب پذیری XSS ذخیره شده از طریق Post Slugs
مانند بسیاری از آسیب‌پذیری‌های XSS، این مورد نیز می‌تواند برای تصرف کامل یک سایت یا افزودن یک "درب پشتی" (backdoor) مخرب مورد استفاده قرار گیرد. با این حال، تنها کاربرانی که اجازه انتشار پست‌ها را دارند می‌توانند از آن سوء استفاده کنند.
این آسیب پذیری می‌تواند به کاربرانی با سطح دسترسی بالا مانند نویسنده یا مدیر وب سایت (Administrator)، اجازه دهد تا حمله XSS را با ایجاد یک Post Slugs مخرب اجرا کنند که در ادامه در خصوص آن توضیح داده خواهد شد. انتظار نمی رود که این آسیب پذیری، مورد سوء استفاده قرار گیرد زیرا به دسترسی بالاتری نسبت به نقش های معمولی نیاز دارد.
با توجه به تغییراتی که در کد های وردپرس به وجود آمده، به نظر می رسد که تابع truncate_post_slug_ واقع در مسیر زیر تغییر کرده است:
wp-includes/post.php
اکنون یک مقدار true به آرگومان سوم تابع utf8_uri_encode اختصاص می یابد که می‌تواند در مسیر زیر مورد استفاده قرار گیرد:
این تابع برای پذیرش آرگومان سوم تغییر یافته است و اگر روی true تنظیم شود، کاراکترهای ascii مانند "<"، " “ " و " ‘ " را رمزگذاری می کند.
(تصویر2)
Post Slug محتوایی در URL وب سایت است که بعد از دامنه قرار می گیرد. مثلا اگر نویسنده در وردپرس بخواهد پستی با عنوان زیر بنویسد:
Hello, world!
اسلاگ پست (Post Slug) به این صورت خواهد بود:
hello-world
و مسیر دسترسی به صورت زیر است:
www[.]example[.]com/hello-world
بدون پاکسازی مناسب داده ها، یک حساب نویسنده یا مدیر هک شده می تواند با استفاده از این کاراکترهای خاص، یک پست یا عنوان مخرب ایجاد نموده تا توسط آن قربانی را مورد حمله قرار دهد.
یک حساب نویسنده یا مدیر هک شده، می تواند چنین حمله ای را در نسخه های قدیمی وردپرس انجام دهد، بنابراین قفل کردن پنل مدیریت وردپرس، با احراز هویت دو عاملی یا موارد مشابه دیگر، بسیار مهم است.
آسیب پذیری تزریق کد SQL از طریق WP_Meta_Query
بر اساس تغییراتی که در کد های وردپرس اتفاق افتاده، به نظر می رسد که تابع find_compatible_table_alias در هر دو مسیر wp-includes/class-wp-meta-query.php و wp-includes/class-wp-tax-query.php اصلاح شده است.
این تابع در هر دو فایل به نحوی تغییر یافته است که متغیر ['sibling['alias$ را پاک کند و هر کاراکتری که حروف نباشد ( جز 0-9، A-Z، a-z، _ نباشد) را با یک آندرلاین ( _ ) جایگزین می کند. این امر با از بین بردن امکان تزریق کاراکترهایی مانند '، "، (، ) و فاصله ها، از تزریق SQL جلوگیری می نماید.
(تصویر3)
آسیب پذیری Object Injection در Multisite ها
برای سوء استفاده از این مشکل نیاز به دسترسی Super Administrator است و فقط سایت های وردپرسی Multisite (چند سایته) تحت خطر هستند. مانند تمام آسیب‌پذیری‌های Object Injection، در این مورد نیز به وجود یک زنجیره POP جداگانه نیاز است. POP مخفف Property Oriented Programming است و این نام از این واقعیت ناشی می شود که مهاجم می تواند تمام ویژگی های یک شیء (object) غیر سریال را کنترل کند.
در حالی که تأثیر یک آسیب‌پذیری Object Injection می‌تواند حیاتی باشد اما این موضوع بر تعداد کمی از سایت‌ها تأثیر می‌گذارد زیرا تنظیماتی که موجب سوء استفاده می شود، بسیار نادر است.
با توجه به تغییراتی که در کد های وردپرس صورت گرفته، به نظر می رسد که تابع upgrade_280 واقع در مسیر wp-admin/includes/upgrade.php تغییر کرده است. این تابع در طول فرآیند نصب یا ارتقا وردپرس Multisite قدیمی تر از نسخه 2.8، استفاده می شود که تمام گزینه های وردپرس را دانلود و سپس با استفاده از تابع unserialize مقدار گزینه (option_value) را از حالت سریال خارج می کند. منظور از سریال سازی (serialize)، تبدیل داده هایی مانند array یا object به صورت متن ساده است در مقابل آن، تابع unserialize داده های سریالی را به یک مقدار php تبدیل می کند. از آنجایی که مقدار گزینه (option_value) ممکن است حاوی اطلاعات ارائه شده توسط کاربر باشد، می تواند باعث ایجاد آسیب پذیری Object Injection شود.
به طور خلاصه، وقتی مهاجم بر یک شیء (object) سریال سازی شده، که به تابع ()unserialize منتقل می شود نظارت می کند، می تواند ویژگی های شیء ایجاد شده را کنترل و توسط متدهایی اقدام به تخریب کند.
این بخش به گونه‌ای تغییر یافته است که با استفاده از تابع maybe_unserialize، فقط داده‌هایی که واقعا به صورت سریال هستند را به غیر سریال تغییر دهد. علاوه بر آن، برای اطمینان از اینکه تغییر به درستی صورت گرفته، بررسی می کند که آیا مقدار گزینه پس از unserialize کردن با مقدار غیر سریال مطابقت دارد یا خیر.
(تصویر4)
نتیجه گیری
در این مقاله، چهار آسیب‌پذیری رفع شده در نسخه امنیتی وردپرس 5.8.3 توضیح داده شده است. اکثر سایت‌های وردپرسی که در حال حاضر فعال هستند، قبلاً از طریق بروزرسانی های خودکار اصلاح شده اند و هر سایتی که آسیب‌پذیر باقی بماند، تنها در شرایط بسیار خاص قابل سوء استفاده است. با این وجود در صورتی که وردپرس شما به طور خودکار به روز نشده است، توصیه می شود که آن را به نسخه اصلاح شده وردپرس به روز کنید.