SQL Injection وردپرس از طریق افزونه وردپرس Duplicate-Page

SQL Injection وردپرس از طریق افزونه وردپرس Duplicate-Page

ریسک امنیتی: آسان / از راه دور

DREAD Score: 8.4

آسیب پذیری: تزریق SQL / تزریق شی

نسخه پچ: 3.4

در بررسی افزونه Duplicate-Page آسیب پذیری خطرناک که تزریق SQL می باشد کشف شد.
معمولاً باگ امنیتی افزونه وردپرس به علت بهینه نبودن طراحی افزونه وردپرس می باشد که باعث بروز مشکلات امنیتی و خطرناک غیر قابل جبران می گردد.

باگ امنیتی افزونه Duplicate-Page به صورت خارجی مورد سوء استفاده قرار نگرفته است و در 800،000 سایتی که از این پلاگین وردپرسی استفاده می نمودند تاثیری نداشت.

این فوریت امنیتی توسط سیستم امتیاز بندی مربوط به DREAD تعریف شده است که به آسیب، قابلیت بارز بودن، قابلیت بهره برداری، کاربران آسیب دیده و قابلیت کشف مربوط می شود.

وضعیت کنونی آسیب پذیری

با توجه به نام افزونه بدین معنا که باعث ایجاد صفحات تکراری از صفحه های وردپرس می شود.

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

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

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

خط زمان افشاء

• 22 مارس 2019 – تلاش جهت تماس با نویسنده افزونه
• 22 مارس 2019 – پاسخ نویسنده، ما آسیب پذیری را برای همه کاربران اعلام می کنیم
• 25 مارس 2019 – نویسنده patch را برای بررسی افراد بر می گرداند، که در همان روز انجام پذیرفت.
• 1 آوریل 2019 – اصلاحیه در wordpress.org در دسترس قرار گرفت

جزییات فنی

در صورت فعال سازی این افزونه لینکی در گزینه های صفحهات تحت عنوان ” Duplicate this ” ایجاد می شود.

نگاهی دقیق به آدرس URL که این لینک ایجاد می کند: http://[vulnerable ite]/wp-admin/admin.php?action=dt_duplicate_post_as_draft&post=[the post id]

پارامتر عامل مدیرتی (admin_action_) که توسط عامل hook به جهت تشخیص و اجرا مورد استفاده قرار می گیرد نمونه ای شبیه به “wp_ajax_” می باشد.

hook admin_action_ که در انتهای بیشتر wp-admin / admin.php اجرا می شود.
این فایل تقریبا در تمام صفحات که در / wp-admin / / یک رابط کاربری فراهم شده است قرار دارد که شامل wp-admin / index.php می باشد.

As a result, it may be executed when any kind of users are on their dashboard, or even editing their personal information.
نتیجه این hook ها، ممکن است زمانی اجرا شود که هر نوعی از کاربران در داشبورد خود وارد شوند و یا حتی اطلاعات شخصی خود را ویرایش کنند.

افزونه هایی که از این ویژگی های (hook) برای انجام وظایف جدی خود استفاده می کنند می بایست کلیه راه های مخرب که توسط کاربران کم اهمیت هست را کنترل و بررسی کنند.

با توجه به این نظر، بیایید تا نگاهی به چگونگی عمل hook وردپرس بیاندازیم. از تصویر بالا به این نتیجه می رسیم که روش اتصال به صورت dt_duplicate_post_as_draft می باشد.

با بررسی این روش به نکات جالبی بر خورد کردیم:

1. این هیچ گونه مسیر یا امتیازی را بررسی نمی کند.
2. این می تواند از $_GET[‘post’] or $_POST[‘post’] استفاده کند تا شناسه پست هایی که ما می خواهیم از آن ها کپی بگیریم انجام شود.
3. تنها بررسی مورد استفاده شده بر روی مقدار بازگشتی get_post () می باشد. اگر چیزی غیر از NULL را برگرداند، فرض می شود که همه چیز به درستی کار می کند و می توانیم روال تکثیر صفحه را ادامه دهد.

متاسفانه، تابع get_post () از روش get_instance () از کلاس WP_Post جهت یافتن پست ها با استفاده از شناسه هایشان استفاده می کند، که همانطور که این قطعه کد را می بینید، قبل از جستجو پایگاه داده، $ post_id را به یک عدد صحیح تبدیل می کند!

این بدین معناست که محتویات $ post_id مهم نیست، همیشه پستی معتبر را بازیابی خواهد کرد که متغیر با شناسه پایگاه داده شروع شود. به عنوان مثال “123 hello world” پستی را بر می گرداند که شناسه آن 123 است.

اگر این تکنیک برای شما آشناست، ما از یک ترفند بسیار مشابه در آسیب پذیری Content Injection وردپرس استفاده کردیم که در نسخه 4.7.2 منتشر شد.

در ادامه تحلیل ما از روش dt_duplicate_post_as_draft استفاده می کنیم و می بینیم که $ post_id مستقیما به query $ wpdb-> get_results () اضافه می گردد.

از آنجا که $ post_id حاوی ورودی کاربر unsanitized (کاربر تعریف نشده) است، این منجر به آسیب پذیری SQL Injection می شود.

با مطالئه جزئیات بیشتر همچنین می توانیم به مقادیر بازگشتی که این درخواست آسیب پذیر در قالب یک حلقه foreach () بر می گرداند توجه کنیم که می تواند در جهت استفاده از دستور INSERT query SQL برای اضافه کردن استفاده کرد.

از آنجا که ما می توانیم متغیر $ meta_key را با استفاده از کوئری SQL UNION در اولین درخواست آسیب پذیر کنیم که می توان مقادیر دلخواه را در جدول postmeta تزریق کنیم.

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