Prieš kelias savaites žinia apie Log4j saugumo problemas apvertė daug tinklo vartotojų aukštyn kojomis ir tai yra vienas iš labiausiai išnaudojamų trūkumų, kurį daugelis ekspertų pavadino „pavojingiausiu pasaulyje“. ilgą laiką », Apie pažeidžiamumą, apie kurį buvo pranešta tinkle, kalbame apie kai kuriuos iš jų čia, tinklaraštyje ir šį kartą radome naujieną apie kitą.
Ir taip yra prieš kelias dienas buvo paskelbta žinia, kad Log4j 2 bibliotekoje buvo nustatytas dar vienas pažeidžiamumas (kuris jau įtrauktas į CVE-2021-45105) ir kuris, skirtingai nei ankstesnės dvi problemos, buvo klasifikuojamas kaip pavojingas, bet ne kritinis.
Nauja problema leidžia atsisakyti paslaugos ir pasireiškia kilpų ir neįprastų nutraukimų pavidalu apdorojant tam tikras eilutes.
Pažeidžiamumas turi įtakos sistemoms, kurios naudoja kontekstinę paiešką, pvz., $ {ctx: var}, norėdami nustatyti žurnalo išvesties formatą.
The Log4j versijose nuo 2.0-alpha1 iki 2.16.0 trūko apsaugos nuo nekontroliuojamos pasikartojimo, ką leido užpuolikui manipuliuoti pakeitimui naudojama verte kad susidarytų nesibaigianti kilpa, kuriai ant krūvos pritrūktų vietos ir procesas užstotų. Visų pirma, problema iškilo pakeičiant reikšmes, tokias kaip "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Be to, Galima pastebėti, kad „Blumira“ mokslininkai pasiūlė ataką prieš pažeidžiamas „Java“ programas kurie nepriima užklausų iš išorinių tinklų, pavyzdžiui, tokiu būdu gali būti atakuojamos Java programų kūrėjų ar vartotojų sistemos.
Metodo esmė ta, kad jei yra pažeidžiamų Java procesų vartotojo sistemoje, kuri priima tinklo ryšius tik iš vietinio pagrindinio kompiuterio (localhost) arba apdoroja RMI užklausas (Remote Method Invocation, 1099 prievadas), ataka gali būti vykdoma vykdomu JavaScript kodu kai vartotojas naršyklėje atidaro kenkėjišką puslapį. Norint užmegzti ryšį su Java programos tinklo prievadu tokios atakos metu, naudojama WebSocket API, kuriai, skirtingai nei HTTP užklausoms, netaikomi jokie tos pačios kilmės apribojimai (WebSocket taip pat gali būti naudojamas nuskaityti tinklo prievadus vietinėje pagrindinį kompiuterį, kad nustatytų galimas tinklo tvarkykles).
Taip pat domina „Google“ paskelbtų bibliotekų, susijusių su „Log4j“ priklausomybėmis, pažeidžiamumo įvertinimo rezultatai. „Google“ teigimu, problema paliečia 8% visų „Maven Central“ saugykloje esančių paketų.
Visų pirma, 35863 4 „Log4j“ susiję „Java“ paketai su tiesiogine ir netiesiogine priklausomybe buvo paveikti pažeidžiamumų. Savo ruožtu Log17j kaip tiesioginė pirmojo lygio priklausomybė naudojama tik 83% atvejų, o 4% paketų, kuriems taikomas pažeidžiamumas, surišimas atliekamas per tarpinius paketus, kurie priklauso nuo Log21j, tai yra pasakyk. antrojo ir aukščiausio lygio priklausomybės (12% - antrasis lygis, 14% - trečias, 26% - ketvirtas, 6% - penktas, XNUMX% - šeštas).
Pažeidžiamumo taisymo tempas vis dar palieka daug norimų rezultatų, praėjus savaitei po pažeidžiamumo nustatymo, iš 35863 4620 nustatytų paketų problema iki šiol buvo ištaisyta tik 13, tai yra XNUMX%.
Paketų pakeitimai būtini norint atnaujinti priklausomybės reikalavimus ir pakeisti senų versijų susiejimą fiksuotomis Log4j 2 versijomis („Java“ paketai praktikuoja susiejimą su konkrečia versija, o ne atviru diapazonu, leidžiančiu įdiegti naujausią versiją).
„Java“ programų pažeidžiamumą panaikinti trukdo tai, kad programose dažnai pateikiamos bibliotekų kopijos, o sistemos paketuose neužtenka atnaujinti „Log4j 2“ versiją.
Tuo tarpu JAV infrastruktūros apsaugos ir kibernetinio saugumo agentūra paskelbė nepaprastosios padėties direktyvą, reikalaujančią, kad federalinės agentūros nustatytų informacines sistemas, paveiktas Log4j pažeidžiamumo, ir įdiegtų naujinimus, blokuojančius problemą. Iki gruodžio 23 d.
Kita vertus, iki gruodžio 28 d. buvo duotas nurodymas, kuriame organizacijoms buvo nustatyta pareiga atsiskaityti už atliktus darbus. Siekiant supaprastinti probleminių sistemų identifikavimą, buvo parengtas produktų, kuriuose patvirtintas pažeidžiamumo pasireiškimas, sąrašas (sąraše yra daugiau nei 23 tūkst. programų).
Galiausiai, Verta paminėti, kad pažeidžiamumas buvo ištaisytas Log4j 2.17, kuris buvo paskelbtas prieš kelias dienas o vartotojams, kuriems naujinimai išjungti, rekomenduojama atlikti atitinkamą naujinimą, be to, pažeidžiamumo pavojų sumažina tai, kad problema pasireiškia tik sistemose su „Java 8“.
Fuente: https://logging.apache.org/