آسیب‌پذیری گسترده log4j
آسیب‌پذیری امنیتی log4j، یکی از شایع‌ترین آسیب‌پذیری‌های امنیت سایبری در سال‌های اخیر است که احتمالا درباره آن شنیده‌اید. این آسیب‌پذیری امنیتی در نرم‌افزاری رایگان و متن باز به نام log4j کشف شده است. این نرم‌افزار توسط هزاران وب‌سایت و برنامه کاربردی استفاده می‌شود تا عملکردهایی معمول را انجام دهند؛ عملکردهایی مثل ثبت اطلاعات برای استفاده توسط توسعه‌دهندگان، اشکال‌زدایی و اهداف دیگر. هر برنامه وب به چنین عملکردهایی نیاز دارد و در نتیجه، استفاده از log4j در سراسر جهان فراگیر است.
آسیب‌پذیری Log4j دقیقا چیست؟
متاسفانه، اخیرا مشخص شد که log4j یک آسیب‌پذیری امنیتی کشف‌نشده دارد که در آن اگر داده‌های ارسالی از طریق وب‌سایت حاوی دنباله خاصی از کاراکترها باشند منجر به دریافت و اجرای خودکار نسخه‌ای اضافی از log4j می‌شود. اگر یک مهاجم سایبری از این مشکل سوءاستفاده کند، می‌تواند روی سروری که log4j را اجرا می‌کند، هر نرم‌افزاری که می‌خواهد را جایگزین کند که این نوع حمله، به عنوان Remote Code Execution یا RCE شناخته می‌شود.
نتیجه این است که مهاجمان سایبری، در حال حاضر می‌توانند هزاران وب‌سایت و برنامه آنلاین را به طور کامل تحت کنترل خود درآورند و از این طریق دسترسی لازم برای سرقت پول و داده‌ها را به دست آورند. جامعه امنیتی بر روی این آسیب‌پذیری متمرکز شده و سرورهای در حال اجرای log4j را در سریع‌ترین زمان ممکن برای محافظت در برابر این آسیب‌پذیری به‌روزرسانی کرده‌اند.
پاکسازی آسیب‌پذیری
بنیاد نرم‌افزار آپاچی، به تازگی جزئیاتی از اولین آسیب‌پذیری Log4Shell با نام CVE-2021-44228 را اعلام کرد. همه تحلیل‌های مختلف درباره این آسیب‌پذیری و شیوع آن اعلام کرده‌اند که پاکسازی اثرات این آسیب‌پذیری زمان‌بر است. دلیل اصلی زمان‌بر بودن پروسه پاکسازی، ترکیب عوامل مختلفی است که خطرات ناشی از تهدید را تقویت می‌کنند. باب رودیس، دانشمند ارشد داده‌های امنیت در Rapid7، خاطرنشان کرد که «حتی سازمان‌هایی که برنامه‌های کاربردی مستقر شده را اصلاح کرده‌اند، ممکن است برخی از ماشین‌های مجازی یا imageها را از قلم بیاندازند و آسیب‌پذیری در مجموعه باقی بماند.»
با این حال، تمایز مفهومی بین این آسیب‌پذیری خاص و خطرات آتی ناشی از آسیب‌های مشابه دیگر، حیاتی است. به همین دلیل است که زنجیره تامین نرم‌افزار اهمیت ویژه‌ای پیدا می‌کند. میزان مخرب بودن این آسیب‌پذیری به این معنی نیست که ما در برابر پیچیدگی‌های معماری ناتوان هستیم. با توجه به وابستگی‌های نرم‌افزار به شبکه، ریسکی غیرقابل پیش‌بینی به وجود آمده، اما این به معنای از دست رفتن همه چیز نیست و همواره امکان کم کردن احتمال بروز خطرها وجود دارد.
مشکل از کجاست؟
گزارشی که در The State of Software Security Vol. 11 توسط Veravode با همکاری موسسه Cyentia منتشر شده، یافته‌هایی مربوط به توانایی ما برای کنترل ریسک زنجیره تامین ارائه می‌دهد. آن‌ها به سنجش دقیق‌تر این مشکل کمک کرده‌اند و نشان می‌دهند که حداقل در تئوری می‌توانیم خطرات آن را کاهش دهیم. چند نکته برگزیده از این مقاله شامل موارد زیر هستند:
- ۷۹ درصد از کتابخانه‌ها هرگز به‌روز نمی‌شوند.
- کتابخانه‌های آسیب‌پذیر، سریع‌تر از کتابخانه‌های غیرآسیب‌پذیر به‌روز می‌شوند.
- متداول‌ترین توضیح برای زمان طولانی ارائه به‌روزرسانی، کمبود منابع مورد نیاز توسعه‌دهندگان اعلام شد.
- در بررسی تمام کدها، هیچ سناریویی در رابطه با وابستگی به‌روزرسانی حلقه‌ای یافت نشد.
- ۱۳.۹ درصد از برنامه‌های اسکن‌شده دارای زنجیره‌های به‌روزرسانی که با یک نسخه معیوب خاتمه می‌یافتند بودند.
- زنجیره‌های به‌روزرسانی با بیش از دو مرحله، همیشه در یک نسخه بدون نقص خاتمه می‌یابند؛ به عبارت دیگر تا زمانی که توسعه‌دهندگانی که از کتابخانه‌ها استفاده می‌کنند به دنبال ارائه به‌روزرسانی‌ها باشند، موفقیتشان تضمینی است.
مقاله پیشنهادی“Storage DRS چیست؟ و چطور کار می‌کند؟”
Veracode ریسک وابستگی نرم‌افزار را به عنوان یک مشکل اطلاعاتی معرفی می‌کند و چه در بینش‌های کلیدی، چه در نتیجه‌گیری گزارش، روی این موضوع تاکید می‌کنند که اگر توسعه‌دهندگان اطلاعات مورد نیاز خود را در اختیار داشته باشند، آسیب‌پذیری‌های third-party را به‌طور قابل‌توجهی سریع‌تر اصلاح می‌کنند. با این حال بر اساس یافته‌های بالا، یک عنصر لجستیکی نیز وجود دارد؛ مکانیسم‌های کنترل ریسک در زنجیره تامین نرم‌افزار درک شده‌اند، اما این مکانیسم‌ها به منابع خاصی نیاز ندارند. در واقع با اینکه ریسک زنجیره تامین در حال افزایش است، کنترل این ریسک غیرممکن نیست. کنترل ریسک، وظیفه‌ای است که هنوز به درستی بررسی نشده و اولویت خاصی به آن تعلق ندارد.
استفاده از مدل Zero Trust
با توجه به تعدد سمینارهایی که در رابطه با Zero Trust در سال گذشته شاهد بودیم، موضوع و جریان اصلی سال ۲۰۲۱ را باید Zero Trust بدانیم. بنابراین، پیدایش آسیب‌پذیری Log4Shell در همین سال بسیار طعنه‌آمیز است! مدل Zero Trust چهار ستون اصلی دارد که شامل identity، شبکه، end-pointها و اپلیکیشن می‌شود. به نظر می‌رسد که اکثر سازمان‌هایی که از مدل Zero Trust استفاده می‌کنند علاوه بر بخش اپلیکیشن، در بخش شبکه هم نقص‌هایی دارند؛ از وجود این آسیب‌پذیری در برنامه‌های مختلف که بگذریم، Log4j هرگز نباید قادر به برقراری ارتباط با سرورهای خارجی باشد.
این مبحث صرفا جنبه انتقادی ندارد و باید تلاش کنیم تا جای ممکن از چنین رخدادهایی درس بگیریم. آنچه که مشاهده می‌شود این است که اکثر سازمان‌ها به Zero Trust به عنوان پروژه‌ای نگاه می‌کنند که یک بار انجامش می‌دهند و برای همیشه از آن بهره‌مند هستند. نکته‌ای که نباید در این مورد فراموش کرد، تغییر همیشگی محیط‌های مدرن است که به معنای از بین رفتن دائمی سیاست Zero Trust است. در اینجا، تیم‌ها باید مراقب چالش‌ها باشند و طی تلاشی دائمی، برای حفظ امنیت تلاش کنند.
Zero Trust که به عنوان یک فرآیند چرخه‌ای و چند سطحی در نظر گرفته می‌شود، شبیه اجرای مدرن‌شده اصول امنیتی قدیمی است. باید به این مدل به عنوان چشم‌انداز غیرمتمرکز امنیت برای سیستم‌های غیرمتمرکز نگاه کنیم. با توجه به اینکه ادغام با برنامه‌های third-party را نمی‌توان در همه سطوح حذف کرد، Zero Trust تنها رویکرد قابل دوام برای حفظ امنیت به نظر می‌رسد؛ اما تنها در صورتی که بدانیم Zero Trust سیاستی است که شاید به آن نزدیک شویم اما هرگز به طور کامل به آن دست پیدا نمی‌کنیم.
جمع‌بندی
به عنوان کلام آخر، نیازی نیست که از نرم‌افزارهای third-party استفاده نکنیم. بلکه بر اساس نقل قولی از رودیس، «از کتابخانه‌ها استفاده کنید، اما پیش از این کار آن‌ها را دقیقا بررسی کنید.» با این حال، نباید فراموش کرد که مدیریت آسیب‌پذیری، به تنهایی کافی نیست. بسیاری از حملات ناشی از رفتار مجموعه‌ای از اجزای متفاوت در هنگام تعامل پدید می‌آیند. به همین ترتیب است که سه آسیب‌پذیری کم‌خطر، ترکیب شده و به یک آسیب‌پذیری سطح بالا تبدیل می‌شوند. بنابراین آسیب‌پذیری‌های با شدت کمتر را نباید دست‌کم گرفت و برای برطرف شدنشان باید اقداماتی اصولی انجام داد.
