آسیبپذیری اجرای کد از راه دور در Apache Tomcat
Apache Tomcat یک نرم افزار متنباز است که توسط Apache ساخته شده است. اخیراً یک آسیبپذیری اجرای کد از راه دور در Apache Tomcat با شناسه CVE-2020-9484 یافت شد.
نسخههای آسیبپذیر عبارتند از:
- Apache Tomcat 10.x < 10.0.0-M5
- Apache Tomcat 9.x < 9.0.35
- Apache Tomcat 8.x < 8.5.55
- Apache Tomcat 7.x < 7.0.104
به عبارت دیگر تمام نسخههای tomcat 7، 8، 9 و 10 تحت تأثیر این آسیبپذیری قرار میگیرند. بدین منظور باید نسخه tomcat خود را به آخرین نسخه منتشر شده بهروزرسانی نمود.
پیشنیازها
به منظور بهرهبرداری از این آسیبپذیری موارد زیر باید اعمال گردد:
- PersistentManager فعال شده و از یک FileStore استفاده کند.
- مهاجمی با توانایی بارگذاری یک فایل با محتوای دلخواه، نام و محل بارگذاری فایل را کنترل خواهد کرد.
- Gadgetهای موجود در classpath میتوانند جهت یک حمله deserialization جاوا استفاده شوند.
Tomcat PersistentManager
Tomcat از کلمه Manager به منظور توضیح بخشی که sessionها را مدیریت میکند استفاده میکند. sessionها به منظور حفظ وضعیت بین درخواستهای کلاینت استفاده میشوند.
انواع sessionهای موجود در Tomcat عبارتند از:
- apache.catalina.session.StandardManager (پیشفرض)
- apache.catalina.session.PersistentManager
مؤلفه StandardManager، sessionها را در حافظه نگه میدارد. در صورت بسته شدن tomcat، این sessionها در یک شیء بر روی دیسک ذخیره میشوند (به طور پیشفرض به نام SESSIONS.ser).
مؤلفه PersistentManager نیز وظیفهای مشابه با کمی تغییرات را انجام میدهد: تعویض sessionهای بلااستفاده. اگر یک session به مدت x ثانیه بلااستفاده باقی بماند به دیسک انتقال داده میشود که این یک روش کاهش استفاده از حافظه است.
محل ذخیره این sessionها در حافظه میتواند یکی از موارد زیر باشد:
- FileStore: یک دایرکتوری را روی دیسک مشخص کرده و sessionهای تعویض شده با نامی بر اساس session ID ذخیره میشوند.
- JDBCStore: یک جدول را در پایگاه داده مشخص کرده و sessionهای تعویض شده به عنوان ردیف منحصر به فردی ذخیره میشوند.
پیکربندی
به طور پیشفرض tomcat با StandardManager فعال شده اجرا میشود. حساب کاربری Admin میتواند به نحوی پیکربندی شود که با تغییر conf/context.xml از PersistentManager استفاده کند:
شکل 1
هنگامی که برچسب Manager در context.xml ثبت نشده باشد، از StandardManager استفاده میشود.
بهرهبرداری
هنگامی که Tomcat یک درخواست HTTP با کوکی JSESSIONID دریافت میکند، از Manager درخواست میکند وجود session را بررسی کند. مهاجم میتواند مقدار فرستاده شده در درخواست را کنترل کند، در صورت ارسال مقدار ../../../../../../tmp/12345:
- Tomcat از Manager درخواست میکند که وجود ../../../../../../tmp/12345 را بررسی کند.
- در ابتدا وجود این session در حافظه بررسی میشود.
- در صورت عدم وجود آن، Manager در حال اجرا یک PersistentManager است، بنابراین وجود این session در دیسک بررسی میشود.
- محل directory + sessionid + “.session” بررسی شده و ./session/../../../../../../tmp/12345.session را ارزیابی میکند.
- در صورت وجود فایل، آن را deserialize میکند و اطلاعات session را از آن جدا میکند.
شکل 2: برنامه وب خطای HTTP 500 را در حین بهرهبرداری بازمیگرداند، زیرا به جای این که حاوی اطلاعات جلسه باشد، با یک هدف serialize شده مخرب روبرو میشود.
از خط stacktrace در شکل بالا که با خط قرمز نمایش شده است، مشخص میشود PersistentManager تلاش میکند session را از FileStore بارگیری کند. در خط آبی نیز deserialize شدن شیء نمایش داده میشود. این خطا پس از اعمال deserialization حذف میشود، اما پس از در نظر گرفتن شیء به عنوان session (که این طور نیست)، کد مخرب در این بخش اجرا میشود.
در نهایت مهاجم باید بتواند یک شیء مخرب را در محل /tmp/12345.session قرار دهد. بهرهبرداری در اینجا بی معناست، زیرا فقط یک درخواست HTTP است. با این وجود یک کد PoC توسط masahiro311 نیز به وجود آمده است.
نتیجهگیری
این حمله (RCE) دارای تأثیر بالاست، اما با توجه به شرایط مورد نیاز احتمال بهرهبرداری کم است.
- PersistentManager باید توسط مدیر سیستم tomcat به طور دستی فعال شود. این مسئله احتمالاً فقط در وب سایتهای با بار زیاد ترافیک اتفاق میافتد (به احتمال زیاد از فروشگاه JDBC به جای File Store استفاده میشود).
- مهاجم باید برای قرار دادن پرونده serialized مخرب روی سرور، آسیبپذیری بارگذاری فایل جداگانه را بیابد.
- در classpath باید کتابخانههایی وجود داشته باشد که نسبت به حمله هدررفت جاوا (به عنوان مثال gadget) در آنها آسیبپذیر باشند.
با این حال بسیاری از دستگاههای tomcat تحت تأثیر قرار گرفتهاند.
مراجع
[1]