Mõni nädal tagasi pööras uudis Log4j turvaprobleemidest paljud võrgu kasutajad pea peale ja see on üks enim ära kasutatud vigadest, mida paljud eksperdid on nimetanud "üle pika aja kõige ohtlikumaks". Räägime mõnest võrgus teatavaks tehtud haavatavusest siin blogis ja seekord oleme leidnud uudise teisest.
Ja see on paar päeva tagasi avaldati uudis, et Log4j 2 teegis tuvastati veel üks haavatavus (mis on juba loetletud CVE-2021-45105 all) ja mis erinevalt kahest eelmisest probleemist klassifitseeriti ohtlikuks, kuid mitte kriitiliseks.
Uus probleem võimaldab teenusest keeldumist ja väljendub silmuste ja ebanormaalsete lõpetamistena teatud ridade töötlemisel.
Haavatavus mõjutab süsteeme, mis kasutavad kontekstiotsingut, näiteks $ {ctx: var}logi väljundvormingu määramiseks.
The Log4j versioonidel 2.0-alpha1 kuni 2.16.0 puudus kaitse kontrollimatu rekursiooni eest, mida võimaldas ründajal asenduses kasutatava väärtusega manipuleerida tekitada lõputu silmus, mille virna ruum saaks otsa ja protsess takerduks. Eelkõige ilmnes probleem selliste väärtuste asendamisel nagu "$ {$ {:: - $ {:: - $$ {:: - j}}}}".
Lisaks Võib märkida, et Blumira teadlased on teinud ettepaneku rünnata haavatavaid Java rakendusi mis ei võta vastu välisvõrkude päringuid, näiteks saab sel viisil rünnata Java-rakenduste arendajate või kasutajate süsteeme.
Meetodi olemus seisneb selles, et kui on haavatavaid Java protsesse kasutaja süsteemis, mis aktsepteerib võrguühendusi ainult kohalikult hostilt (localhost) või töötleb RMI-päringuid (Remote Method Invocation, port 1099), ründe saab sooritada käivitatud JavaScripti koodiga kui kasutaja avab brauseris pahatahtliku lehe. Java-rakenduse võrgupordiga ühenduse loomiseks sellise rünnaku korral kasutatakse WebSocket API-t, millele erinevalt HTTP päringutest sama päritolu piiranguid ei rakendata (WebSocketit saab kasutada ka kohaliku võrgu portide skannimiseks saadaolevate võrgudraiverite kindlakstegemiseks).
Huvi pakuvad ka Google'i avaldatud Log4j-ga sõltuvustega seotud raamatukogude haavatavuse hindamise tulemused. Google'i andmetel mõjutab probleem 8% kõigist Maven Centrali hoidlas olevatest pakettidest.
Eelkõige puutus haavatavustesse 35863 4 Log4j-ga seotud Java-paketti, millel olid otsesed ja kaudsed sõltuvused. Log17j on omakorda kasutusel esimese taseme otsese sõltuvusena vaid 83% juhtudest ning 4% haavatavusega hõlmatud pakettidest toimub sidumine läbi Log21j-st sõltuvate vahepakettide ehk tell. teise ja kõrgeima taseme sõltuvused (12% - teine tase, 14% - kolmas, 26% - neljas, 6% - viies, XNUMX% - kuues).
Haavatavuse parandamise määr jätab soovida veel nädal pärast haavatavuse tuvastamist, 35863 4620 tuvastatud paketist on probleem seni lahendatud vaid 13 puhul ehk XNUMX%.
Pakettide muudatused on vajalikud sõltuvusnõuete värskendamiseks ja vanade versioonide sidumiste asendamiseks Log4j 2 fikseeritud versioonidega (Java paketid harjutavad sidumist konkreetse versiooniga, mitte avatud vahemikuga, mis võimaldab installida uusima versiooni).
Java-rakenduste haavatavuse kõrvaldamist raskendab asjaolu, et programmid sisaldavad sageli tarnimisel teekide koopiaid ning Log4j 2 versiooni uuendamisest süsteemipakettides ei piisa.
Vahepeal andis USA infrastruktuurikaitse ja küberjulgeoleku agentuur välja hädaolukorra direktiivi, mis nõuab, et föderaalasutused tuvastaksid Log4j haavatavusest mõjutatud infosüsteemid ja installiksid probleemi blokeerivad värskendused enne 23. detsembrit.
Seevastu 28. detsembrini anti juhend, milles organisatsioonidel oli kohustus tehtud töödest aru anda. Probleemsete süsteemide tuvastamise lihtsustamiseks on koostatud nimekiri toodetest, mille puhul on kinnitust leidnud haavatavus (nimekirjas on üle 23 tuhande rakenduse).
Lõpuks Tasub mainida, et haavatavus parandati mõne päeva eest avaldatud versioonis Log4j 2.17 ja kasutajatel, kellel on uuendused keelatud, soovitatakse teha ka vastav uuendus, lisaks sellele, et haavatavuse ohtu vähendab see, et probleem avaldub vaid Java 8-ga süsteemides.
allikas: https://logging.apache.org/