În biblioteca Log4j 2 a fost descoperită încă o vulnerabilitate (CVE-2021-45105), care, spre deosebire de douăle probleme anterioare, este clasificată ca fiind periculoasă, dar nu critică. Noua problemă permite generarea unei interdicții în serviciu și se manifestă prin looping și opriri neașteptate în timpul procesării anumitor șiruri. Vulnerabilitatea a fost remediate în versiunea Log4j 2.17 publicată cu câteva ore în urmă. Pericolul vulnerabilității este atenuat de faptul că problema apare doar pe sistemele cu Java 8.
Sistemele care utilizează cereri contextuale (Context Lookup) pentru a determina formatul de ieșire în log, cum ar fi ${ctx:var}, sunt expuse la vulnerabilități. În versiunile Log4j, de la 2.0-alpha1 până la 2.16.0, nu exista protecție împotriva recursului necontrolat, ceea ce permitea atacatorului, prin manipularea valorii folosite în substituție, să provoace looping, ceea ce duce la epuizarea memoriei pe stivă și la oprirea neașteptată a procesului. În special, problema apărea la substituirea unor valori precum «${${::-${::-$${::-j}}}}».
De asemenea, cercetătorii de la compania Blumira au propus o variantă de atac împotriva aplicațiilor Java vulnerabile care nu acceptă cereri externe. De exemplu, sistemele dezvoltatorilor sau utilizatorilor de aplicații Java pot fi atacate în acest fel. Esența metodei este aceea că, în condițiile în care pe sistemul utilizatorului există procese Java vulnerabile ce acceptă conexiuni doar de la gazda locală (localhost) sau care procesează cereri RMI (Remote Method Invocation, port 1099), atacul poate fi realizat prin cod JavaScript care este executat când utilizatorul deschide o pagină web malițioasă în browser. Pentru a organiza conexiunea cu portul rețelei aplicației Java în timpul unui astfel de atac, se folosește API WebSocket, care, spre deosebire de cererile HTTP, nu are restricții de aceeași origine (WebSocket poate fi folosit și pentru scanarea porturilor rețelei pe gazda locală pentru a determina handler-ii rețelei disponibili).
De asemenea, rezultatele evaluării vulnerabilităților bibliotecilor legate de Log4j, publicate de compania Google, sunt de interes. Conform datelor Google, problema afectează 8% din toate pachetele din depozitul Maven Central. În particular, 35863 de pachete Java legate de Log4j s-au dovedit a fi vulnerabile, atât prin dependențe directe, cât și indirecte. Astfel, Log4j este utilizat ca dependență directă de prim nivel doar în 17% din cazuri, iar în 83% din pachetele afectate de vulnerabilitate, legătura este realizată prin intermediul pachetelor intermediare care depind de Log4j, adică dependențe de nivelul doi sau mai înalt (21% – de nivel doi, 12% – de nivel trei, 14% – de nivel patru, 26% – de nivel cinci, 6% – de nivel șase). Ritmurile de corectare a vulnerabilității sunt încă nesatisfăcătoare; la o săptămână după descoperirea vulnerabilității, din cele 35863 de pachete identificate, problema a fost rezolvată doar în 4620, adică 13%.
Între timp, Agenția pentru Securitatea Cibernetică și Protecția Infrastructurii din SUA a publicat o directivă de urgență, obligând agențiile federale să identifice systemele informaționale vulnerabile la Log4j și să instaleze actualizări pentru a bloca problema până pe 23 decembrie. Până la 28 decembrie, organizațiile trebuie să raporteze despre progresele realizate. Pentru a facilita identificarea sistemelor problematice, a fost pregătit un listă de produse în care s-a confirmat manifestarea vulnerabilității (lista cuprinde peste 23000 de aplicații).
Sursa: opennet.ro
