Efter två år är Log4Shell fortfarande ett problem, eftersom många projekt fortfarande är sårbara

log4j

Log4Shell är en som kommer att dyka upp i dataintrång under det kommande decenniet

Denna sista månad av året 2023 markerade andra årsdagen av upptäckten av Log4j/Log4Shell-sårbarheten, vilket är en sårbarhet som fortsätter att påverka många projekt idag och utgör en säkerhetsrisk.

Och Log4j fortsätter att vara ett främsta mål för cyberattacker, enligt Cloudflares årliga rapport "Year in Review" och även resultaten av en studie om relevansen av kritiska sårbarheter i Log4j Java-biblioteket släppt av säkerhetsforskare av Veracode.

mycket Veracode-forskare nämner det efter att ha studerat 38.278 XNUMX ansökningar användes av 3.866 XNUMX organisationer upptäckte de det två av fem applikationer använder fortfarande sårbara versioner från Apache Log4j-biblioteket, två år efter att en kritisk sårbarhet offentliggjordes.

Rapporten visar att ungefär en tredjedel av applikationerna kör Log4j2 1.2.x (som nådde slutet av livet i augusti 2015 och inte längre får patchuppdateringar) vilket motsvarar 38 %. Den främsta anledningen till att fortsätta använda äldre kod är integrationen av gamla bibliotek i projekt eller mödan i att migrera från grenar som inte stöds till nya grenar som är bakåtkompatibla. Dessutom använder 2.8 % av applikationerna fortfarande versioner som är sårbara för den välkända Log4Shell-sårbarheten.

Utöver det, Det nämns att det finns tre huvudkategorier av applikationer som fortfarande använder sårbara versioner av Log4j, enligt Veracode-rapporten:

  1. Log4Shell-sårbarhet (CVE-2021-44228):
    2.8 % av applikationerna fortsätter att använda Log4j-versioner från 2.0-beta9 till 2.15.0, som innehåller den kända sårbarheten.
  2. Fjärrkodexekveringssårbarhet (RCE) (CVE-2021-44832):
    3.8 % av applikationerna använder versionen Log4j2 2.17.0, som åtgärdar Log4Shell-sårbarheten, men som inte löser sårbarheten för fjärrkörning av kod (RCE) som identifieras som CVE-2021-44832.
  3. Log4j2 1.2.x Branch (Support slutförts 2015):
    32 % av applikationerna använder fortfarande Log4j2 1.2.x-grenen, vars stöd upphörde 2015. Denna gren har påverkats av kritiska sårbarheter, såsom CVE-2022-23307, CVE-2022-23305 och CVE-2022-23302, identifierade i 2022, sju år efter att underhållet upphörde.

Dessa data belyser mångfalden av situationer där applikationer fortsätter att använda föråldrade och sårbara versioner av Log4j, vilket väcker stor oro från forskare.

Och ett oroande faktum är att 3.8 % av applikationerna använder Log4j2 2.17.0, som patchades mot Log4Shell, men innehåller CVE-2021-44832, en annan sårbarhet för fjärrexekvering av kod.

Rapporten visar att trots de ansträngningar som gjorts under de senaste åren för att förbättra säkerhetspraxis inom mjukvaruutveckling och användning av öppen källkod, det finns arbete att göra.

Chris Eng, forskningschef på Veracode, betonar att:

Utvecklare har ett avgörande ansvar och det finns utrymme för förbättringar när det kommer till säkerheten för programvara med öppen källkod.

Även om många utvecklare initialt reagerade på lämpligt sätt på Log4j-krisen genom att installera version 2.17.0, tyder rapporten på att vissa har återgått till tidigare mönster genom att inte tillämpa patchar efter utgåvan av 2.17.1.

Apache Software Foundation (ASF) har aktivt underrättat nedströmsprojekt om att det är brådskande att uppdatera, men rapportens resultat tyder på att det fortfarande finns applikationer som inte har implementerat de nödvändiga korrigeringarna.

Veracodes rapport baserades på data från mjukvaruskanningar av mer än 38,000 90 appar under en 15-dagarsperiod mellan 15 augusti och 4 november. Applikationerna körde Log1.1j-versioner från 3.0.0 till 1 alfa 3,866 i XNUMX XNUMX olika organisationer.

Vår forskning fann också att när utvecklare varnas om ett sårbart bibliotek genom en skanning, fixar de dem relativt snabbt: 50 procent av sårbarheterna åtgärdas på totalt 89 dagar, på 65 dagar för allvarliga sårbarheter och på 107 dagar för medelsvåra sårbarheter.

Dessa resultat överensstämmer med tidigare varningar, som 2022 års Federal Cybersecurity Review Board-rapport, som indikerade att Log4j-krisen skulle ta år att lösa helt.

äntligen om du är det intresserad av att veta mer om det, Jag inbjuder dig att besöka den ursprungliga artikeln på veracode-bloggen. Länken är den här.


Lämna din kommentar

Din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *

*

*

  1. Ansvarig för data: AB Internet Networks 2008 SL
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.