În urmă cu câteva săptămâni, știrile despre problemele de securitate ale Log4j dădeau peste cap mulți utilizatori din rețea și este că este unul dintre defectele care a fost exploatat cel mai mult și pe care mulți experți l-au etichetat drept „cel mai periculos într-un mult timp », Dintre vulnerabilitățile care au fost făcute cunoscute în rețea vorbim despre unele dintre ele aici pe blog iar de data aceasta am aflat vestea altuia.
Și este că acum câteva zile a fost lansată știrea că o altă vulnerabilitate a fost identificată în biblioteca Log4j 2 (care este deja listată sub CVE-2021-45105) și care, spre deosebire de cele două numere anterioare, a fost clasificată drept periculoasă, dar nu critică.
Noua problemă permite o refuzare a serviciului și se manifestă sub formă de bucle și terminații anormale la procesarea anumitor linii.
Vulnerabilitate afectează sistemele care utilizează căutarea contextului, cum ar fi $ {ctx: var}, pentru a determina formatul de ieșire a jurnalului.
Las Versiunile Log4j 2.0-alpha1 până la 2.16.0 nu aveau protecție împotriva recursiunii necontrolate, ce a permis unui atacator să manipuleze valoarea utilizată în înlocuire pentru a provoca o buclă nesfârșită care ar rămâne fără spațiu pe stivă și ar cauza blocarea procesului. În special, problema a apărut la înlocuirea unor valori precum „$ {$ {:: - $ {:: - $$ {:: - j}}}}”.
În plus, Se poate observa că cercetătorii Blumira au propus un atac asupra aplicațiilor Java vulnerabile care nu acceptă solicitări de la rețele externe, de exemplu, sistemele dezvoltatorilor sau utilizatorii de aplicații Java pot fi atacate în acest fel.
Esența metodei este că dacă există procese Java vulnerabile pe sistemul utilizatorului care acceptă conexiuni de rețea numai de la gazda locală (localhost) sau procesează cereri RMI (Remote Method Invocation, portul 1099), atacul poate fi efectuat prin cod JavaScript executat atunci când utilizatorul deschide o pagină rău intenționată în browser. Pentru a stabili o conexiune la portul de rețea al unei aplicații Java într-un astfel de atac, se folosește API-ul WebSocket, căruia, spre deosebire de solicitările HTTP, nu i se aplică restricții de aceeași origine (WebSocket poate fi folosit și pentru a scana porturile de rețea pe rețeaua locală). gazdă pentru a determina driverele de rețea disponibile).
De asemenea, sunt de interes rezultatele evaluării vulnerabilității bibliotecilor asociate cu dependențele cu Log4j publicate de Google. Potrivit Google, problema afectează 8% din toate pachetele din depozitul Maven Central.
În special, 35863 de pachete Java legate de Log4j cu dependențe directe și indirecte au fost expuse la vulnerabilități. La rândul său, Log4j este folosit ca dependență directă a primului nivel doar în 17% din cazuri, iar în 83% din pachetele acoperite de vulnerabilitate, legarea se face prin pachete intermediare care depind de Log4j, adică tell. dependențe ale celui de-al doilea și cel mai înalt nivel (21% - al doilea nivel, 12% - al treilea, 14% - al patrulea, 26% - al cincilea, 6% - al șaselea).
Ritmul de reparare a vulnerabilităților mai lasă de dorit, la o săptămână de la identificarea vulnerabilității, din 35863 de pachete identificate, problema a fost remediată până acum doar în 4620, adică la 13%.
Modificările pachetelor sunt necesare pentru a actualiza cerințele de dependență și pentru a înlocui legăturile versiunilor vechi cu versiuni fixe ale Log4j 2 (pachetele Java practică legarea la o anumită versiune și nu la o gamă deschisă care permite instalarea celei mai recente versiuni).
Eliminarea vulnerabilității în aplicațiile Java este împiedicată de faptul că programele includ adesea o copie a bibliotecilor în livrare și nu este suficient să actualizați versiunea Log4j 2 în pachetele de sistem.
Între timp, Agenția SUA pentru Protecția Infrastructurii și Securitate Cibernetică a emis o directivă de urgență prin care le cere agențiilor federale să identifice sistemele de informații afectate de vulnerabilitatea Log4j și să instaleze actualizări care blochează problema înainte de 23 decembrie.
Pe de altă parte, până pe 28 decembrie s-a dat un ghid în care organizațiile aveau obligația de a raporta asupra muncii desfășurate. Pentru a simplifica identificarea sistemelor problematice, a fost pregătită o listă de produse în care a fost confirmată manifestarea unei vulnerabilități (în listă sunt peste 23 de mii de aplicații).
În cele din urmă, De menționat că vulnerabilitatea a fost remediată în Log4j 2.17 care a fost publicat în urmă cu câteva zile iar utilizatorilor care au actualizările dezactivate li se recomandă să efectueze actualizarea corespunzătoare, pe lângă faptul că pericolul vulnerabilității este atenuat de faptul că problema se manifestă doar pe sistemele cu Java 8.
Fuente: https://logging.apache.org/