„Log4Shell“ per ateinantį dešimtmetį atsiras duomenų pažeidimų atveju
Šis paskutinis 2023 metų mėnuo pažymėjo antrosios Log4j/Log4Shell pažeidžiamumo atradimo metinės, Tai yra pažeidžiamumas, kuris šiandien ir toliau daro poveikį daugeliui projektų ir kelia pavojų saugumui.
Remiantis „Cloudflare“ metine „Year in Review“ ataskaita ir saugumo tyrinėtojų paskelbtu „Log4j Java“ bibliotekos kritinių spragų tinkamumu, „Log4j“ ir toliau yra pagrindinis kibernetinių atakų taikinys.
Los Veracode mokslininkai mini, kad ištyrę 38.278 XNUMX prašymus naudojo 3.866 organizacijos, jie atrado, kad dvi iš penkių programų vis dar naudoja pažeidžiamas versijas Apache Log4j bibliotekos, praėjus dvejiems metams po kritinio pažeidžiamumo paskelbimo viešai.
Ataskaitoje pabrėžiama, kad maždaug trečdalyje programų veikia Log4j2 1.2.x (kuris pasibaigė 2015 m. rugpjūčio mėn. ir nebegauna pataisų atnaujinimų), o tai sudaro 38 proc. Pagrindinė priežastis, kodėl toliau naudojamas senas kodas, yra senų bibliotekų integravimas į projektus arba sunkus perėjimas iš nepalaikomų filialų į naujas, atgaline data suderinamas šakas. Be to, 2.8 % programų vis dar naudoja versijas, pažeidžiamas gerai žinomo Log4Shell pažeidžiamumo.
Be to, Paminėta, kad yra trys pagrindinės kategorijos programų, vis dar naudojančių pažeidžiamas Log4j versijas, remiantis „Veracode“ ataskaita:
- „Log4Shell“ pažeidžiamumas (CVE-2021-44228):
2.8 % programų ir toliau naudoja Log4j versijas nuo 2.0-beta9 iki 2.15.0, kuriose yra žinomas pažeidžiamumas. - Nuotolinio kodo vykdymo (RCE) pažeidimas (CVE-2021-44832):
3.8 % programų naudoja Log4j2 2.17.0 versiją, kuri pašalina Log4Shell pažeidžiamumą, bet nepašalina nuotolinio kodo vykdymo (RCE) pažeidžiamumo, identifikuoto kaip CVE-2021-44832. - Log4j2 1.2.x filialas (palaikymas baigtas 2015 m.):
32 % programų vis dar naudoja Log4j2 1.2.x šaką, kurios palaikymas baigėsi 2015 m. Šią šaką paveikė kritinės spragos, tokios kaip CVE-2022-23307, CVE-2022-23305 ir CVE-2022-23302, nustatytos 2022 m., praėjus septyneriems metams po priežiūros pabaigos.
Šie duomenys pabrėžia situacijų, kai programos ir toliau naudoja pasenusias ir pažeidžiamas Log4j versijas, įvairovę, o tai kelia didelį tyrėjų susirūpinimą.
Nerimą kelia tai, kad 3.8 % programų naudoja Log4j2 2.17.0, kuri buvo pataisyta prieš Log4Shell, tačiau jame yra CVE-2021-44832, dar vienas didelio sunkumo nuotolinio kodo vykdymo pažeidžiamumas.
Pranešime pabrėžiama, kad nepaisant įdėtų pastangų pastaraisiais metais tobulinti saugumo praktiką kuriant programinę įrangą ir naudojant atvirąjį kodą, yra ką veikti.
Chrisas Engas, „Veracode“ tyrimų direktorius, pabrėžia, kad:
Kūrėjai prisiima didelę atsakomybę ir yra kur tobulėti atvirojo kodo programinės įrangos saugumo srityje.
Nors daugelis kūrėjų iš pradžių tinkamai reagavo į Log4j krizę įdiegdami 2.17.0 versiją, ataskaitoje teigiama, kad kai kurie grįžo prie ankstesnių modelių, nepritaikydami pataisų po 2.17.1 versijos.
„Apache Software Foundation“ (ASF) aktyviai praneša tolesniems projektams apie būtinybę atnaujinti, tačiau ataskaitos išvados rodo, kad vis dar yra programų, kurios neįdiegė reikiamų pataisymų.
Veracode ataskaita buvo pagrįsta duomenimis, gautais daugiau nei 38,000 90 programų programinės įrangos nuskaitymo per 15 dienų laikotarpį nuo rugpjūčio 15 d. iki lapkričio 4 d. Programos veikė Log1.1j versijos nuo 3.0.0 iki 1 alfa 3,866 XNUMX skirtingose organizacijose.
Mūsų tyrimas taip pat nustatė, kad kai kūrėjai yra įspėjami apie pažeidžiamą biblioteką nuskaitydami, jie gana greitai jas ištaiso: 50 procentų pažeidžiamumų iš viso ištaisoma per 89 dienas, per 65 dienas, jei pažeidžiamumas yra didelis, ir per 107 dienas, kai pažeidžiamumas yra vidutinio sunkumo.
Šie rezultatai atitinka ankstesnius įspėjimus, pvz., 2022 m. Federalinės kibernetinio saugumo peržiūros tarybos ataskaitą, kurioje nurodyta, kad Log4j krizei visiškai išspręsti prireiks metų.
pagaliau jei esi domina sužinoti daugiau apie tai, kviečiu apsilankyti originaliame veracode tinklaraščio straipsnyje. Nuoroda yra tokia.