تمرکز بر Log4Shell ممکن است راه خوبی برای تحریک آژانس‌ها و کسب‌وکارهای ایالات متحده در زمینه امنیت توسعه نرم‌افزار باشد، اما دن لورنک، مدیر عامل Chainguard و رهبر تلاش‌های امضای کد منبع باز Sigstore، گفت که این کار انجام خواهد شد. هنگامی که نقص هایی مانند Log4J به دلیل روشی که فناوری توسط مشتریان پیاده سازی می شود، آسیب پذیر هستند، سخت است. یعنی زمانی که ادمین ها اصل حداقل امتیاز را برای دستگاه ها اعمال نمی کنند.
این با هشدار دائمی مایکروسافت مبنی بر اینکه تهدید Log4Shell برای مشتریان Azure خود همچنان بالاست همسو است. مایکروسافت در ماه دسامبر تنها مشاهده کرده بود که از آن برای استقرار بدافزار استخراج رمزنگاری استفاده می‌شود، اما هشدار داد که هکرهای تحت حمایت دولت در حال بررسی سیستم‌ها برای آن هستند.
طبق بررسی هیئت مدیره، سازمان‌ها باید برای رسیدگی به Log4J در درازمدت آماده شوند، در حالی که تنظیم‌کننده‌های ایالتی و فدرال باید توصیه‌های کاهش CISA را اعمال کنند. سازمان‌ها همچنین باید برنامه‌های پاسخگویی و افشای آسیب‌پذیری مستند داشته باشند.
با این حال، هیئت مدیره “تا حدودی شگفت انگیز” اذعان کرد که “تا به امروز، به طور کلی، بهره برداری از Log4j در سطوح پایین تر از آنچه بسیاری از کارشناسان پیش بینی می کردند، با توجه به شدت آسیب پذیری رخ داده است”.
بر اساس CSRB، Log4Shell اکنون “بومی” است و انتظار می رود حداقل تا سال 2032 روی سیستم ها تأثیر بگذارد.
در این بیانیه آمده است: «این به یکی از فشرده‌ترین واکنش‌های جامعه امنیت سایبری در تاریخ ختم شد.
در این گزارش آمده است که شرکت‌ها و فروشندگان برای کشف محل استفاده از Log4j تلاش کردند و «سرعت، فشار و تبلیغات» چالش‌های دفاعی را تشدید کرد زیرا محققان امنیتی به سرعت آسیب‌پذیری‌های بیشتری را در Log4j پیدا کردند که به سردرگمی و «خستگی وصله‌ای» کمک می‌کرد. در این بیانیه آمده است که مدافعان تلاش کردند تا اسکن آسیب پذیری توسط محققان با حسن نیت را از عوامل تهدید تشخیص دهند. و پاسخ دهندگان یافتن منابع معتبر اطلاعاتی در مورد چگونگی رسیدگی به این مسائل را مشکل یافتند.
در آن زمان، CISA هشدار داد که ممکن است ماه‌ها طول بکشد تا مهاجمان به آن حمله کنند و کمیسیون تجارت فدرال اعلام کند ممکن است سازمان‌های آمریکایی را به دلیل عدم اقدام مجازات کند.
فروشندگان نرم افزار منبع باز به آژانس های فدرال نیز باید مبنایی برای شفافیت داشته باشند. و ایالات متحده باید در ساختارهای تشویقی مورد نیاز برای ایجاد نرم افزار امن سرمایه گذاری کند.
CSRB جزئیات ویرانی هایی را که باعث شد محققان، مدیران، مهندسان نرم افزار و نگهبانان منبع باز که قرار بود پس از نزدیک به دو سال تقویت فناوری WFH در طول همه گیری، به تعطیلات کریسمس بروند، توضیح می دهد.
“پاسخ دهندگان، بخش های عمومی و خصوصی، جامعه منبع باز و محققان در سطح جهانی، به شیوه ای اختصاصی با یکدیگر همکاری و ارتباط داشتند و در تعطیلات آخر هفته و تعطیلات دسامبر کار می کردند.”
مهم‌تر از همه، رویداد Log4j به پایان نرسیده است. هیئت مدیره ارزیابی می‌کند که Log4j یک «آسیب‌پذیری بومی» است و نمونه‌های آسیب‌پذیر Log4j برای سال‌های آینده، شاید یک دهه یا بیشتر، در سیستم‌ها باقی خواهند ماند. ” هیئت می نویسد.
Log4Shell در صدها میلیون دستگاه سازمانی که در معرض اینترنت قرار داشتند وجود داشت. با این حال، علیرغم یا به دلیل تلاش‌های گسترده به رهبری ایالات متحده، یک ماه پس از فاش شدن این نقص، CISA هیچ نفوذ قابل توجهی را مشاهده نکرده بود.
فهرست توصیه‌های CSRB شامل بسیاری از فعالیت‌هایی است که دولت ایالات متحده و شرکت‌های بزرگ فناوری در حال حاضر برای بهبود امنیت نرم‌افزارهای منبع باز انجام می‌دهند. تلاش‌های Google شامل بهبود امنیت بسته‌ها برای زبان‌های برنامه‌نویسی، پشتیبانی از پروژه‌های متن‌باز حیاتی با بودجه بیشتر، مدیریت بسته‌های منبع باز، فشار دادن چارچوب زنجیره تامین Levels for Software Artifacts یا SLSA، و دادن کلیدهای امنیتی دو مرحله‌ای به توسعه‌دهندگان پایتون است. این سرمایه گذاری ها در زمانی انجام می شود که 41 درصد از سازمان ها در مورد امنیت نرم افزار منبع باز خود تردید دارند.
“مدافعان با یک وضعیت چالش برانگیز مواجه شدند؛ آسیب پذیری تقریباً بر هر سازمان شبکه ای تأثیر گذاشت و شدت تهدید مستلزم اقدام سریع بود. این واقعیت که هیچ “لیست مشتری” جامعی برای Log4j وجود ندارد، یا حتی لیستی از مکان هایی که به عنوان یک ادغام شده است وجود ندارد. رابرت سیلورز و هدر ادکینز، نویسندگان CSRB می نویسند: زیر سیستم، مانع از پیشرفت مدافع شد.
“با Log4j، جلوگیری از کل دسته از اشکالاتی که باعث ایجاد آن می شوند، با فناوری امروزی دشوار خواهد بود، اما مواردی مانند fuzzing و طراحی ایمن زبان/کتابخانه به صورت پیش فرض می تواند کمک زیادی کند. اما بهره برداری کامل همچنان نیازمند کتابخانه است. در محیطی با مجوزهای قابل توجهی اجرا شود که بعید است به بسیاری از آنها نیاز باشد.”
منبع: https://www.zdnet.com/article/log4j-flaw-why-it-will-still-be-causing-problems-a-decade-from-now/#ftag=RSSbaffb68
علیرغم تلاش های هماهنگ شده برای جمع آوری سازمان ها برای رفع نقص اصلی نرم افزار منبع باز، مقامات امنیت سایبری حداقل برای یک دهه پایانی برای مشکلات Log4Shell نمی بینند.
نویسندگان ادامه می‌دهند: «دستیابی به این نتیجه‌گیری دشوار بوده است. “در حالی که فروشندگان امنیت سایبری قادر به ارائه برخی شواهد حکایتی از بهره برداری بودند، هیچ منبع معتبری برای درک روندهای بهره برداری در مناطق جغرافیایی، صنایع یا اکوسیستم ها وجود ندارد. بسیاری از سازمان ها حتی اطلاعات مربوط به بهره برداری خاص Log4j را جمع آوری نمی کنند، و گزارش هنوز تا حد زیادی داوطلبانه است.”
این نتیجه گیری هیئت بررسی ایمنی سایبری (CSRB) است در فوریه تاسیس شد بر اساس فرمان اجرایی امنیت سایبری جو بایدن، رئیس جمهور ایالات متحده، که خواستار واکنش ملی به حوادث مهم امنیت سایبری بود. اولین وظیفه این گروه بررسی عیوب Log4Shell در کتابخانه Log4j Java App Logging بود. گزارش و پیشنهادات هیئت مدیره می باشد اکنون از طریق آژانس امنیت سایبری و امنیت زیرساخت وزارت امنیت داخلی (CISA).
CISA یک هفته پس از افشای نقص اجرای کد از راه دور در 9 دسامبر 2021، به سرعت به همه آژانس‌های فدرال دستور داد تا Log4J را با بهترین توانایی‌های خود وصله کنند. بنیاد نرم افزار آپاچی (ASF)، در محصولات VMware، IBM، Oracle، Cisco، SolarWinds و دیگران پیاده سازی شد.
CSRB با تشریح عظمت کار در دست، خاطرنشان می کند که یک آژانس فدرال 33000 ساعت را صرف اصلاح نوردهی های Log4j در شبکه کرده است. این امر باعث ایجاد یک انباشته کار روی آسیب‌پذیری‌های حیاتی دیگر شد، که در آن مرحله توسط CISA به عنوان اجباری برای سازمان‌های فدرال برای اصلاح از طریق کاتالوگ آسیب‌پذیری‌های مورد سوء استفاده شناخته شده آن علامت‌گذاری می‌شد.