Log4Shell، یک آسیبپذیری اینترنتی، اخیراً میلیونها دستگاه را تحت تأثیر قرار داده است. Log4j، یک نرم افزار مبهم و در عین حال تقریباً فراگیر، باعث ایجاد آن می شود.
Log4j برای ثبت تمام اقداماتی که در پشت صحنه در انواع سیستم های کامپیوتری رخ می دهد استفاده می شود.
این بر اساس یک کتابخانه ورود به سیستم منبع باز است که توسط مشاغل و حتی سازمان های دولتی در اکثر برنامه ها استفاده می شود.
به عنوان یکی از بدترین حفره های امنیتی سایبری که تاکنون کشف شده است، محافظت از سیستم های خود در برابر این آسیب پذیری بسیار مهم است. اما، چگونه؟
بیایید آسیب پذیری Log4j را با جزئیات بررسی کنیم و همه راه حل های ممکن برای رفع آن را بررسی کنیم.
Log4j چیست؟
Log4j یک است منبع باز چارچوب ورود به سیستم که توسعه دهندگان نرم افزار را قادر می سازد تا داده های مختلف را در برنامه های خود ثبت کنند. این جزء پروژه Apache Logging Services است که توسط Apache Software Foundation.
صدها وب سایت و برنامه از Log4j برای انجام عملیات حیاتی مانند ثبت داده ها برای اشکال زدایی و سایر کاربردها استفاده می کنند.
هنگامی که یک لینک آنلاین ضعیف را وارد می کنید یا روی آن کلیک می کنید و یک اخطار خطای 404 دریافت می کنید، این یک مثال متداول از Log4j در محل کار است. وب سروری که دامنه پیوند وب را اجرا می کند که سعی کردید به آن دسترسی پیدا کنید، به شما اطلاع می دهد که چنین صفحه وب وجود ندارد. همچنین رویداد را در Log4j برای مدیران سیستم سرور ثبت می کند.
در سراسر برنامه های نرم افزاری، سیگنال های تشخیصی مشابهی استفاده می شود. به عنوان مثال، در بازی آنلاین Minecraft، سرور از Log4j برای ثبت فعالیت هایی مانند کل RAM استفاده شده و دستورالعمل های کاربر ارسال شده به کنسول استفاده می کند.
آسیب پذیری چگونه رخ می دهد؟
جستجوها یک ویژگی جدید معرفی شده در Log4j 2.0 است که به گنجاندن اطلاعات اضافی در ورودیهای گزارش کمک میکند. یکی از این جستجوها جستجوی JNDI (نامگذاری جاوا و رابط دایرکتوری) است که یک API جاوا برای برقراری ارتباط با یک سرویس دایرکتوری است.
با استفاده از این رویکرد، شناسههای کاربر داخلی را میتوان به نامهای کاربری واقعی نگاشت. این پرس و جو آسیب پذیری RCE تازه کشف شده را آشکار می کند، زیرا یکی از انواع داده های ارائه شده توسط سرور LDAP یک URI است که به کلاس جاوا اشاره می کند، که سپس در حافظه بارگذاری می شود و توسط نمونه Log4j اجرا می شود.
به دلیل ضعف در اعتبارسنجی ورودی کتابخانه Log4j، امکان تزریق یک سرور LDAP دلخواه از یک منبع نامعتبر وجود دارد. از آنجایی که توسعهدهندگان فرض میکنند که دادههای ارسال شده به گزارشها به صورت متن ساده مدیریت میشوند، هیچ اعتبار ورودی اضافی انجام نمیشود و ورودی خطرناک کاربر وارد گزارشها میشود.
یک دستور log ممکن است به شکل زیر باشد:
یک کاربر مخرب اکنون جستجوی JNDI را با اشاره به یک سرور LDAP سرکش در پارامتر URL وارد می کند. جستجوی JNDI به شرح زیر است:
کتابخانه Log4j سپس با این سرور LDAP در attacker.com صحبت می کند تا اطلاعات دایرکتوری، از جمله مقادیر برای Java Factory و Java Codebase را دریافت کند.
این دو مقدار شامل کلاس جاوا مهاجم است که سپس در حافظه بارگذاری شده و توسط نمونه Log4j اجرا می شود و اجرای کد را تکمیل می کند.
چه کسی در معرض خطر است؟
آسیب پذیری Log4j فوق العاده گسترده است و بر برنامه های کاربردی تجاری، دستگاه های تعبیه شده و زیرسیستم های آنها تأثیر می گذارد. برنامههای تحت تأثیر سیسکو Webex، Minecraft و FileZilla FTP هستند.
با این حال، این به هیچ وجه یک لیست کامل نیست. این نقص حتی بر ماموریت هلی کوپتر Ingenuity Mars 2020 که از Apache Log4j برای ضبط رویداد استفاده می کند، تأثیر می گذارد.
جامعه امنیتی یک را تدوین کرده است لیست سیستم های آسیب پذیر. بسیار مهم است که توجه داشته باشید که این لیست ها به طور مداوم به روز می شوند، بنابراین اگر برنامه یا سیستم خاصی نمایش داده نمی شود، تصور نکنید که تحت تأثیر قرار نگرفته است.
قرار گرفتن در معرض این آسیب پذیری کاملاً محتمل است و حتی اگر خاص باشد پشته فنی جاوا را اعمال نمی کند، مدیران امنیتی باید از سیستم های تامین کننده حیاتی، تامین کنندگان SaaS، ارائه دهندگان میزبانی ابری و ارائه دهندگان وب سرور انتظار داشته باشند که این کار را انجام دهند.
چگونه آسیب پذیری Log4j را بررسی کنیم؟
اولین قدم این است که مشخص شود آیا حمله قبلاً رخ داده است یا خیر. شما می توانید این کار را با بررسی گزارش های سیستم برای قطعات محموله RCE انجام دهید.
اگر جستجو برای عباراتی مانند "jndi"، "ldap"، یا "$::" هر گونه گزارشی را به دست آورد، محققان امنیتی باید بیشتر بررسی کنند تا ببینند آیا این یک حمله قانونی بوده یا صرفاً اثر انگشت بوده است.
بسیاری از حملات در طبیعت کشف شد که هیچ محموله مضری را تحویل ندادند. با این وجود، آنها توسط کارشناسان امنیتی انجام شد تا مشخص شود چه تعداد اپلیکیشن در برابر این حمله آسیبپذیر هستند.
قدم بعدی استفاده از کتابخانه Log4j برای شناسایی تمامی پروژه ها است. اگر از نسخه های بین 2.0-beta9 و 2.14.1 استفاده شود، پروژه می تواند آسیب پذیر باشد.
با توجه به دشواری تعیین محل وجود این آسیب پذیری، می توان ترجیح داد که پروژه را مستعد فرض کنیم و اینکه به روز رسانی کتابخانه بهترین اقدام برای حذف خطر اجرای کد است.
اگر نسخه استفاده شده کمتر از 2.0-بتا 9 باشد، پروژه آسیب پذیر نیست، اگرچه کتابخانه Log4j همچنان باید ارتقا یابد زیرا نسخه های در محدوده 1.x قدیمی هستند و دیگر به روز رسانی نمی شوند.
اگر پروژه حساسی کشف شود، توصیه میشود که بررسی شود تا ببینیم آیا اطلاعات ثبتشده با استفاده از Log4j حاوی اطلاعاتی است که کاربر میتواند تغییر دهد. URL ها، پارامترهای درخواست، سرصفحه ها و کوکی ها نمونه هایی از این داده ها هستند. اگر یکی از این موارد ثبت شود، پروژه در خطر است.
این دانش می تواند به شما کمک کند تا بیشتر در لاگ های سیستم جستجو کنید و تعیین کنید که آیا برنامه وب شما قبلاً مورد حمله قرار گرفته است یا خیر.
ابزارهای آنلاین رایگانی وجود دارند که می توانند آسیب پذیر بودن یک برنامه وب را تشخیص دهند. یکی از این برنامه ها می باشد شکارچی Log4Shell. منبع باز است و در دسترس است GitHub.
اگر یک ناحیه آسیب پذیر از کد در برنامه آنلاین کشف شود، می توان از محموله ارائه شده توسط ابزار فاش شده برای تزریق آن به برنامه وب استفاده کرد. در صورت سوء استفاده از این آسیبپذیری، ابزار تست، اتصالات ایجاد شده بین برنامه وب و سرور LDAP آنها را نشان میدهد.
راه حل هایی برای رفع آسیب پذیری Log4j
اولین مرحله به روز رسانی Log4j است که می توانید با استفاده از پکیج منیجرهای معمولی یا با دانلود مستقیم آن از این برنامه انجام دهید. با ما.
همچنین می توان با تنظیم متغیر محیطی FORMAT MSG NO LOOKUPS بر روی true، قابلیت بهره برداری آسیب پذیری را کاهش داد. با این حال، این اقدام متقابل فقط برای نسخههای Log4j بزرگتر یا مساوی 2.10 قابل اعمال است.
اجازه دهید اکنون گزینه های جایگزین را در نظر بگیریم.
1. راه حل برای Log4j نسخه 2.17.0
قطعاً توصیه می شود که از Log4j نسخه 2.15.0 برای محافظت در برابر Log4Shell استفاده کنید، اما اگر این امکان پذیر نیست، راه حل های دیگری در دسترس هستند.
نسخه های 2.7.0 و جدیدتر Log4j: محافظت در برابر هرگونه حمله با تغییر قالب رویدادهایی که باید با استفاده از نحو درصد m nolookups برای داده های ارائه شده توسط کاربر ثبت شوند، امکان پذیر است. این به روز رسانی نیاز به ویرایش فایل پیکربندی Log4j برای تولید نسخه جدیدی از برنامه دارد. در نتیجه، قبل از استقرار این نسخه جدید، مراحل اعتبار سنجی فنی و عملکردی باید تکرار شود.
Log4j نسخه 2.10.0 و جدیدتر: همچنین میتوان با تنظیم پارامتر پیکربندی log4j2.formatMsgNoLookups روی true، در برابر هرگونه حمله محافظت کرد، برای مثال، هنگام راهاندازی ماشین مجازی جاوا با گزینه -Dlog4j2. formatMsgNoLookups = true، گزینه دیگر حذف کلاس JndiLookup از آرگومان classpath است که بردار حمله اصلی را حذف می کند (محققان احتمال وجود بردار حمله دیگری را رد نمی کنند).
خدمات وب آمازون یک هاتپچ ارائه میکند که «باید با مسئولیت خودتان از آن استفاده کنید». «تکنیکهای» دیگری مانند Logout4Shell که «از این آسیبپذیری علیه خود استفاده میکند» منتشر شدهاند. این کارشناس امنیتی قانونی بودن این اقدام را که شامل "هک کردن یک ماشین برای تعمیر آن" است، زیر سوال می برد.
2. مشکل در Log4j v2.17.0 حل شده است.
برای نسخه های بزرگتر از 2.10: Log4j2.formatMsgNoLookups باید روی true تنظیم شود.
برای نسخه های 2.0 تا 2.10.0: دستور زیر را برای حذف کلاس LDAP از Log4j اجرا کنید.
Log4j2.formatMsgNoLookups باید در تنظیمات سیستم روی true تنظیم شود.
کاهش در JVM
کاهش با پارامترهای JVM دیگر یک گزینه نیست. سایر روش های کاهش دهنده همچنان موفق هستند. در صورت امکان به Log4j نسخه 2.17.0 ارتقا دهید. یک راهنمای مهاجرت برای Log4j v1 موجود است.
اگر به روز رسانی امکان پذیر نیست، مطمئن شوید که اجزای سمت سرویس گیرنده و سمت سرور دارای -Dlog4j2.formatMsgNoLookups = مجموعه ویژگی سیستم واقعی هستند.
لطفاً توجه داشته باشید که Log4j v1 به پایان عمر خود (EOL) رسیده است و دیگر رفع اشکال دریافت نخواهد کرد. سایر بردارهای RCE نیز به Log4j v1 حساس هستند. از این رو، ما از شما می خواهیم که در اسرع وقت به Log4j 2.17.0 ارتقا دهید.
3. اقدامات کاهشی
اکسپلویتهای فعلی نمیتوانند کار کنند حتی اگر Log4j در برخی موارد حساس باشد، مثلاً اگر دستگاه میزبان یک نسخه جاوا بالاتر از 6u212، 7u202، 8u192 یا 11.0.2 را اجرا کند.
این به دلیل حفاظت بهتر بارگذاری کلاس از راه دور نامگذاری جاوا و رابط دایرکتوری (JNDI) در نسخه های فعلی است که برای عملیات حمله ضروری است.
علاوه بر این، با نسخههای Log4j بزرگتر از 2.10، میتوان با تنظیم مقدار سیستم formatMsgNoLookups روی true، ارائه آرگومان JVM -Dlog4j2.formatMsgNoLookups = true، یا حذف کلاس JndiLookup از مسیر کلاس، از این مشکل جلوگیری کرد.
در همین حال، تا زمانی که موارد آسیبپذیر برطرف نشدهاند، میتوان با استفاده از تکنیکهای زیر آسیبپذیری را برطرف کرد:
- ویژگی سیستم log4j2.formatMsgNoLookups را برای >=2.10 روی true تنظیم کنید.
- گزینه محیطی LOG4J FORMAT MSG NO LOOKUPS را برای >=2.10 روی true تنظیم کنید.
- JndiLookup.class را از classpath برای نسخه 2.0-beta9 تا 2.10.0 حذف کنید: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
یکی از بهترین روش های توصیه شده این است که ترافیک خروجی به اینترنت را فقط به پورت های مناسب محدود کنید.
اگرچه بیشتر حملات در این زمینه از طریق HTTP انجام می شود، این آسیب پذیری ممکن است از طریق هر پروتکلی که داده های ورودی کاربر را با استفاده از Log4j ثبت می کند مورد سوء استفاده قرار گیرد.
با این حال، به روز رسانی به log4j 2.17.0 بهترین راه حل است زیرا کسی می تواند یک رویکرد اضافی برای این مشکل پیدا کند. علاوه بر این، بسیاری از ناشران و تولیدکنندگان بهبودهایی را در خدمات یا برنامه های خود اعلام کرده اند.
4. وصله آسیب پذیری Log4Shell
Log4j در همه جا حاضر است، به خصوص اکنون که این آسیب پذیری مورد سوء استفاده قرار می گیرد. به طور خلاصه، تنها کاری که باید انجام دهید این است که کاراکترهای زیر را در لاگ های بررسی شده توسط Log4j قرار دهید.
و با این کار فایل جاوا که در انتهای URL قرار دارد دانلود و اجرا می شود. به همان اندازه که سرراست و دراماتیک است.
همانطور که می دانید، برای رفع این آسیب پذیری Log4Shell (CVE-2.17.0-4) ضروری است که log2021j را به نسخه >= 44228 ارتقا دهید.
اگر این امکان پذیر نیست:
برای برنامههایی که از کتابخانه Log4j نسخههای 2.10.0 و جدیدتر استفاده میکنند، میتوان با تنظیم پارامتر پیکربندی log4j2.formatMsgNoLookups روی true، در برابر هر گونه حمله محافظت کرد، برای مثال، در حالی که ماشین مجازی جاوا را با -Dlog4j2.formatMsgNoLookups = true راهاندازی میکند. گزینه.
گزینه دیگر حذف کلاس JndiLookup از آرگومان classpath است که بردار حمله اولیه را حذف می کند (محققان وجود بردار حمله دیگری را رد نمی کنند).
توجه داشته باشید
سازمانهایی که مردد هستند یا تمایلی به ایجاد تنظیمات در سیستمهای حساس ندارند (یا میخواهند محافظهای بیشتری را نصب کنند) باید به این موارد فکر کنند:
- اطمینان حاصل کنید که تمام ترافیک از طریق iSensor/ هدایت می شودWAF/IPS. این می تواند مانع از دسترسی حمله به سیستم شود.
- محدود کردن میزان ترافیکی که می تواند به سیستم حساس برسد اگر سیستم نیازی به اتصال به اینترنت ندارد، دسترسی به IPS و محدوده های ضروری و قابل اعتماد را محدود کنید.
- کاهش ترافیک خروجی مجاز میزبان. از آنجایی که این حمله با اتصال به یک سرور سرکش عمل می کند، تمام آدرس های IP اضافی و پورت ها باید روی یک فایروال مسدود شوند.
- اگر سرویس دیگر مورد نیاز نیست، باید تا زمانی که یک تعمیر آماده شود، غیرفعال شود.
نتیجه
نقص های Log4j جامعه ما را شوکه کرد و به همه ما یادآوری کرد که چقدر به نرم افزار منبع باز وابسته هستیم.
Log4j منحصر به فرد است. نه سیستم عامل است، نه مرورگر و نه نرم افزار. در عوض، این چیزی است که برنامه نویسان از آن به عنوان یک کتابخانه، یک بسته یا یک ماژول کد یاد می کنند. این فقط یک هدف را دنبال می کند، یعنی ثبت وقایع روی سرور.
افرادی که کد می نویسند ترجیح می دهند روی چیزی که نرم افزارشان را متمایز می کند تمرکز کنند. آنها علاقه ای به اختراع مجدد چرخ ندارند. در نتیجه، آنها به تعداد زیادی از کتابخانه های کد موجود، مانند Log4j، متکی هستند.
ماژول Log4j از آپاچی، پرکاربردترین نرم افزار وب سرور، مشتق شده است. به همین دلیل است که می توان آن را در میلیون ها سرور کشف کرد. از این رو تهدیدات امنیتی را افزایش می دهد.
امیدوارم راه حل های بالا به شما کمک کند تا دستگاه های خود را ایمن نگه دارید.
برای اطلاعات مفیدتر از دنیای فناوری با HashDork همراه باشید.
پاسخ دهید