اگر در زمینه امنیت کار می‌کنید، احتمالاً روزهای اخیر را درگیر رسیدگی فوری به آسیب پذیری Log4Shell با شناسه (CVE-2021-44228) بوده‌اید؛ مثلاً به دنبال یافتن موارد استفاده از Log4j در محیط خود گشته‌اید و یا از وندورها (vendors) در مورد راهکارشان پرس‌وجو کرده‌اید. به احتمال زیاد درباره‌ی پیامدها و اقدامات لازم نیز مطالعه کرده‌اید. این مقاله برای تمام کسانی است که می‌خواهند بفهمند چه خبر است و چرا دوباره در اینترنت جنجال به پا شده است. برای متخصصان امنیت نیز پرسش‌هایی را از منظر بلندمدت و پیرامون پیامدهای گسترده‌تر این مسئله مطرح و بررسی کرده‌ایم.
Log4Shell چیست؟
آسیب‌پذیری Log4Shell – با شناسه CVE-2021-44228 – یک آسیب‌پذیری حیاتی است که اجرای کد از راه دور (RCE) را در سیستم‌هایی که از Log4j شرکت آپاچی (Apache Software Foundation) استفاده می‌کنند، امکان‌پذیر می‌نماید. Log4j یک کتابخانه اوپن سورس جاوا است که به طور گسترده در محصولات و برنامه‌های نرم‌افزاری تجاری و اوپن‌سورس استفاده می‌شود.
Log4j چیست؟
Log4j یکی از رایج‌ترین ابزارهای ارسال متن برای ذخیره در فایل‌های لاگ و/یا دیتابیس است. این ابزار در میلیون‌ها اپلیکیشن و در وبسایت تمامی سازمان‌های سراسر اینترنت استفاده می‌شود. به عنوان مثال، اطلاعات لازم برای مانیتور بازدیدکنندگان وبسایت، اخطار موقع بروز خطا و کمک به رفع مشکلات تیم پشتیبانی در فرایند تریاژ، توسط Log4j ارسال می‌شود.
مشکل چیست؟
ظاهراً Log4j فقط استرینگ‌های Plain را لاگ نمی‌کند. تکست استرینگ‌هایی (plain strings) که به روش خاصی فرمت شده باشند، درست مانند یک لاین از یک برنامه کامپیوتری اجرا می‌شوند. مشکل اینجاست که این مسئله به عوامل مخرب اجازه می‌دهد تا کامپیوترها را در سراسر اینترنت دستکاری کنند و بدون خواست یا اجازه‌ی صاحب کامپیوتر، کارهایی را روی آن انجام دهند. در حملات سایبری از این مسئله برای سرقت اطلاعات، اعمال زور یا اخاذی از صاحبان یا اپراتورهای کامپیوتر استفاده می‌شود.
این آسیب‌پذیری همان چیزی است که ما از آن به عنوان Log4Shell یا CVE-2021-44228 یاد می‌کنیم. Log4j خودِ تکنولوژیِ آسیب‌پذیر است.
آیا مسئله Log4Shell واقعاً جدی است؟
در یک کلام بله.
کیتلین کیسکا (Caitlin Kiska)، مهندس امنیت اطلاعات در کاردینال هلث (Cardinal Health)، موضوع را اینطور بیان می‌کند:
«تصور کنید نوع خاصی از پیچ و مهره در بیشتر خودروها و قطعات خودروی جهان به کار می‌رود و اعلام می‌کنند که فقط آن پیچ باید تعویض گردد».
گلن تورپ (Glenn Thorpe)، مدیر پاسخگویی به تهدیدات اضطراری Rapid7، اضافه می‌کند: «… و وجود آن پیچ به هر کسی اجازه می‌دهد که ماشین را تحت اختیار بگیرد».
اولین مسئله استفاده‌ی گسترده از Log4j است. این ابزار کوچک در سیستم‌های بی‌شماری در سراسر اینترنت استفاده می‌شود که همین مسئله اصلاح (remediation) یا کاهش مخاطره (mitigation) آن را به کاری سخت و بزرگ تبدیل می‌کند.
مسئله دوم این است که مهاجمان می توانند از آن به طرق مختلف استفاده کنند، بنابراین با هیچ محدودیتی مواجه نیستند.
شاید بزرگترین نگرانی این باشد که استفاده از این آسیب‌پذیری برای اهداف مخرب بسیار آسان است. آسیب‌پذیری‌های اجرای کد از راه دور (RCE) همیشه نگران‌کننده هستند، اما می‌دانید که اکسپلویت این آسیب‌پذیری‌ها پیچیده است و به مهارت فنی تخصصی نیاز دارد. به این ترتیب تعداد افرادی که می‌توانند از آنها استفاده کنند محدود می‌شود و سرعت حملات کاهش می‌یابد بنابراین مدافعان می‌توانند به صورت ایده‌آل اقدامات اصلاحی را انجام دهند. این مسئله در مورد Log4Shell صادق نیست. ابزار Log4j به گونه‌ای طراحی شده است که هر داده‌ی ورودی را که فرمت مناسبی داشته باشد ارسال کند، بنابراین تا زمانی که مهاجمان بدانند چگونه دستورات خود را به فرمت مناسب تبدیل کنند (که چیز پنهانی هم نیست)، می‌توانند از این باگ سوءاستفاده کنند. بد نیست بدانید که همین حالا نیز در حال انجام همین کار هستند.
آیا وضعیت واقعاً ناامیدکننده است؟
قطعاً نه. خبر خوب این است که شرکت آپاچی Log4j را برای رفع این آسیب‌پذیری به‌روزرسانی کرده است. تمام سازمان‌ها باید فوراً وجود این آسیب‌پذیری را در محیط خود بررسی کنند و سیستم‌های آسیب‌دیده را به آخرین نسخه پچ به‌روزرسانی کنند.
اولین به‌روزرسانی – نسخه 2.15.0 – در 6 دسامبر 2021 منتشر شد. با افزایش اکسپلویت‌های گروه‌های متفرقه، مشخص شد که این به‌روزرسانی به طور کامل مشکل را در تمام موارد برطرف نکرده است، ضعفی که دیتابیس ملی آسیب‌پذیری امریکا (NVD) تحت عنوان CVE-2021-45046 کدگذاری کرد.
در نتیجه، در 13 دسامبر، بنیاد آپاچی نسخه 2.16.0 را منتشر کرد که به طور کامل پشتیبانی از الگوهای message lookup را حذف می‌کند، بنابراین به طور کامل در را به روی عملکرد JNDI می‌بندد و احتمالاً تیم‌های توسعه پس از این آپدیت مجبور می‌شوند به سراغ کدبیس خود بروند و material section هایی را که وظیفه‌ی لاگ‌کردن را برعهده دارند، به‌روزرسانی کنند.
ساده به نظر می رسد، همینطور است؟
متأسفانه این کار احتمالاً کاری بسیار سخت و بزرگ خواهد بود و به مراحل مختلفی از شناسایی تا اصلاح یا کاهش مخاطره (remediation/ mitigation) نیاز داشته باشد.
به جامعه کارشناسان تست نفوذ بپیوندید:
اصلاح
اولین اقدام شناسایی تمام برنامه‌های آسیب‌پذیر است؛ این برنامه‌ها ممکن است از تامین‌کننده‌های ثالث تهیه شده باشند یا ممکن است در خود سازمان توسعه داده شده باشند. NCSC NL لیستی از نرم‌افزارهای تحت تاثیر این آسیب‌پذیری را ارائه کرده است و در عین حال سازمان‌ها باید مشاوره‌های امنیتی ارائه شده توسط وندورها را برای کسب به‌روزترین اطلاعات دنبال کنند.
برای اپلیکیشن‌هایی که داخل سازمان توسعه یافته‌اند، سازمان‌ها دست‌کم باید کتابخانه‌های Log4j خود را به آخرین نسخه به‌روزرسانی کنند (که از تاریخ ۱۴-۱۲-۲۰۲۱ و نسخه 2.16 است) و به اصطلاح mitigation ها را اعمال کنند که شامل افزودن یک پارامتر به تمام اسکریپت‌های راه‌اندازی جاوا است و تنظیمات به‌روزرسانی ماشین مجازی جاوا را به جدیدترین و ایمن‌ترین نسخه‌ها شدیداً تشویق می‌کند. تیم امنیتی آپاچی طی گزارشی تکمیلی فهرستی از تمام پروژه‌های آسیب‌دیده‌ی آپاچی را منتشر کرده است که می‌تواند برای تسریع شناسایی و تشخیص آسیب‌پذیری‌ها مفید باشد.
حال به دو نوع بررسی می‌رسیم؛ بررسی‌های «از راه دور» (remote)، مانند همان اکسپلویت از راه دوری که مهاجم انجام می‌دهد، در مقابل بررسی‌های «احراز هویت‌شده» (authenticated) فایل‌سیستم‌های local. بررسی‌های از راه دور باید هم از طریق آدرس IP و هم با نام دامنه یا نام هاست مجازی کاملاً بررسی شده باشد؛ چرا که ممکن است الگوریتم‌های روتینگ متفاوتی وجود داشته باشد که با اسکن از طریق آدرس IP شناسایی نشوند.
این اقدامات باید هر وقت که یک نمونه آسیب‌پذیر از Log4j دیده شد، انجام شود. تصور نکنید که این مشکل فقط برای سیستم‌های مبتنی بر اینترنت یا سیستم‌های live-running پیش می‌آید. ممکن است batch job هایی وجود داشته باشد که به صورت ساعتی، روزانه، هفتگی، ماهانه و غیره بر روی داده‌های ذخیره‌شده اجرا می‌شوند که ممکن است شامل استرینگ‌های اکسپلویت باشد که می‌تواند اجرای اکسپلویت را تریگر کند.
فارنزیک
حملات دست‌کم از اول دسامبر 2021 فعال بوده‌اند و شواهد نشان می‌دهد که این نقص از مارس 2021 شناسایی شده است. بنابراین، هوشیارانه است که رویکرد ” assume breach” را اتخاذ کنید. توجه داشته باشید که این حمله فقط یک حمله مبتنی بر وب نیست. نشانه‌های اولیه و کاملا عمومی اکسپلویت شامل تغییر نام دستگاه‌های iOS و خودروهای تسلا بود. هر دوی این شرکت‌ها به طور مرتب متاداده‌ها را از دستگاه‌های مربوطه خود بازیابی می‌کنند و به نظر می‌رسد استرینگ‌های مذکور در جایی از زنجیره پردازش به کنترل‌کننده‌های Log4j منتقل شده‌اند. باید تمام لاگ‌های سیستم‌های مبتنی بر اینترنت و لاگ‌های هر جایی را که در آن پردازش Log4j انجام می‌شود، بازبینی کنید.
اکسپلویت‌ها عموماً لازم دارند که پس از استقرار، چیزهایی را از منابع خارجی متعلق به مهاجم دانلود کنند (همانطور که در هر حمله‌ای پس از دستیابی به دسترسی اولیه می‌بینیم)، بنابراین راهکارهای امنیتی که فرایندهایی برای تشخیص الگوهای رفتاری بدافزارها و حملات دارند، ممکن است قبلاً برخی از این حملات را شناسایی یا متوقف کرده باشند. نقص Log4j اجازه می‌دهد که مسیرهای نسبتاً هوشمندانه‌ای برای نشت داده‌ها، به ویژه از نوع DNS وجود داشته باشد. مهاجمان مقادیر را از متغیرهای محیطی و فایل‌هایی که آدرس مشخصی در فایل‌سیستم دارند بیرون می‌کشند و نام‌های دامنه را از آنها ایجاد می‌کنند. این بدان معناست که سازمان‌ها باید لاگ‌های کوئری DNS را تا آنجا که ممکن است بررسی کنند.
توجه: این کار ممکن است کمی زمان ببرد، اما حتماً باید انجام شود تا مطمئن شوید که از پیش قربانی حملات نشده‌اید.
رویکرد Proactive (فعال)
سازمان‌ها برای احتیاط بیشتر باید در زمان نشت داده‌ها بخش‌های IP حیاتی (جایی که Log4j در آن قرار داشته است) را مجدداً شماره‌گذاری کنند، در سیستم‌های حیاتی (جایی که Log4j در آن قرار داشته است) نام هاست را تغییر بدهند و اطلاعات هویتی را ریست کنند. به ویژه آنهایی که با Amazon AWS و سایر تأمین‌کنندگان cloud مرتبط هستند.
چه کسانی باید به log4shell توجه داشته باشند؟
تقریباً هر سازمانی، صرف نظر از اندازه، بخش یا جغرافیا. اگر هر نوع حضوری در وب دارید یا به اینترنت متصل می‌شوید، باید مراقب باشید و وضعیت خود را بررسی کنید. اگر تمام جنبه‌های فنی کسب و کار خود را برون سپاری می‌کنید، از وندورهای خود بپرسید که در مورد این موضوع چه اقداماتی صورت می‌دهند.
چه کسانی و چگونه اکسپلویت می‌کنند؟
به نوعی… هر کسی می‌تواند این آسیب‌پذیری را اکسپلویت کند.
محققین امنیتی (برخی به صورت مستقل و برخی از اعضای سازمان‌های امنیت سایبری) از این اکسپلویت برای به دست آوردن درک اولیه از سطح حمله‌ی مبتنی بر اینترنت استفاده می‌کنند.
مهاجمان سایبری نیز بسیار فعال هستند و می‌خواهند قبل از اینکه سازمان‌ها پچ‌های خود را نصب کنند، از این آسیب‌پذیری استفاده کنند. بات‌نت‌هایی مانند Mirai، خود را برای استفاده از کد اکسپلویت جهت انجام حملات نشت داده‌های حساس و کسب دسترسی اولیه به سیستم‌ها (برخی در عمق سازمان‌ها) سازگار کرده‌اند.
گروه‌های باج‌افزاری از قبل وارد عمل شده‌اند و ضعف Log4j را تبدیل به اسلحه‌ای برای تهدید سازمان‌ها کرده‌اند.
اوضاع چطور پیش می‌رود؟
این کمپین‌ها تازه اول کار است. حملات پیچیده‌تر از سوی گروه‌های جدی‌تر و توانمندتر در روزها، هفته‌ها و ماه‌های آینده رخ خواهد داد و احتمالاً بیشتر روی نرم‌افزارهای درجه یک سازمانی که آسیب‌پذیر هستند، تمرکز خواهند کرد.
بیشتر حملات اولیه از طریق نقاط تزریق داخل وب سایت (website-focused injection points) مثلاً فیلدهای ورودی، باکس‌های جستجو، هدرها و غیره) انجام می‌شود. کمپین‌های پیشرفته‌تری وجود خواهند داشت که اندپوینت‌های API را (حتی APIهای «پنهان» که بخشی از اپلیکیشن‌های موبایلی شرکت هستند) هدف قرار می‌دهند و سعی می‌کنند از راه‌های موذیانه‌ای استرینگ‌های اکسپلویت را از گیت عبور دهند (مانند تغییر نام دستگاه iOS).
حتی سازمان‌هایی که برنامه‌های دیپلوی‌شده را اصلاح کرده‌اند ممکن است برخی از ایمیج‌های کانتینرها یا ماشین مجازی را که مرتباً یا به‌ندرت فعال می‌شوند، جا انداخته باشند. حملات Log4Shell به راحتی اتوماسیون می‌شوند و این حملات را مثل حملات WannaCry و Conficker به کرات مشاهده خواهیم کرد (بله، هنوز هم شاهد اکسپلویت‌های بسیار زیادی از این آسیب‌پذیری‌ها هستیم).
آیا نگران آسیب‌پذیری‌های مشابه در سیستم‌های دیگر باشیم؟
در آینده نزدیک، تیم‌های امنیتی باید توجه خود را صرف شناسایی سیستم‌های دارای پکیج‌های Log4j کنند.
در بلندمدت، با وجود اینکه پیش‌بینی شناسایی آسیب‌پذیری‌های مشابه غیرممکن است، می‌دانیم که کاهش و غلبه بر CVE-2021-44228 مستلزم توجه مستمر تیم‌های امنیت، زیرساخت و برنامه‌نویسی است.
در کنار Log4Shell، آسیب‌پذیری CVE-2021-4104 را نیز داریم – که در 9 دسامبر 2021 گزارش شد – یک نقص در کتابخانه لاگ جاوا Apache Log4j در نسخه 1.x. JMSAppender که در برابر deserialization داده‌های نامطمئن آسیب‌پذیر است. اگر برنامه دیپلوی شده برای استفاده از JMSAppender و JMS Broker مهاجم پیکربندی شده باشد، مهاجم می‌تواند کد را از راه دور روی سرور اجرا کند. توجه داشته باشید که این نقص بر برنامه‌هایی تأثیر می گذارد که به طور خاص برای استفاده از JMSAppender پیکربندی شده‌اند که به طور پیش فرض انجام نمی‌شود. زمانی که مهاجم دسترسی ویرایش پیکربندی Log4j دارد تا JMSAppender را به JMS Broker خود بیفزاید، نیز خطرناک است.
وکتورهای حمله مورد استفاده در اکسپلویت Log4Shell و میتیگیشن‌های گزارش شده در روز جمعه که توسط Snyk.io و کمپین جاوا گزارش شده است، همچنان در حال تکامل هستند؛ بنابراین، بهتر است دائماً در مورد این تهدید هوشیار باشیم. در اقدامات پس از حادثه (که بسیار زیاد هم هستند) حتما باید فعالیت‌هایی برای بهبود کتابخانه‌های نرم‌افزاری، کتابخانه‌های اوپن‌سورس و کتابخانه‌های Dependency گنجانده شود. در ضمن اگر پکیج‌هایی داریم که رفتاری مانند Log4j دارند و بخشی از ورودی‌های خود را وارسی نمی‌کنند، بهتر است تهدیداتی را که ممکن است از این پکیج‌ها ناشی شوند مدل کنیم؛ به خصوص حالا که فهمیده‌ایم چنین رفتاری در یک پکیج نرم‌افزاری می‌تواند چه عواقب سهمگینی به دنبال داشته باشد.
از صفر شروع کنیم؟
آیا این موضوع نشان می دهد که باید کامپایل پکیج‌های جانبی را متوقف کنیم و مثل گذشته خودمان هرچیزی را نیاز داشتیم از صفر بسازیم؟
در همه‌ی حوزه‌های توسعه نرم‌افزار، بحث‌های زیادی درباره استفاده از تعداد زیادی Dependency جانبی وجود داشته و دارد. امسال شاهد تلاش‌های زیادی برای آلوده‌کردن اکوسیستم‌های متعدد، از پایتون گرفته تا جاوا اسکریپت بوده‌ایم و حالا با یک آسیب‌پذیری حیاتی در یکی از اصلی‌ترین و فراگیرترین اجزای جهان فناوری اطلاعات مواجه‌ایم.
از یک سو، اتکا بر کدهایی که در داخل سازمان توسعه می‌دهید (کدهایی که بر اساس ویژگی‌های اصلی زبان برنامه نویسی انتخابی شما ساخته شده است) چندان هم رویکرد بدی نیست. می‌توان استدلال کرد که این مسئله کار مهاجمان را سخت‌تر می‌کند و باعث می‌شود که زحماتشان کمتر نتیجه بدهد.
به هر صورت، احمقانه است که به طور کامل از این جز اساسی، حاضر و آماده و پر از فیچرهای مفید چشم‌پوشی کنیم. و فراموش نکنیم که تمام نرم افزارها شبیه هم ساخته نمی‌شوند. ایده آل این است که نرم افزار ساخته شده و به اشتراک گذاشته شده توسط جامعه، در دستان توانمند بیشتری ورز داده شود و از چشم‌های تیزبین‌تر و فرصتی طولانی‌تر برای بلوغ بهره‌مند شود.
درسی که از نقص Log4Shell می‌گیریم، واضح به نظر می‌رسد: استفاده کنید، اما اعتبارسنجی و پشتیبانی داشته باشید! کتابخانه‌هایی مانند Log4j به خاطر فیچرهای مفیدی که می‌توان به سرعت و به طور مؤثر استفاده کرد، بسیار محبوبند. با این حال، نمی‌توانید فرض کنید که همه چیز در هر اکوسیستمی خوب است و خواهد بود. اگر درخواست اولیه برای افزودن این فیچر نسبتاً احمقانه (اجرای پیام dynamic) بیشتر مورد بررسی قرار می‌گرفت و متخصصین امنیت بیشتری در جریان تأیید بودند، به احتمال زیاد در حال حاضر این پست را نمی‌خواندید.
سازمان‌ها باید همکاری بیشتری داشته باشند، فرایندهای ساخت کد و پشتیبانی را زیر نظر بگیرند و پروژه‌هایی را که به اجزای اساسی یا گسترده در محیط توسعه اپلیکیشنشان تبدیل می‌شوند، بیشتر بررسی کنند.
تأثیر SBOM چیست؟
فهرست مقادیر یا Bill of Materials نوعی inventory یا «لیست دارایی‌ها» است و از نظر مفهومی باید به سرعت بخشیدن به اقدامات اضطراری پاسخ به آسیب‌پذیری، مانند همین ماجرای Log4j که اکنون درگیر آن هستیم، کمک کند.
SBOM به نوعی یک گزارش رسمی است که شامل جزئیات و روابط زنجیره تامین اجزای مختلف نرم افزار است. در این مورد، این اجزا شامل کتابخانه‌های جاوا هستند که برای ورود به سیستم استفاده می‌شوند (مانند Log4j2).
الزامات SBOM در فرمان اجرایی ایالات متحده صادر شده در ماه مه 2021 گنجانده شده است. اگرچه الزامات بین‌المللی نیز وجود دارد، ما برای سادگی الزامات امریکایی را آورده‌ایم.
منبع: The Minimum Elements For a Software Bill of Materials (SBOM) ، صادر شده از وزارت بازرگانی، با هماهنگی اداره ملی مخابرات و اطلاعات (NTIA)، 12 ژوئیه 2021.
| زمینه‌ی اطلاعات | توضیحات |
| نام تأمین‌کننده | نام نهادی که کامپوننت‌ها را به وجود آورده، تعریف کرده و شناسایی می‌کند. |
| نام جزء یا کامپوننت | نام اختصاص داده شده به واحد نرم افزاری که توسط تأمین‌کننده اصلی تعریف شده است. |
| نسخه‌ی کامپوننت | شاخصی که توسط تأمین‌کننده برای مشخص کردن تغییر در نرم افزار نسبت به نسخه شناسایی شده قبلی استفاده می‌شود. |
| مشخصه‌های منحصربه‌فرد دیگر | مشخصه‌های دیگری که برای شناسایی یک کامپوننت استفاده می‌شوند یا به عنوان کلید جستجو برای دیتابیس مربوطه عمل می‌کنند. |
| رابطه‌ی Dependency | توصیف رابطه‌ای که یک کامپوننت بالادستی x در نرم‌افزار y گنجانده شده است. |
| نویسنده اطلاعات SBOM | نام نهادی که داده‌های SBOM را برای این کامپوننت ایجاد می‌کند. |
| ثبت زمانی | رکورد تاریخ و زمان جمع‌آوری داده‌های SBOM |
سؤالی که ذهن بسیاری از مقابله‌کنندگان با log4shell، منجمله CISO ها، توسعه‌دهندگان، مهندسان، ادمین‌های سیستم و مشتریان را مشغول کرده، این است که ورژن‌های آسیب‌دیده‌ی Log4j، در کجای اکوسیستم فنی‌شان مورد استفاده هستند. از آنجایی که محیط‌های فنی پیچیده‌تر، درهم‌تنیده‌تر و گسترده‌تر شده‌اند، نگهداری از موجودی دقیق دارایی‌ها بسیار چالش‌برانگیز شده‌است. اتکای روزافزون ما به فناوری‌های متصل به اینترنت و ظهور shadow IT مشکل را از این پیچیده‌تر نیز می‌کنند.
آسیب‌پذیری در ابزارهایی مانند Log4j که به‌طور گسترده در فن‌آوری‌ها و سیستم‌ها به کار گرفته می‌شود، نیاز به شفافیت بیشتر و به کارگیری اتوماسیون در زمینه مدیریت موجودی‌ها و دارایی را برجسته می‌کند. شاید از تاثیرات اساسی و بلندمدت Log4Shell این باشد که تمرکز سرمایه‌گذاری‌ها تغییر کند و وجود فهرستی از نرم‌افزارها و کامپوننت‌ها با SBOM که به راحتی قابل جست‌وجو باشد، بیش از پیش ضرورت یابد.
مخلص کلام این است که اگر ما در شرایطی زندگی می‌کردیم که SBOMها برای تمام پروژه‌های نرم‌افزاری یک امر ضروری بود و در روند آنها پیش‌بینی می‌شد، شناسایی محصولات، دستگاه‌ها و اکوسیستم‌های آسیب‌دیده بسیار آسان‌تر از تجربه‌ی فعلی Log4Shell می‌شد و احتمالاً اصلاحات مورد نظر سریع‌تر و موثرتر اتفاق می‌افتاد.
تأثیر Log4Shell بر مقررات چیست؟
چگونه Log4Shell بر وضعیت قانون‌گذاری سازمان‌ها تأثیر می گذارد؟ آیا باید برای مطابقت با مقررات نظارتی اقدام خاصی انجام دهیم؟
به گفته Harley Geiger، کارشناس سیاست‌گذاری و خط مشی Rapid7:
«ممکن است نهادهای نظارتی وقوع Log4Shell را پیش‌بینی نکرده باشند، اما حالا که این آسیب‌پذیری کشف شده است، انتظار می‌رود شرکت‌های تحت نظارت آن را برطرف کنند. از آنجایی که برنامه‌های امنیتی سازمان‌ها به این آسیب‌پذیری گسترده و جدی رسیدگی می‌کنند، اقداماتشان باید با شرایط و گزارش‌ها مطابقت داشته باشند. برای بسیاری از شرکت‌های تحت نظارت، کشف Log4Shell اقداماتی مانند ارزیابی مجدد ریسک‌های شرکت، اثربخشی تدابیر امنیتی آنها برای محافظت از سیستم‌ها و اطلاعات حساس (از جمله پچ به آخرین نسخه)، و آمادگی فرآیندهای واکنش به حادثه را برای اکسپلویت احتمالی Log4j ضروری می‌کند. بسیاری از مقررات نیز این تعهدات را برای ارائه‌دهندگان خدمات الزامی می‌کنند. اگر اکسپلویت Log4j منجر به اختلال قابل توجه در کسب و کار یا نقض اطلاعات شخصی شود، احتمالاً نهادهای نظارتی شرکت‌ها را ملزم به صدور گزارش حادثه یا اعلان نقض کنند.»
از هارلی پرسیدیم که آیا احتمال دارد شاهد اقدامی در سطح سیاست عمومی باشیم. او در پاسخ بیان کرد:
«در سطح سیاست فدرال، سازمان‌ها باید منتظر فشار مجدد برای پذیرش SBOM برای کمک به شناسایی Log4j(و سایر آسیب‌پذیری‌ها) در محصولات و محیط‌ها در آینده باشند.سازمان CISA سازمان‌های فدرال را ملزم به تسریع کاهش صدماتLog4j کرده و اطلاعات مربوط به این آسیب‌پذیری را به سرعت منتشر نموده است. این زنجیره از حوادث ممکن است به موج ارائه شدن قوانین «گزارش حوادث سایبری» که در حال حاضر در کنگره مورد بحث هستند، شدت ببخشد.
تمام این چیزها را از کجا دریافته‌ایم؟
خب، یک مشت بچه شروع به ویران کردن سرورهای Minecraft کردند و از آن نقطه همه چیز به سرازیری افتاد. در حالی که حقیقتی در این ادعا وجود دارد، واقعیت این است که این مشکل در اواخر نوامبر سال ۲۰۲۱ بر روی پروژه Log4j فایل شد. کد proof of concept در اوایل دسامبر منتشر شد و حملات فعال پس از آن اتفاق افتاد. برخی از وندورهای امنیت سایبری شواهدی در اختیار دارند که نشان می‌دهد حملات مقدماتی از اول دسامبر سال ۲۰۲۱ آغاز شدند.
البته هر کسی که پی‌گیر مباحث مرتبط بوده باشد (چیزی که هم توسعه دهندگان، مدافعان و هم مهاجمان به‌طور منظم انجام می‌دهند) متوجه گپی که فیچر مذکور دلیلش بود، شده‌اند.
از کی این مشکل را داریم؟
شواهدی مبنی بر درخواست اضافه شدن این عملکرد در سال ۲۰۱۳ وجود دارد. در یک سخنرانی در بلک هت ۲۰۱۶ آمریکا به وکتورهای اجرای کد از راه دور برای تزریق JNDI اشاره شد، ولی مستقیماً صحبتی از Log4j به میان نیامد.
برخی از PoC هایی که نقطه ضعف JNDI Lookup در Log4j 2.x را هدف قرار می‌دهند هم در مارس ۲۰۲۱ کشف شدند.
امروز شاهد همه‌گیری استراتژی ارعاب، عدم قطعیت و تردید (FUD) هستیم و احتمالاً در هفته‌ها و ماه‌های آینده نیز باقی خواهد ماند. در حالی که اتخاذ یک رویکرد «assumed breach» برای هر آسیب‌پذیری معروفی مناسب نیست، گستردگی و وابستگی مجازی (transitive dependency) کتابخانه Log4j، در کنار تکنیک‌های پیچیده و پنهان اکسپلویت که در حال حاضر شاهد هستیم، نشان می‌دهد که نباید بپرسیم «چه مدت است که این مشکل را داریم؟» بلکه باید پرسید «چقدر زمان برای آماده‌سازی ذهنی خودمان (و تطبیق انتظارات) برای اصلاح نیاز داریم؟»
آیا به‌روزرسانی کافی است؟
شنیده‌ام که به‌روزرسانی کار نمی‌کند و حتی اگر به‌روزرسانی کرده باشید هم مورد اکسپلویت قرار می‌گیرید. آیا ترس من به جاست؟
اگر به نسخه ۲٫۱۵ (فیکس اورجینال) یا نسخه ۲٫۱۶ آپدیت کرده‌اید (آخرین فیکس)، لازم نیست وحشت کنید. درست است که به‌روزرسانی نسخه ۲٫۱۵ «برای برخی پیکربندی‌های غیرپیش‌فرض ناقص بود» که آن هم به‌عنوان یک آسیب‌پذیری جداگانه با شناسه CVE-2021-45046 شناسایی شد، اما به این کلمات کلیدی توجه کنید: «برای برخی پیکربندی‌های غیرپیش‌فرض».
اساساً، هنگامی که یک پیکربندی ورود به سیستم از یک Pattern Layout غیر پیش‌فرض با Context Lookup استفاده می‌کند، هکرهایی که کنترل داده‌های ورودی Thread Context Map (MDC) را داشته باشند، می‌توانند با استفاده از JNDI Lookup داده‌های ورودی مخرب تولید کنند. این اتفاق می‌تواند به حملات DoS ختم شود. ما اکنون می‌دانیم که می‌تواند منجر به نشت اطلاعات و در برخی موارد خاص RCE هم شود. به همین علت، امتیاز این آسیب‌پذیری در وبسایت بنیاد آپاچی از ۳٫۷ به ۹٫۰ ارتقاء پیدا کرد.
اما RCE در حال حاضر فقط در mac OS گزارش شده‌است و هیچ اکسپلویتی نیز از سوی گروه‌های متفرقه گزارش نشده‌است، بنابراین هنوز زمان وحشت کردن نیست. نکته اصلی این است که شما باید در اسرع وقت به نسخه ۲٫۱۶ به روز رسانی کنید، اما اگر از تنظیمات غیرپیش‌فرض استفاده نمی‌کنید، نسخه ۲٫۱۵ هم احتمالاً شما را پوشش خواهد داد.
حملات باج‌افزاری و log4shell
شنیده‌ام که حملات باج افزاری علیه این آسیب‌پذیری رخ داده است. باید وحشت کنم؟
درست است که در گزارش‌هایی گروه باج‌افزار Conti از CVE-2021-44228 (Log4Shell) برای انجام حملات استفاده کرده است. طبق گزارشی ازAdvIntel گروه Conti با هدف قرار دادن نمونه‌های آسیب‌پذیر Log4j2 در حال آزمایش اکسپلویتی در VMware vCenter است. در این گزارش آمده است که اکسپلویت مورد نظر «برای حمله حرکت عرضی (lateral movement) مستقیم از شبکه آسیب‌دیده است که دسترسی به vCenter را فراهم آورده و تمام شبکه‌های قربانی در ایالات متحده و اروپا را از طریق سشن‌های از پیش موجود Cobalt Strike تحت تأثیر قرار می‌دهد». بابت این موضوع نباید وحشت کرد، اما ممکن است در هفته‌های آینده شاهد اکسپلویت‌های باج‌افزاری بسیار گسترده‌تر باشیم، و این دلیل دیگری است برای اینکه باید در اسرع وقت به آخرین نسخه (نسخه ۲٫۱۶) بروزرسانی کنید.
چالش قوانین ضدهک در امریکا
آیا اسکن کردن برنامه‌ها یا سیستم‌های آسیب‌پذیر بلامشکل است؟
اگر صاحب یا اجاره‌کننده سیستم هستید و مجوز دارید، اسکن کردن برای شناسایی برنامه‌ها یا سیستم‌های آسیب‌پذیر گامی درست است – در واقع، ما قویاً توصیه می‌کنیم این کار را انجام دهید تا بتوانید پچ کنید.
علاوه بر این، در حالی که قوانین در کشورهای مختلف متفاوت هستند، اغلب قوانین ضد هک حول محور عدم تجاوز از سطح دسترسی مجاز یا دسترسی به سیستم‌های بدون مجوز است، بنابراین اسکن دارایی‌های شخص دیگری بدون مجوز ممکن است مغایر قانون باشد.
هارلی گایگر، قانون Computer Fraud and Abuse Act (CFAA) از قوانین ضدهک ایالات متحده را در توییتی توضیح می‌دهد:
«اگر تست شما شامل نشت غیرمجاز داده‌های غیرعمومی از سیستم هدف باشد یا باعث شود سیستم هدف، کد اجرایی شما را بدون مجوز دانلود کند، حتی اگر این کار با حسن نیت انجام شده باشد، باید دست نگهدارید و برای خود وکیل بگیرید».
