آسیب پذیری Log4j را فرصت خود قرار دهید

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

در حالی که ما از اینکه جرقه زنی تحت تاثیر قرار نگرفته بودیم، لحظه ای به ما فرصت داد تا در مورد آنچه می توانست باشد فکر کنیم. مانند بسیاری از فروشندگان نرم‌افزار HMI ، ما تمام تلاش خود را می‌کنیم تا مطمئن شویم که پلتفرم‌هایمان تا حد ممکن ایمن هستند، اما صادقانه بگوییم، مواقعی وجود دارد که رویدادهایی مانند Log4j علیرغم تلاش‌های ما ممکن است رخ دهد. هنگامی که آنها اتفاق می افتند، تنها وظیفه فروشنده نیست که بر امنیت تمرکز کند، وظیفه کاربر نهایی نیز هست.

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

 

Log4j چیست و چگونه به آن نزدیک شدیم؟
در 9 دسامبر، موسسه ملی استانداردها و فناوری (NIST) اطلاعیه‌ای را در پایگاه داده آسیب‌پذیری ملی خود (NVD) درباره آسیب‌پذیری روز صفر در رابطه با Log4j، (CVE-2021-44228) منتشر کرد. Log4j یک کتابخانه ثبت جاوای رایج است که در بسیاری از پلتفرم های نرم افزاری امروزی استفاده می شود. اخطار آسیب‌پذیری به طور خاص یک حمله اجرای از راه دور را فراخوانی می‌کند که از کتابخانه Log4j سوء استفاده می‌کند و دارای امتیاز شدت 10 است. اساساً، آسیب‌پذیری Log4j به مهاجمان اجازه دسترسی و کنترل دستگاه‌های متصل را می‌دهد.

دیدگاه توسعه نرم افزار
در لحظه ای که از این مشکل مطلع شدیم، تیم مهندسی نرم افزار ما تأیید کرد که Ignition تحت تأثیر این آسیب پذیری قرار نگرفته است. در این مورد، تأیید نسبتاً ساده بود زیرا هیچ یک از نسخه‌های LTS فعلی Ignition (7.9 و 8.1) از Log4j برای ثبت گزارش استفاده نمی‌کنند. ما از یک کتابخانه متفاوت به نام "Logback" استفاده می کنیم. ما همچنین وابستگی‌های گذرای خود را تجزیه و تحلیل کردیم تا مطمئن شویم که Log4j را بطور اتفاقی با Ignition به عنوان وابستگی به کتابخانه دیگری که استفاده می‌کنیم، بسته‌بندی نکرده‌ایم، و خوشحالیم که متوجه نشدیم. همچنین مهم است که توجه داشته باشید که ما از یک ابزار تجزیه و تحلیل وابستگی خودکار استفاده می کنیم که هر وابستگی (مستقیم یا گذرا) Ignition را که دارای افشای CVE منتشر شده باشد را علامت گذاری می کند تا بتوانیم در اسرع وقت اقدامات متقابل انجام دهیم.

نسخه های قدیمی Ignition (7.8 و بالاتر) از کتابخانه Log4j استفاده می کردند، اما از نسخه قدیمی (1.2) استفاده می کردند که تحت تأثیر این آسیب پذیری قرار نگرفت.

چشم انداز امنیت فناوری اطلاعات/سایبری
تیم امنیت سایبری ما تحقیقاتی موازی در تمام دارایی‌های شرکت برای کشف هرگونه نمونه داخلی Log4j آغاز کرد. با استفاده از مجموعه گسترده ابزارهای امنیتی خود، Github را برای هر نسخه در حال استفاده جستجو کردیم و از اسکنرهای شبکه/آسیب‌پذیری برای شناسایی سرویس‌های تحت تأثیر احتمالی استفاده کردیم. از آنجا، ابزارهای موجودی نرم‌افزار مبتنی بر میزبان را بیشتر جستجو کردیم تا وابستگی‌های پنهانی را که در بسته‌های نرم‌افزاری در غیر این صورت خوش خیم تعبیه شده است، پیدا کنیم. پس از پایان تحقیقات خود، قوانین پیشگیری را در فایروال های شبکه و برنامه های وب خود به کار بردیم تا اسکن انبوهی را که شروع شده بود خنثی کنیم.

بلافاصله پس از انجام مراحل تأیید امنیتی و اصلاح، ما به سرعت یک توصیه فنی در وب سایت خود پست کردیم، اعلان هایی را به لیست پستی خود ارسال کردیم و اعلان را در اخبار هفتگی خود قرار دادیم.

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

 

اگر داستان متفاوت بود چه اتفاقی می افتاد؟
برای اکثر مردم، داستان به همین جا ختم می شود و همه چیز خوب است. اما امنیت هرگز آرام نمی گیرد و همیشه یک آسیب پذیری در سایه ها پنهان خواهد بود. با توجه به اینکه ما در طفره رفتن از این مشکل خاص خوش شانس بودیم، بهتر است عقب نشینی کنیم و یک سوال مهم بپرسیم: اگر Log4j به شدت در Ignition تعبیه شده بود چه؟

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

با توجه به قطارهای رهاسازی سریع ما، احتمالاً می‌توانستیم یک به‌روزرسانی در همان روز در وب‌سایت به شکل یک انتشار شبانه داشته باشیم. به همان اندازه که ممکن است یک وصله یک روزه عالی باشد، انتشار یک پچ از مشتریانی که قادر به نصب آن وصله نیستند محافظت نمی کند، بنابراین این سوال مطرح می شود: آیا مشتریان در موقعیتی هستند که یک پچ اضطراری Ignition را برای یک مشکل نصب کنند.

آیا مورد سوء استفاده قرار گرفته است، آسیب پذیری در طبیعت؟

 

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

دانستن اینکه مشکل امنیتی وجود دارد و راه حلی در دسترس است، یکی از راه‌های تقویت استراتژی امنیتی شماست. همچنین مهم است که مطمئن شوید که این اصلاحات به طور منظم اعمال می شوند.

Patch Gap
در حالی که ما به عنوان یک سازمان می توانیم برای ارائه برتری در امنیت تلاش کنیم، همچنین باید کاربران خود را تشویق و آموزش دهیم که خودشان اقدامات امنیتی را انجام دهند. برای مثال، در حالی که می‌توانیم وصله‌ها را به سرعت منتشر کنیم، برخی از مشتریان ما ممکن است خود را در یک «شکاف وصله» بیابند.

"فاصله وصله" زمان بین کشف یک آسیب پذیری تا زمان استقرار وصله است. مسئولیت ما به انتشار به موقع پچ ختم می شود - این بر عهده مشتری است که آن را در تمام سیستم های خود مستقر کند. قرار گرفتن در موقعیتی برای واکنش سریع به موقعیت هایی مانند این از اهمیت حیاتی برخوردار است.

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

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

کنترل برنامه
هنگامی که نوبت به توقف تهدیدات در حال ظهور و آسیب‌پذیری‌های روز صفر می‌رسد، دو مورد از مهم‌ترین کنترل‌هایی که می‌توان اعمال کرد، فیلتر کردن سخت‌گیرانه خروجی/خروجی در شبکه شما و کنترل دقیق برنامه‌ها بر روی سرورهای شما است. هر دوی این کنترل‌ها بر روی یک رویکرد فهرست مجاز تکیه دارند که در آن فقط اتصالات شبکه از قبل تأیید شده می‌توانند شبکه شما را ترک کنند و فقط نرم‌افزار از پیش تأیید شده می‌تواند روی سرورهای شما اجرا شود.

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

در نهایت، اطمینان از اینکه کاربری که فرآیند Ignition Java را اجرا می‌کند دارای حداقل امتیاز ممکن برای انجام کار خود است، توانایی‌های کاری که مهاجم می‌تواند پس از نقض فرآیند انجام دهد را کاهش می‌دهد. حداقل، در صورت امکان، کاربر نباید به عنوان یک کاربر سیستم یا روت یا کاربر با sudo اجرا شود.

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

نکات کلیدی:
برای به روز ماندن در لیست پشتیبانی جرقه زنی و به روز رسانی محصول ثبت نام کنید.
نصب‌های Ignition خود را مرتباً وصله کنید تا چابک بمانید.
کنترل های امنیتی جبرانی را به عنوان یک شبکه ایمنی مستقر کنید.