Prije nekoliko sedmica vijest o sigurnosnim problemima Log4j-a izokrenula je mnoge korisnike na mreži, a riječ je o tome da je to jedna od mana koja se najviše iskorištava i koju 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 je 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, klasifikovan kao opasan, ali ne i kritičan.
Novi problem dozvoljava uskraćivanje usluge i manifestuje se u obliku petlji i abnormalnih završetaka prilikom obrade određenih linija.
Ranjivost utiče na sisteme koji koriste pretraživanje konteksta, kao što je $ {ctx: var}, za određivanje izlaznog formata dnevnika.
u Log4j verzije 2.0-alpha1 do 2.16.0 nisu imale zaštitu od nekontrolisanog ponavljanja, šta dozvolio napadaču da manipuliše vrijednošću korištenom u zamjeni da izazove beskonačnu petlju koja bi ostala bez prostora na steku i prouzrokovala da proces visi. Konkretno, problem je nastao prilikom zamjene vrijednosti kao što je "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Takođe, Može se primijetiti da su istraživači Blumire predložili napad na ranjive Java aplikacije koji ne prihvataju zahtjeve iz vanjskih mreža, na primjer, sistemi programera ili korisnika Java aplikacija mogu biti napadnuti na ovaj način.
Suština metode je da ako postoje ranjivi Java procesi na korisnikovom sistemu koji prihvata mrežne veze samo sa 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 pretraživaču. 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 drajvera).
Zanimljivi su i rezultati procjene ranjivosti biblioteka povezanih s ovisnostima sa Log4j koje je objavio Google. Prema Google-u, problem pogađa 8% svih paketa u Maven Central repozitorijumu.
Konkretno, 35863 Log4j povezanih Java paketa sa direktnim i indirektnim zavisnostima bilo je izloženo ranjivosti. Zauzvrat, Log4j se kao direktna zavisnost prvog nivoa koristi samo u 17% slučajeva, a u 83% paketa obuhvaćenih ranjivosti, povezivanje se vrši preko međupaketa koji zavise od Log4j, tj. zavisnosti drugog i najvišeg nivoa (21% - drugi nivo, 12% - treći, 14% - četvrti, 26% - peti, 6% - šesti).
Tempo popravke ranjivosti i dalje ostavlja mnogo da se poželi, nedelju dana nakon što je ranjivost identifikovana, od 35863 identifikovana paketa, problem je do sada otklonjen samo u 4620, odnosno na 13%.
Promjene paketa su neophodne za ažuriranje zahtjeva ovisnosti i zamjenu vezivanja starih verzija fiksnim verzijama Log4j 2 (Java paketi praktikuju vezivanje za određenu verziju, a ne otvoreni raspon koji dozvoljava instalaciju najnovije verzije).
Otklanjanje ranjivosti u Java aplikacijama je otežano činjenicom da programi često uključuju kopije biblioteka u isporuci, a nije dovoljno ažurirati verziju Log4j 2 u sistemskim paketima.
U međuvremenu, američka Agencija za zaštitu infrastrukture i kibernetičku sigurnost izdala je hitnu direktivu koja zahtijeva od saveznih agencija da identifikuju informacione sisteme pogođene ranjivosti Log4j i instaliraju ažuriranja koja blokiraju problem prije 23. decembra.
S druge strane, data je smjernica do 28. decembra u kojoj su organizacije imale obavezu da izvještavaju o obavljenom poslu. Da bi se pojednostavila identifikacija problematičnih sistema, pripremljena je lista proizvoda kod kojih je potvrđena manifestacija ranjivosti (na listi se nalazi više od 23 hiljade aplikacija).
Na kraju, Vrijedi napomenuti 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, pored činjenice da je opasnost od ranjivosti ublažena činjenicom da se problem manifestuje samo na sistemima sa Javom 8.
Izvor: https://logging.apache.org/