آسیب‌پذیری Spring4Shell: ارزیابی ریسک
چگونه باید تشخیص دهید که آیا سیستم‌های شما در معرض مخاطرات ناشی از یک آسیب‌پذیری مهم و چشمگیر مثل Spring4Shell قرار دارند یا خیر؟ ممکن است برای دریافت خدمات بیمه یا یکسری از گواهینامه‌های خاص از شما درخواست شود که تعدادی آزمون خارجی را بر روی دارایی‌های تحت وب‌تان اجرا کنید. این گزارش‌ها معمولاً نشان می‌دهند که بعضی از بخش‌های وب‌سایت شما در معرض خطر بوده و احتمال دارد منجر به بروز مشکلات و مخاطرات امنیتی برای وب‌سایت‌تان گردند. در نهایت باید درباره تشخیص‌های مثبت کاذب تحقیق کنید و در صورت اطمینان به مدیریت اطلاع دهید که آیتم شناسایی شده واقعاً در معرض خطر قرار دارد.
پیش از این بارها موارد تشخیص‌های مثبت کاذب را در اسکن‌های خارجی مشاهده کرده‌ایم که دلیل اصلی آن باز بودن یک پورت و ارتباط آن با یک مشکل شناخته شده است حتی اگر سرویس مدنظر بر روی آن پورت در حال اجرا نباشد. زمان‌هایی که یک تست نفوذ یا اسکن آسیب‌پذیری دارید، می‌توانید با یافته‌ها مخالفت کرده و به محقق توضیح دهید که آیتم مدنظر منجر به بروز آسیب‌پذیری برای شما نمی‌شود. البته این فرایند فرصت شما برای انجام سایر اقدامات امنیتی را کمتر می‌کند. از طرفی با توجه به اینکه پذیرفتن این موارد به جای بحث درباره آنها با بازرس به زمان نسبتاً کمتری نیاز دارد، پس در بسیاری از موارد با این یافته‌ها موافقت می‌کنیم.
آیا Spring4Shell یک تهدید واقعی محسوب می‌شود؟
پیش از این Spring4Shell یک نگرانی مهم به حساب می‌آمد اما به تدریج مشخص شد که تأثیر چندان چشمگیری ندارد. مایکروسافت برای مقابله با اکسپلویت‌های Spring4Shell یعنی CVE-2022-22963، CVE-2022-22965 و CVE-2022-22947 در فایروال برنامه‌های کاربردی تحت وب آژور سازوکارهای حفاظتی مخصوصی منتشر کرد.
تیم‌های امنیتی و سازمان‌ها برای ارزیابی تأثیر یک آسیب‌پذیری معمولاً یا با افراد مورد اعتماد در تصمیم‌گیری‌های امنیتی مشورت می‌کنند یا اطلاعات گزارش شده درباره این مسئله را بررسی می‌نمایند. همچنین در مورد Spring4Shell چنین به نظر می‌رسد که سرخط اخبار منتشر شده صرفاً هیجان کاذب ایجاد می‌کند و اشاره چندان زیادی به مخاطرات واقعی ندارد.
برای مثال مایکروسافت درباره Spring4Shell می‌گوید: «در 31 مارس 2022 میلادی آسیب‌پذیری‌های موجود در فریم‌ورک اسپرینگ برای جاوا به صورت عمومی اعلام شدند. مایکروسافت در حال ارزیابی تأثیر این آسیب‌پذیری‌ها است. این وبلاگ مخصوص مشتریانی است که در پی حفاظت از خودشان در برابر سوءاستفاده و شناسایی وجود آسیب‌پذیری اجرای کد از راه دور CVE-2022-22965 که با عناوین SpringShell یا Spring4Shell هم شناخته می‌شود در شبکه خودشان هستند. فریم‌ورک اسپرینگ از جمله فریم‌ورک‌های پرکاربرد اپن سورس سبک وزن برای جاوا است. در نسخه 9 یا جدیدتر کیت توسعه جاوا، یک مهاجم می‌تواند از راه دور و از طریق قابلیت انقیاد پارامترهای این فریم‌ورک یک شی AccessLogValve به دست آورده و سپس از مقادیر مخرب برای فعال کردن سازوکار پایپ لاین استفاده کند و در صورت وجود شرایطی خاص، اطلاعات مد نظر را در فایلی در مسیر دلخواه بنویسد».
در واقعیت، شرایط ذکر شده توسط مایکروسافت تقریباً غیرعادی بوده و اکسپلویت‌های واقعی چندان زیادی برای آن مشاهده نشدند. اظهارات محققانی مثل Will Dormann نشان می‌دهد که این خبر آنگونه که به نظر می‌رسد مهم نیست. بنا به گفته او: «فقط تعداد کمی از برنامه‌های کاربردی تحت وب (مثل Red Hat JBoss Fuse 7 که هر چند کتابخانه آسیب‌پذیر اسپرینگ را ندارد اما کد اکسپلویت منتشر شده در اینترنت بر روی آن کار نمی‌کند) واقعاً تحت تأثیر چنین آسیب‌پذیری قرار دارند».
براساس گزارش‌های اخیر Spring4Shell در حملات هدفمندی در سنگاپور استفاده شده و مهاجمان توانسته‌اند با استفاده از آن از بدافزار بات‌نت Mirai بر روی سیستم‌ها استفاده کنند. مشخص نیست که آیا این کد مختص سرورهای ذکر شده در سنگاپور است یا اینکه آزمایشی برای اجرای یک حمله بزرگتر بوده است.
بهترین روش برای واکنش به این آسیب‌پذیری‌ها
در چنین شرایطی تیم‌های امنیت سایبری باید کدام مسیر را انتخاب کنند؟ ترس و وحشت و نصب وصله‌های امنیتی بدون اجرای تست یا کنار گذاشتن نرم‌افزارهایی که احتمالاً آسیب‌پذیر هستند؟ در پاسخ به این سوال ابتدا باید بررسی کنید که در بین تجهیزات خودتان و اینترنت چه موانعی وجود دارند؛ حتی برای تجهیزاتی که با اینترنت در تماس هستند، هر دستگاه یا منبعی باید راهکاری برای فیلتر یا جستجوی الگوهای مشابه داشته باشد. برای مثال فایروال برنامه‌های کاربردی تحت وب می‌تواند الگوها یا رشته‌های غیرعادی را جستجو کند. فروشندگان برنامه‌های کاربردی تحت وب معمولاً به سرعت مجموعه قوانینی به این فایروال‌ها اضافه می‌کنند تا حملات احتمالی را شناسایی نمایند.
بهترین واکنش به خطر Spring4Shell
در رابطه با Spring4Shell می‌توانید یک فهرست سیاه در فایروال تنظیم کنید تا رشته‌های حاوی مقادیری مثل class.*، Class.*، *.class.* و *.Class.* را مسدود نماید.
سپس بررسی کنید که آیا در سیستم‌های شما کد آسیب‌پذیر وجود دارد یا خیر. ممکن است نسخه‌های آسیب‌پذیر جاوا یا سرور تام‌کت بر روی سیستم‌های‌تان وجود نداشته باشند. ظاهراً Spring4Shell بر روی پیکربندی‌های زیر تأثیرگذار است:
- نسخه‌های فریم‌ورک اسپرینگ قبل از 5.2.20، 5.3.18,و کیت توسعه جاوا نسخه 9 یا بالاتر؛
- آپاچی تام‌کت؛
- وابستگی Spring-webmvc یا spring-webflux؛
- انقیاد پارامتر اسپرینگ که برای استفاده از یک نوع پارامتر غیرساده خاص تنظیم شده باشد مثل اشیای ساده قدیمی جاوا؛
- فایل‌های قابل نصب بسته بندی شده در قالب آرشیوهای WAR
- نصب‌های مبتنی بر JAR
در نهایت سعی کنید همواره اطلاعات و منابع مفید را بررسی کنید. اگر گروه‌های تخصصی برای بررسی حقایق آسیب‌پذیری‌ها ندارید، بهتر است اطلاعات بیشتری را با مراجعه به وب‌سایت‌هایی مثل ردیت و سایر وبلاگ‌ها اطلاعات بیشتری کسب کنید چون معمولاً شامل پرسش‌های بیشتر یا راهکارهایی هستند که ممکن است شما و تیم‌تان به آنها فکر نکرده باشید. اگر منابع خارجی امنیتی در اختیار دارید با مشاوران و اجراکنندگان تست نفوذ تماس بگیرید تا منابع و توصیه‌های لازم را از آنها دریافت کنید.
در نهایت آسیب‌پذیری Spring4Shell را جدی بگیرید اما در تخصیص منابع دقت کنید. صرفاً با خواندن یک سرخط درباره آسیب‌پذیر بودن خودتان قضاوت نکنید.
برای مطالعه سایر مقالات در حوزه امنیت سایبری اینجا کلیک کنید.
منبع: csoonline
