WordPress که معروف‌ترین CMS موجود در جهان است، به یک اشکال منطقی آسیب‌پذیر است که می‌تواند به یک مهاجم از راه دور اجازه دهد تا تحت شرایط خاصی کلمات عبور کاربران مورد هدف را تغییر دهد.
این آسیب‌پذیری که CVE-2017-8295 نام‌گذاری شده است با دانستن اینکه بر روی تمامی نسخه‌های WordPress و حتی نسخه ۴٫۷٫۴ تأثیرگذار است، بسیار خطرناک به نظر می‌رسد.
این عیب موجود در WordPress توسط محقق امنیتی لهستانی به نام Dawid Golunski از شرکت Legal Hackers در جولای سال گذشته (۲۰۱۶) کشف شد[۱] و به تیم امنیتی WordPress گزارش شد؛ اما WordPress تصمیم به نادیده گرفتن این آسیب‌پذیری گرفت و میلیون‌ها وب‌سایت را در معرض خطر حمله قرار داد.
Golunski در یک گزارش که در تاریخ ۴ می ۲۰۱۷ چاپ شده است[۲] این‌گونه نوشته است: “این مشکل با فرستادن اولین گزارش به WordPress در ماه جولای ۲۰۱۶ چندین بار به تیم امنیتی این شرکت گزارش شده است. این گزارش به دو صورت مستقیم (از طریق پست الکترونیکی ایمن) و همچنین از طریق وب‌سایت HackerOne برای آن‌ها ارسال شد. با توجه به اینکه هیچ‌گونه پیشرفتی جهت وصله کردن این مشکل از طرف این شرکت صورت نگرفته است، این آسیب‌پذیری بدون ارائه کردن هیچ‌گونه وصله‌ای در اختیار عموم قرار گرفت.”
Golunski همان محققی است که یک آسیب‌پذیری حیاتی در کتابخانه‌های منبع باز PHPMailer را کشف کرده بود که به مهاجمان بدخواه اجازه می‌داد تا از راه دور کد دلخواه را در زمینه سرویس‌دهنده وب اجرا کنند و برنامه وب مورد هدف را در معرض خطر قرار می‌داد.
این آسیب‌پذیری در فرآیندی قرار دارد که WordPress درخواست‌های ریست شدن کلمه عبور را بررسی می‌کند.
به‌صورت کلی، هنگامی‌که یک کاربر درخواست ریست کردن کلمه عبور خود را از طریق گزینه فراموشی کلمه عبور می‌دهد، WordPress به‌سرعت یک کد ایمن واحد را تولید می‌کند و آن را به شناسه پست الکترونیک کاربر که در دیتابیس آن ذخیره شده است ارسال می‌کند.
این آسیب‌پذیری چگونه عمل می‌کند؟
هنگام فرستادن این پست الکترونیک، WordPress از یک متغیر با نام SERVER_NAME استفاده می‌کند تا به‌منظور قرار دادن مقادیر فیلدهای From و Return-Path نام میزبان یک سرور را به دست آورد.
در اینجا، From به پست الکترونیک فرستنده باز می‌گردد و Return-Path به پست الکترونیکی‌ای که پست‌های الکترونیک bounce-back باید به آن ارسال شود. (درصورتی‌که فرآیند تحویل به دلایلی با مشکل همراه شده باشد.)
بر طبق گفته Golunski یک مهاجم می‌تواند در هنگام شروع فرآیندِ ریست شدن کلمه عبور برای یک کاربر ادمینِ مورد هدف، یک درخواست HTTP جعلی با یک نام میزبان از پیش تعریف‌شده (برای مثال attacker-mxserver.com) ارسال کند.
ازآنجایی‌که نام میزبان قرار داشته در درخواست HTTP مخرب، یک دامنه تحت کنترل مهاجم است، فیلدهای From و Return-Path در پست الکترونیک مربوط به ریست شدن کلمه عبور به‌گونه‌ای اصلاح خواهد شد که شامل پست الکترونیک مربوط به دامنه مهاجم باشد.
Golunski می‌گوید: “به علت تغییر یافتن سرآیند میزبان، مقدار SERVER_NAME به مقداری که مربوط به نام میزبان انتخاب‌شده توسط مهاجم است تغییر می‌یابد. درنتیجه WordPress سرآیندها و بدنه پست الکترونیک را به بخش /usr/bin/sendmail انتقال می‌دهد.”
شما باید توجه داشته باشید که پست الکترونیک مربوط به ریست شدن کلمه عبور تنها به آدرس پست الکترونیک قربانی ارسال می‌شود، اما ازآنجایی‌که فیلدهای From و Return-Path در حال حاضر به ID پست الکترونیک مهاجم اشاره دارد، مهاجم مربوطه نیز تحت سناریوهای زیر کد ریست شدن کلمه عبور را دریافت می‌کند:
- اگر فرد قربانی به آدرس پست الکترونیک فرستاده شده یک جواب ارسال کند، یک پست الکترونیک به آدرس پست الکترونیک مهاجم که در بخش From آمده است فرستاده خواهد شد.
- اگر بنا به دلایلی سرور پست الکترونیک فرد قربانی فعال نباشد، پست الکترونیک ریست شدن کلمه عبور به‌صورت خودکار به آدرس پست الکترونیکی که در بخش Return-Path به آن اشاره شده است، ارسال می‌شود که در حقیقت همان inbox فرد مهاجم است.
- در یک سناریوی امکان‌پذیر دیگر، برای بازیابی پست الکترونیک bounce-back با زور، یک مهاجم می‌تواند یک حمله DDoS علیه سرور پست الکترونیک قربانی انجام دهد یا تعداد زیادی پست الکترونیک ارسال کند تا اینکه حساب کاربری پست الکترونیک فرد قربانی قادر به دریافت پست الکترونیک دیگری نباشد.
Golunski به وب‌سایت خبری The Hacker News گفته است: “حمله CVE-2017-8295 می‌تواند هم با مداخله کاربر (کلیک کردن بر روی گزینه reply توسط کاربر) و هم بدون مداخله کاربر (افزایش تعداد پست‌های الکترونیک به بیش‌ازحد مجاز) صورت گیرد.
بنا به دلایل مشخص، این سناریوها به‌عنوان روش‌های قطعی و ۱۰۰ درصد قابل‌اطمینان مطرح نیستند، اما در ارتباط با حملات هدفمند، مهاجمان حرفه‌ای می‌توانند به‌گونه‌ای مدیریت کرده تا بتوانند به‌طور موفقیت‌آمیز از این عیب بهره‌برداری کنند.
یکی دیگر از واقعیت‌های قابل‌توجه در بهره‌برداری موفقیت‌آمیز از این عیب به این مورد بستگی دارد که حتی اگر وب‌سایت WordPress دارای آسیب‌پذیری باشد، تمامی وب سرورها به مهاجم اجازه نمی‌دهند تا نام میزبان را از طریق سرآیند SERVER_NAME تغییر دهد، و این در حالی است که WordPress می‌تواند در هر سرور به اشتراک گذاشته شده‌ای به‌عنوان میزبان باشد.
Golunski می‌گوید: “سرآیند سرور SERVER_NAME می‌تواند در تنظیمات پیش‌فرض یک وب سرور آپاچی (رایج‌ترین deployment مربوط به WordPress) و از طریق سرآیند HOST مربوط به یک درخواست HTTP دست‌کاری شود.
ازآنجایی‌که این آسیب‌پذیری در حال حاضر در اختیار عموم قرار گرفته است و هیچ‌گونه وصله‌ای از طرف شرکت مربوطه تاکنون برای آن منتشرنشده است، به مدیران WordPress شدیداً توصیه می‌شود تا تنظیمات سرور خود را به‌روزرسانی کرده و گزینه UseCanonicalName را فعال کرده تا مجبور به داشتن مقدار SERVER_NAME از نوع static/predefined شود.
منابع
[۲]https://exploitbox.io/vuln/WordPress-Exploit-4-7-Unauth-Password-Reset-0day-CVE-2017-8295.html
[۳] http://thehackernews.com/2017/05/hacking-wordpress-blog-admin.html
ثبت ديدگاه