Een paar weken geleden zette het nieuws over de beveiligingsproblemen van Log4j veel gebruikers op het netwerk op zijn kop en het is dat het een van de fouten is die het meest is uitgebuit en die veel experts hebben bestempeld als "de gevaarlijkste in een lange tijd », Van de kwetsbaarheden die in het netwerk bekend zijn gemaakt, hebben we het over enkele hier op de blog en deze keer hebben we het nieuws van een ander gevonden.
En dat is het een paar dagen geleden het nieuws werd vrijgegeven dat er een andere kwetsbaarheid is geïdentificeerd in de Log4j 2-bibliotheek (die al wordt vermeld onder CVE-2021-45105) en die, in tegenstelling tot de vorige twee problemen, werd geclassificeerd als gevaarlijk, maar niet kritiek.
Het nieuwe probleem staat een denial of service toe en manifesteert zich in de vorm van lussen en abnormale beëindigingen bij het verwerken van bepaalde regels.
Kwetsbaarheid beïnvloedt systemen die context zoeken gebruiken, zoals $ {ctx: var}, om het uitvoerformaat van het logbestand te bepalen.
De Log4j-versies 2.0-alpha1 tot 2.16.0 misten bescherming tegen ongecontroleerde recursie, wat stond een aanvaller toe de waarde te manipuleren die werd gebruikt bij vervanging om een eindeloze lus te veroorzaken die te weinig ruimte op de stapel zou hebben en ervoor zou zorgen dat het proces zou blijven hangen. Het probleem deed zich met name voor bij het vervangen van waarden zoals "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Bovendien heeft Opgemerkt kan worden dat Blumira-onderzoekers een aanval op kwetsbare Java-applicaties hebben voorgesteld die geen verzoeken accepteren van externe netwerken, bijvoorbeeld systemen van ontwikkelaars of gebruikers van Java-applicaties, kunnen op deze manier worden aangevallen.
De essentie van de methode is dat als er kwetsbare Java-processen zijn op het systeem van de gebruiker die alleen netwerkverbindingen accepteren van de lokale host (localhost), of RMI-verzoeken verwerken (Remote Method Invocation, poort 1099), de aanval kan worden uitgevoerd door uitgevoerde JavaScript-code wanneer de gebruiker een schadelijke pagina in de browser opent. Om bij een dergelijke aanval verbinding te maken met de netwerkpoort van een Java-toepassing, wordt de WebSocket API gebruikt, waarop, in tegenstelling tot HTTP-verzoeken, geen beperkingen van dezelfde oorsprong worden toegepast (WebSocket kan ook worden gebruikt om netwerkpoorten op de lokale host om beschikbare netwerkstuurprogramma's te bepalen).
De resultaten van de evaluatie van de kwetsbaarheid van de bibliotheken die verband houden met afhankelijkheden met Log4j, gepubliceerd door Google, zijn ook interessant. Volgens Google treft het probleem 8% van alle pakketten in de Maven Central-repository.
Met name 35863 Log4j-gerelateerde Java-pakketten met directe en indirecte afhankelijkheden werden blootgesteld aan kwetsbaarheden. Op zijn beurt wordt Log4j slechts in 17% van de gevallen gebruikt als een directe afhankelijkheid van het eerste niveau, en in 83% van de pakketten die onder de kwetsbaarheid vallen, wordt de binding gedaan via tussenliggende pakketten die afhankelijk zijn van Log4j, dat wil zeggen. afhankelijkheden van het tweede en hoogste niveau (21% - het tweede niveau, 12% - het derde, 14% - het vierde, 26% - het vijfde, 6% - de zesde).
Het hersteltempo van de kwetsbaarheid laat nog steeds veel te wensen over, een week nadat de kwetsbaarheid werd geïdentificeerd, van de 35863 geïdentificeerde pakketten, is het probleem tot nu toe slechts in 4620 opgelost, dat wil zeggen 13%.
Wijzigingen in pakketten zijn nodig om de afhankelijkheidsvereisten bij te werken en oude versiebindingen te vervangen door vaste versies van Log4j 2 (Java-pakketten oefenen binding met een specifieke versie en niet met een open bereik dat installatie van de nieuwste versie mogelijk maakt).
Het elimineren van de kwetsbaarheid in Java-applicaties wordt bemoeilijkt door het feit dat programma's vaak een kopie van de bibliotheken bij de levering bevatten, en het is niet voldoende om de Log4j 2-versie in de systeempakketten bij te werken.
Ondertussen heeft het U.S. Agency for Infrastructure Protection and Cybersecurity een noodrichtlijn uitgevaardigd die federale agentschappen verplicht om vóór 4 december informatiesystemen te identificeren die getroffen zijn door de Log23j-kwetsbaarheid en updates te installeren die het probleem blokkeren.
Daarentegen is tot 28 december een richtlijn gegeven waarin de organisaties de plicht hadden om te rapporteren over de uitgevoerde werkzaamheden. Om de identificatie van problematische systemen te vereenvoudigen, is een lijst met producten opgesteld waarin de manifestatie van een kwetsbaarheid is bevestigd (er zijn meer dan 23 duizend toepassingen in de lijst).
Tenslotte Het is vermeldenswaard dat de kwetsbaarheid is verholpen in Log4j 2.17 die een paar dagen geleden is gepubliceerd en gebruikers die de updates hebben uitgeschakeld, wordt aangeraden de bijbehorende update uit te voeren, naast het feit dat het gevaar van de kwetsbaarheid wordt verzacht door het feit dat het probleem zich alleen manifesteert op systemen met Java 8.
bron: https://logging.apache.org/