För några veckor sedan vände nyheten om Log4j:s säkerhetsproblem upp och ner på många användare på webben och det är en av de mest utnyttjade bristerna och som många experter har stämplat som "den farligaste på länge." sårbarheter som gjordes kända i nätverket, vi pratade om några av dem här på bloggen och vid detta tillfälle har vi hittat nyheten om en annan.
Och det är det för några dagar sedan nyheten kom att en annan sårbarhet identifierades i Log4j 2-biblioteket (som redan är listad under CVE-2021-45105) och som, till skillnad från de två tidigare numren, klassades som farlig, men inte kritisk.
det nya problemet tillåter en denial of service och manifesterar sig i form av loopar och abends vid bearbetning av vissa rader.
Sårbarhet påverkar system som använder kontextsökning, som ${ctx: var}, för att bestämma utdataformatet för loggen.
den Log4j-versioner från 2.0-alpha1 till 2.16.0 saknade skydd mot skenande rekursion, Vad tillät en angripare att manipulera värdet som användes vid substitution för att orsaka en ändlös loop som skulle få slut på stackutrymme och få processen att hänga. I synnerhet uppstod problemet när man bytte ut värden som "${${::-${::-$${::-j}}}}".
Dessutom, Det kan noteras att Blumira-forskare har föreslagit en attack mot sårbara Java-applikationer som inte accepterar förfrågningar från externa nätverk, till exempel utvecklarsystem eller användare av Java-applikationer kan attackeras på detta sätt.
Kärnan i metoden är att om det finns sårbara Java-processer på användarens system som endast accepterar nätverksanslutningar från den lokala värden, eller bearbetar RMI-förfrågningar (Remote Method Invocation, port 1099), attacken kan utföras av exekverad JavaScript-kod när användaren öppnar en skadlig sida i webbläsaren. För att upprätta en anslutning till nätverksporten för en Java-applikation i en sådan attack, används WebSocket API, till vilket, till skillnad från HTTP-förfrågningar, inga restriktioner av samma ursprung gäller (WebSocket kan också användas för att skanna nätverksportar på den lokala värden för att fastställa tillgängliga nätverksdrivrutiner).
Av intresse är också resultaten av utvärderingen av sårbarheten hos biblioteken som är kopplade till beroenden med Log4j som publicerats av Google. Enligt Google påverkar problemet 8 % av alla paket i Maven Central-förvaret.
Särskilt 35863 Log4j-relaterade Java-paket med direkta och indirekta beroenden utsattes för sårbarheter. I sin tur används Log4j som ett direkt beroende av den första nivån endast i 17% av fallen, och i 83% av paketen som täcks av sårbarheten sker bindning genom mellanpaket som är beroende av Log4j, det vill säga. beroenden av den andra och högsta nivån (21% - den andra nivån, 12% - den tredje, 14% - den fjärde, 26% - den femte, 6% - den sjätte).
Takten för att åtgärda sårbarheten lämnar fortfarande mycket att önska, en vecka efter att sårbarheten identifierades, av 35863 identifierade paket, har problemet hittills åtgärdats endast i 4620, det vill säga 13%.
Paketändringar är nödvändiga för att uppdatera beroendekrav och ersätta gamla versionsbindningar med fasta versioner av Log4j 2 (Java-paket övar bindning till en specifik version, inte ett öppet intervall som tillåter installation av den senaste versionen).
Elimineringen av sårbarheten i Java-applikationer försvåras av att program ofta inkluderar en kopia av biblioteken i leveransen, och det räcker inte att uppdatera Log4j 2-versionen i systempaketen.
Samtidigt utfärdade US Agency for Cybersecurity and Infrastructure Protection ett nöddirektiv som kräver att federala myndigheter identifierar informationssystem som påverkas av Log4j-sårbarheten och installerar uppdateringar som blockerar problemet före den 23 december.
Däremot gavs en riktlinje fram till den 28 december där organisationerna hade skyldighet att rapportera om utfört arbete. För att förenkla identifieringen av problematiska system har en lista över produkter där manifestationen av en sårbarhet har bekräftats upprättats (det finns mer än 23 tusen applikationer i listan).
Slutligen, Det är värt att nämna att sårbarheten fixades i Log4j 2.17, som publicerades för några dagar sedan. och användare som har uppdateringar inaktiverade rekommenderas att uppdatera i enlighet med detta, plus att risken för sårbarheten minskas av det faktum att problemet endast visar sig på system med Java 8.
Fuente: https://logging.apache.org/