چگونه توسعه دهندگان برای ایمن سازی آسیب پذیری Log4j تلاش کردند

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

آخر هفته گذشته، اینترنت آتش گرفت، و هنوز مشخص نیست که چه تعداد توسعه دهنده با کپسول های آتش نشانی برای تحت کنترل درآوردن آن مورد نیاز است. با این حال، مجموعه‌ای از اولین پاسخ‌دهنده‌ها در صحنه حضور داشتند: نگهداری‌کنندگان یا توسعه‌دهندگان عمدتاً بدون دستمزد که در اوقات فراغت خود برای اصلاح آسیب‌پذیری‌ها، ارائه راهنمایی‌ها و ارائه شفافیت بسیار مورد نیاز در میان هرج و مرج کار می‌کنند.

در ۹ دسامبر، بنیاد آپاچی یک به‌روزرسانی اضطراری منتشر کرد برای یک آسیب‌پذیری بحرانی روز صفر به نام Log4Shell که در Log4j شناسایی شده بود، یک چارچوب گزارش متن باز که در انواع برنامه‌های جاوا استفاده می‌شود. اشکال، شناسایی شده به عنوان CVE -2021-44228، به مهاجم اجازه می دهد تا کد دلخواه را در هر سیستمی که از کتابخانه Log4j برای نوشتن پیام های گزارش استفاده می کند، اجرا کند. بلافاصله با حداکثر شدت ۱۰ در مقیاس CVSS رتبه‌بندی شد.

همانطور که جان گراهام-کامینگ، مدیر ارشد فناوری Cloudflare نوشت، «این احتمالاً یکی از جدی‌ترین آسیب‌پذیری‌های اینترنت است زیرا هر دو Heartbleed و ShellShock.” حتی Minecraft امن نبود.

اولین پاسخ دهندگان

از آنجایی که توسعه دهندگان و نگهبانان بلافاصله در آخر هفته تلاش کردند تا هر چه بیشتر برنامه های جاوا خود را اصلاح کنند. اولین خط دفاعی خود Log4j بود که توسط تیم Logging Services در بنیاد غیرانتفاعی نرم افزار Apache نگهداری می شود.

تیم Logging Services Apache از ۱۶ داوطلب بدون حقوق تشکیل شده است که تقریباً در هر منطقه زمانی در سراسر جهان توزیع شده اند. گری گرگوری، مهندس نرم افزار و عضو کمیته مدیریت پروژه خدمات ثبت نام آپاچی (PMC)، به InfoWorld گفت: “ما این کار را انجام می دهیم زیرا عاشق نوشتن نرم افزار و حل پازل در اوقات فراغت خود هستیم.”

کانال ارتباطی اصلی PMC ایمیل است و در روز چهارشنبه، ۲۴ نوامبر، ساعت ۷:۵۱ صبح به وقت گرینویچ، گروه یک پیام انفجاری دریافت کرد. Chen Zhaojun، یکی از اعضای تیم امنیت ابری در Alibaba، به آنها هشدار می داد که یک اشکال امنیتی روز صفر در نرم افزار آنها کشف شده است.

گرگوری با حدود چهار ساعت خواب در آخر هفته، گفت: «فوراً واضح بود که این یک مشکل بزرگ خواهد بود.

تیم به سرعت دست به کار شد تا مشکل را به صورت خصوصی برطرف کند، اما زمانی که سوء استفاده در حال صدور به روز رسانی در ساعت ۱۰:۰۰ صبح به وقت گرینویچ روز جمعه، ۱۰ دسامبر. آنها با یک نسخه ۲.۱۶ در ساعت ۲۲:۲۸ به وقت گرینویچ در تاریخ ۱۳ دسامبر.

«من این افراد را می شناسم – همه آنها خانواده و کارهایی دارند که باید انجام دهند. کریستین گروبمیر، توسعه‌دهنده سابق Log4j به بلومبرگ گفت.

در این مرحله در آخر هفته، اعضای فعال PMC به برقراری ارتباط از طریق یک کانال خصوصی Slack روی آوردند، جایی که آنها به مبارزه با این مشکل ادامه دادند و با هم کار کردند تا به‌روزرسانی‌هایی را برای کاربرانی که نسخه‌های قدیمی‌تر جاوا را کار می‌کنند تولید کنند. آنها به سرعت نسخه ۲.۱۲.۲ را برای رفع مشکل کاربران جاوا ۷ تولید کردند. ثابت شده است که یک اصلاح برای جاوا ۶ پیچیده‌تر است، اما در مرحله بعدی آن‌ها قرار دارد.

گرگوری گفت: «به طور کلی، من فکر می‌کنم با وجود عواقب وحشتناک این نوع آسیب‌پذیری، همه چیز به خوبی پیش رفت که یک توسعه‌دهنده با تجربه انتظار داشت. “به ما اطلاع داده شد، یک پچ به سرعت ارائه کردیم و در آن نسخه تکرار کردیم. این چیزی است که من بارها و بارها در محیط های حرفه ای دیده ام.”

Hotpatch و راهنمایی فوری

گروه دیگری که در آخر هفته به سرعت حرکت کرد، تیم آمازون کورتو در خدمات وب آمازون بود. Corretto توزیعی از Open Java Development Kit (OpenJDK) است که این تیم را در خط مقدم مشکل Log4Shell قرار می دهد.

به رهبری مهندس نرم افزار اصلی ولکر سیمونیس، تیم کورتو به سرعت یک هات‌پچ با منبع باز ساخته و برای هر سازمانی که به‌روزرسانی فوری انجام نمی‌شود ممکن است.

همانطور که در صفحه GitHub آن توضیح داده شده است:

این ابزاری است که یک عامل جاوا را به فرآیند JVM در حال اجرا تزریق می کند. عامل تلاش خواهد کرد تا متد lookup() تمام نمونه های بارگذاری شده org.apache.logging.log4j.core.lookup.JndiLookup را وصله کند تا بدون قید و شرط رشته “Patched JndiLookup::lookup()” را برگرداند.

هت‌پچ برای رفع آسیب‌پذیری اجرای کد راه دور CVE-2021-44228 در Log4j بدون راه‌اندازی مجدد فرآیند جاوا طراحی شده است. عامل‌های پویا و استاتیک در JDK 8 و JDK 11 در لینوکس اجرا می‌شوند، در حالی که در JDK 17 فقط عامل استاتیک کار می‌کند.

استیو اشمیت، AWS CISO فهرست جامعی از به‌روزرسانی‌های امنیتی خاص سرویس برای محصولات تحت تأثیر.

در جای دیگر، اعضای تیم جاوا در مایکروسافت، به رهبری مدیر گروه مهندسی اصلی جاوا، مارتین وربورگ، به ارزیابی آن پچ و همچنین توصیه های کلی تری صادر کرد برای محافظت از خود مشتریان، از جمله چندین راه حل توصیه شده تا زمان به روز رسانی کامل امنیتی می توان اعمال کرد.

Google Cloud با به‌روزرسانی محصول امنیتی Cloud Armor خود پاسخ داد که یک قانون فوری فایروال برنامه کاربردی وب (WAF) در ۱۱ دسامبر صادر کرد تا به شناسایی و مسدود کردن سوء استفاده های تلاش شده از CVE-2021-44228 کمک کند.

«در تلاش برای کمک به مشتریان خود برای رفع آسیب‌پذیری Log4j، یک قانون WAF از پیش پیکربندی‌شده جدید به نام «cve-canary» معرفی کرده‌ایم که می‌تواند به شناسایی و مسدود کردن تلاش‌های سوء استفاده از CVE-2021-44228 کمک کند. مدیر محصول برای Cloud Armor و دیو ریسفلد، مدیر متخصص شبکه در Google در یک پست وبلاگ در روز شنبه نوشت.

چه کاری می توانید انجام دهید

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

اولین کاری که باید انجام دهید این است که تشخیص دهید که آیا Log4j در برنامه های شما وجود دارد یا خیر. همچنین مهم است که توجه داشته باشید که همه برنامه ها در برابر این اکسپلویت آسیب پذیر نیستند. هرکسی که از یک نسخه جاوا بالاتر از ۶u212، ۷u202، ۸u192 یا ۱۱.۰.۲ استفاده می کند، به لطف محافظت اضافی برای بارگیری کلاس راه دور JNDI (نامگذاری جاوا و رابط دایرکتوری) در آن نسخه ها، باید ایمن باشد.

به طور مشابه، کاربران نسخه‌های Log4j بالاتر از ۲.۱۰ باید با تنظیم ویژگی سیستم formatMsgNoLookups روی true و تنظیم پارامتر JVM -Dlog4j2.formatMsgNoLookups=true، مشکل را کاهش دهند. یا با حذف کلاس JndiLookup از مسیر کلاس.

هنوز تمام نشده است

از آنجایی که آسیب‌پذیری Log4j نه تنها بر برنامه‌های جاوا، بلکه بر هر سرویسی که از کتابخانه استفاده می‌کند تأثیر می‌گذارد، سطح حمله Log4Shell احتمالاً بسیار بزرگ است.

به عنوان لوسیان کنستانتین برای CSO نوشت: «جامعه هنوز در حال کار برای ارزیابی سطح حمله است، اما به دلیل اکوسیستم پیچیده وابستگی‌ها، احتمالاً بزرگ خواهد بود. برخی از مؤلفه‌های تأثیرگذار بسیار محبوب هستند و توسط میلیون‌ها برنامه و سرویس سازمانی استفاده می‌شوند.»

به نوبه خود، تیم Apache Logging Services “به ارزیابی ویژگی های Log4j که می تواند خطرات امنیتی بالقوه ای داشته باشد ادامه خواهد داد و تغییرات لازم برای حذف آنها را انجام خواهد داد. رالف گورز، یکی از اعضای تیم Apache Logging Services، به InfoWorld گفت، در حالی که ما تمام تلاش خود را برای حفظ سازگاری به عقب انجام خواهیم داد، این ممکن است به این معنی باشد که ما باید ویژگی هایی را که ممکن است از آنها استفاده می کنند غیرفعال کنیم.

حتی با وجود اینکه برنامه‌نویسان بی‌شماری در آخر هفته تلاش خستگی‌ناپذیری برای رفع آسیب‌پذیری Log4j کردند، تعداد زیادی از آنها دیرتر پاسخ می‌دهند. بنابراین تأثیر Log4Shell احتمالاً طولانی مدت و گسترده خواهد بود.

همانطور که تونی رابینسون، تحلیلگر امنیتی توئیت کرد: “در حالی که افراد خوب آنجا هستند در حال رفع سریع مشکل با وصله آن هستند، مکان‌های زیادی وجود دارد که پچ نمی‌شوند یا برای مدتی نمی‌توانند وصله کنند. سپس شروع به ورود به نرم‌افزاری می‌کنید که عمرش به پایان می‌رسد یا ممکن است وصله نشده باشد.»