Prije nekoliko tjedana vijest o sigurnosnim problemima Log4j-a preokrenula je mnoge korisnike na mreži i to je jedan od nedostataka koji se najviše iskorištava i koji su mnogi stručnjaci označili kao "najopasniji u dugo vremena", Od ranjivosti koje su objavljene u mreži govorimo o nekima od njih ovdje na blogu a ovaj put smo pronašli vijest o drugom.
I to prije nekoliko dana objavljena je vijest da je identificirana još jedna ranjivost u biblioteci Log4j 2 (koji je već naveden pod CVE-2021-45105) i koji je, za razliku od prethodna dva problema, klasificiran kao opasan, ali ne i kritičan.
Novi problem dopušta uskraćivanje usluge i očituje se u obliku petlji i abnormalnih završetaka prilikom obrade određenih linija.
Ranjivost utječe na sustave koji koriste pretraživanje konteksta, kao što je $ {ctx: var}, za određivanje izlaznog formata dnevnika.
Las Verzije Log4j od 2.0-alpha1 do 2.16.0 nisu imale zaštitu od nekontrolirane rekurzije, što omogućio napadaču da manipulira vrijednošću korištenom u zamjeni izazvati beskonačnu petlju koja bi ostala bez prostora na stogu i uzrokovala da proces visi. Konkretno, problem se pojavio prilikom zamjene vrijednosti kao što je "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Osim toga, Može se primijetiti da su istraživači Blumire predložili napad na ranjive Java aplikacije koji ne prihvaćaju zahtjeve iz vanjskih mreža, na primjer, sustavi programera ili korisnika Java aplikacija mogu biti napadnuti na ovaj način.
Bit metode je da ako postoje ranjivi Java procesi na sustavu korisnika koji prihvaća mrežne veze samo s lokalnog hosta (localhost) ili obrađuje RMI-zahtjeve (remote Method Invocation, port 1099), napad se može izvesti izvršenim JavaScript kodom kada korisnik otvori zlonamjernu stranicu u pregledniku. Za uspostavljanje veze s mrežnim portom Java aplikacije u takvom napadu koristi se WebSocket API na koji se, za razliku od HTTP zahtjeva, ne primjenjuju ograničenja istog porijekla (WebSocket se također može koristiti za skeniranje mrežnih portova na lokalnom host za određivanje dostupnih mrežnih upravljačkih programa).
Zanimljivi su i rezultati procjene ranjivosti knjižnica povezanih s ovisnostima s Log4j-om koje je objavio Google. Prema Googleu, problem utječe na 8% svih paketa u Maven Central repozitoriju.
Konkretno, 35863 Java paketa povezanih s Log4j s izravnim i neizravnim ovisnostima bilo je izloženo ranjivostima. Zauzvrat, Log4j se kao izravna ovisnost prve razine koristi samo u 17% slučajeva, a u 83% paketa obuhvaćenih ranjivosti, vezanje se vrši preko međupaketa koji ovise o Log4j, odnosno tell. ovisnosti druge i najviše razine (21% - druga razina, 12% - treća, 14% - četvrta, 26% - peta, 6% - šesta).
Tempo popravljanja ranjivosti i dalje ostavlja mnogo da se poželi, tjedan dana nakon što je ranjivost identificirana, od 35863 identificirana paketa, problem je do sada otklonjen samo u 4620, odnosno na 13%.
Promjene paketa potrebne su za ažuriranje zahtjeva ovisnosti i zamjenu veza stare verzije fiksnim verzijama Log4j 2 (Java paketi prakticiraju vezanje na određenu verziju, a ne na otvoreni raspon koji omogućuje instalaciju najnovije verzije).
Otklanjanje ranjivosti u Java aplikacijama otežava činjenica da programi često uključuju kopije knjižnica u isporuci, a nije dovoljno ažurirati verziju Log4j 2 u paketima sustava.
U međuvremenu, američka Agencija za zaštitu infrastrukture i kibernetičku sigurnost izdala je hitnu direktivu koja zahtijeva od saveznih agencija da prije 4. prosinca identificiraju informacijske sustave na koje utječe ranjivost Log23j i instaliraju ažuriranja koja blokiraju problem.
S druge strane, dana je smjernica do 28. prosinca u kojoj su organizacije imale obvezu izvješćivanja o obavljenim radovima. Radi pojednostavljenja identifikacije problematičnih sustava pripremljena je lista proizvoda u kojima je potvrđena manifestacija ranjivosti (na popisu se nalazi više od 23 tisuće aplikacija).
Konačno, Vrijedi spomenuti da je ranjivost ispravljena u Log4j 2.17 koji je objavljen prije nekoliko dana a korisnicima kojima su ažuriranja onemogućena preporučuje se da izvrše odgovarajuće ažuriranje, uz činjenicu da je opasnost od ranjivosti ublažena činjenicom da se problem manifestira samo na sustavima s Javom 8.
izvor: https://logging.apache.org/