آسیب‌پذیری RCE در سیستم مدیریت محتوای Drupal 8

اخیرا یک آسیب‌پذیری از نوع اجرای دستور از راه دور “RCE” در هسته سیستم مدیریت محتوای محبوب دورپال کشف شده است که این بار ماژول REST نسخه 8 این سیستم را هدف قرار داده است. اگر چه در حال حاضر این آسیب پذیری به صورت پیش فرض غیرفعال است ولی با استفاده از وصله امنیتی ارائه شده توسط دروپال، هکرها توانسته اند این آسیب پذیری را به مرحله بهره برداری برسانند. علاوه بر این نسخه اصلاحی پیشنهاد شده برای این آسیب‌پذیری کامل نمی‌باشد و منجر به خطر افتادن امنیت استفاده کنندگان از این سیستم مدیریت محتوا می‌شود.

در این پست سعی میکنیم تجزیه و تحلیلی مفید و متفاوت بر روی این آسیب‌پذیری داشته باشیم.

تجزیه و تحلیل نسخه پیشنهاد شده توسط دروپال

در اولین واکنش مشاوران دروپال به کشف این آسیب‌پذیری بدین صورت بوده است که کاملا واضح گفته‌اند در صورت فعال بودن ماژول REST اجازه اجرای اعداد دلخواه داده می‌شود. با این وجود همانطور که در ادامه‌ی این پست مشاهده خواهید کرد نشان خواهیم داد که غیرفعال سازی فقط درخواست PATCH یا POST اشتباه است و RCE می‌تواند از طریق یک درخواست GET و بدون هر نوع احراز هویت حتی اگر درخواست‌های PATCH/POST در پیکربندی REST غیرفعال باشد انجام پذیرد و مورد سوءاستفاده قرار گیرد.

بنابراین توصیه به اینکه اجازه ندادن به درخواست‌های PUT/PATCH/POST از شما در برابر این آسیب‌پذیری محافظت می‌کند کاملا اشتباه است. ارتقای دروپال و یا غیرفعال کردن ماژول REST در حال حاضر تنها راه حل ممکن است.

بررسی رفتار استاندارد REST

به طور پیش فرض زمانی API /node/{id} فعال است که ماژول REST فعال باشد.

در متون مستندات REST دروپال یک مثال ساده زده شده است که آن را با هم مرور می‌کنیم:

در این مورد، دروپال Title, Type و Body خود را برای یک Node Object ایجاد خواهد کرد، اما همانطور که انتظار می‌رود، از آنجا که ما تایید احراز هویت نشده‌ایم، درخواست نمی‌تواند انجام شود.

…و حالا رفتار غیر منتظره!!!

با این حال، با تغییر POST به GET، و ارسال یک مقدار نامعتبر href، مانند:

نتیجه کار می‌شود:

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

تجزیه و تحلیل وصله امنیتی ارائه شده:

با مشاهده تفاوت‌های ایجاده شده بین دو نسخه 8.6.9 و 8.6.10 دروپال می‌توانیم مشاهده کنیم که در ماژول REST، اکنون FieldItemNormalizer از ویژگی جدیدی به نام SerializedColumnNormalizerTrait استفاده می‌کند. این ویژگی روش checkForSerializedStrings() را فراهم می‌کند که در کوتاه‌ترین زمان ممکن استثنا را افزایش می‌دهد اگر یک رشته برای یک مقدار که به عنوان یه رشته سریالی ذخیره می‌شود ارائه شود. این نشان دهنده استراتژی استنثایی نسبتا واضحی می‌باشد : از طریق یک درخواست REST مهاجم حالا باید یک ویژگی سریالی ارسال کند. این ویژگی بعدا unserialize() می‌شود(آن‌جا که محتوا از حالت serialized خارج می‌شود و در نتیجه ورودی‌های خاصی که ممکن است ارسال شوند، می‌توانند به اجرای کد روی سایت منجر شوند)، چیزی که به راحتی می‌توان با استفاده از ابزارهایی مانند PHPGGC مورد سو استفاده قرار گیرد.

داشتن تمام عناصر و دانش فنی حال دیگر ایجاد یک تابع unserialize را بسیار آسان می‌کند.

از آنجا که دروپال 8 از Guzzle استفاده می‌کند، می‌توانیم با استفاده از PHPGGC یک Payload حاوی دستورات اجرایی مدنظر تولید کنیم:

اکنون می‌توانیم Payload ساخته شده خودمان را از طریق GET ارسال کنیم:

که نتیجه این آسیب‌پذیری را در عکس زیر که پاسخ دریافتی می‌باشد مشاهده می‌کنیم:

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

همانطور که در بالا به آن اشاره شد در حال حاضر تنها راه حل این مسئله ارتقا نسخه و غیرفعال کردن REST می‌باشد.