آسیب پذیری‌ها

آسیب پذیری در سرورهای Oracle WebLogic
۱۳ خرداد ۱۳۹۹
تعداد بازدید: 0

آسیب پذیری در سرورهای Oracle WebLogic


CVE-2020-2883

در مطلب قبلی راجع به یکی از آسیب پذیری های سطح بالای وب سرور Oracle WebLogic که در سال جدید منتشر شد، صحبت کردیم و بیشتر راجع به آن خواندیم. آسیب پذیری RCE کشف شده امتیاز بالایی داشت و مهاجم با استفاده از پیاده سازی exploit میتوانست آسیب های بعضا جبران ناپذیری را به سرور وارد کند. همانطور که می­توانید در پست قبلی هم مشاهده کنید، برای وصله کردن این آسیب پذیری از تغییر در تابعی به اسم toString() صحبت شد که برای چندماه توانست جلوی هکرها مقاومت کند. اما اوایل ماه May بود (درحدود ۱ ماه قبل) که آسیب پذیری دیگری ثبت شد که باعث میشد همان آسیب پذیری RCE را در همان نسخه های آسیب پذیر Oracle WebLogic داشته باشیم. درواقع وصله ای که شرکت Oracle برای CVE-2020-2555 داده بود نتوانست به خوبی عمل نماید و در نهایت شرکت بزرگ Oracle مجبور به ثبت آسیب­ پذیری دیگری شد و مهاجمان با وارد نمودن ضربه دیگری، باعث شدند وصله قوی تری برای آسیب ­پذیری مذکور از سوی شرکت اراکل ارائه گردد.

این بار هم پای یک فرد چینی در میان است. همانطور که در تصویر بالا قابل مشاهده است، کماکان با فراخوانی روش ChainedExtarctor.extract() امکان ارسال و فراخوانی کد به صورت Remote وجود دارد. محقق امنیتی Quynh Le این مورد را گزارش نمود که فراخوانی روش بالا با استفاده از کلاس های ExtractorComparator و AbstractExtractor قابل انجام است. در کلاس ExtractorComparator روشی  به نام compare() وجود دارد که با همدیگر نگاه دقیق تری به آن خواهیم داشت.

شرح آسیب پذیری

همانطور که در کد این روش در تصویر بالا نیز مشخص است، امکان فراخوانی ChainedExtractor.extract() به وسیله ایجاد یک instance از ChainedExtractor وجود دارد. به روش مشابه، امکان استفاده از روش compare() به وسیله کلاس AbstactExtractor وجود دارد.

کلاس MultiExtractor قابلیت هایی که در AbstractExtractor وجود دارد را extend می­‌نماید و جالب اینجاست که این کلاس توسط ChainedExtractor.extract() قابل دستیابی است که کد مربوطه را در تصویر زیر مشاهده می­‌نمایید.

با اشراف به این موضوع که برای exploit از آسیب پذیری موجود بایستی زنجیره ای از فراخوانی ها ایجاد شود، در ابتدا به call کردن روش compare() از یک Comparator که در نهایت به روش آسیب پذیر readobject() می‌رسد، نیاز داریم. روشی  که به صورت عمومی مستند شده و این کار را برای ما انجام میدهد، از کلاس PriorityQueue استفاده می کند که در ابزار کاربردی ysoserial که یک ابزار کاربردی برای انجام حملات بر پایه deserialization است، قابل مشاهده است. در این ابزار روشی به نام SiftUpUsingComparator() وجود دارد که می تواند compare() را فراخوانی بنماید. البته به وسیله روش های دیگری نیز میتوان این فراخوانی را انجام داد. بطور مثال با استفاده از submitter نیز امکان فراخوانی که مورد نیاز است وجود دارد. اگر بخواهیم موضوع را برایتان پیچیده تر نکنیم، فراخوانی از روش toString() که توسط روش compare() فراخوانی می گردد توسط کلاس های متفاوتی قابل انجام است که شما می توانید از کلاسهایی که به صورت عمومی منتشر شده استفاده نمایید و یا از یکی از کلاس هایی که در کد منبع وب سرور مورد نظر استفاده شده، فراخوانی را انجام داده و اقدام به ارسال فایل shell مورد نظر کنید. به طور مثال زنجیره ای از فراخوانی های انجام شده می تواند مانند تصویر زیر باشد.

نکته دیگری که باید در این جا ذکر نمود، این است که آسیب پذیری موجود در کتابخانه Coherence وجود دارد و طبیعتا هر برنامه کاربردی که از این کتابخانه استفاده نماید که به نحوی با deserialization در ارتباط باشد، در برابر این آسیب پذیری خطرناک، قابل exploit است. یکی از سرویس هایی که به طور مثال، آسیب پذیر می باشد، سرویس Oracle Business Intelligence می باشد که بر روی WebLogic پیاده سازی شده است.  ذکر این نکته نیز قابل توجه و جالب می باشد که از زنجیره فراخوانی های موجود در رویکرد برای فراخوانی compare() و در نهایت toString()، می توان برای exploit نمودن آسیب پذیری CVE-2020-2950 نیز استفاده کرد که این آسیب پذیری نیز از نوع RCE می باشد که از طریق پروتکل HTTP قابل بهره برداری است.

راهکارها

در پایان، شرکت Oracle جزییاتی از انتشار این حمله و آمار سرورهای آسیب پذیر در اختیار عموم قرار نداده و تنها توصیه ای که برای ادمین سرورها می نماید، وصله کردن فوری این آسیب پذیری خطرناک می باشد. به صورت کلی استفاده از پروتکل T3/T3S در صورتی که نیازی به استفاده از آنها برای برنامه کاربردی وب بنیان وجود ندارد، می تواند یک نقطه ضعف برای سرور باشد و اطلاعات شما را در معرض خطرهای جبران ناپذیری قرار دهد. توصیه آرمان داده پویان عدم استفاده از این پروتکل‌های به شدت آسیب پذیر می باشد. شرکت Oracle نیز اعلام نموده که در ۱۴ ام July سال ۲۰۲۰، وصله های بعدی ارائه خواهند شد و باید مشاهده کرد که بعد از آن آیا رویکردهای اتخاذ شده، از حملات جلوگیری می نمایند و یا خیر؟

آرمان داده پویان ارائه دهنده تست نفوذ شبکه

برای اطلاعات بیشتر با ما تماس بگیرید


تازه ترین ها