zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Hoppa. Werkt goed hier.

Tja zo gaat het meestal de laatste tijd: door een of ander lek komt de aandacht op een bepaalde module te liggen en blijkt dat ineens grote rotzooi te zijn waar lek na lek uitkomt... dit is vast niet het laatste wat we van log4j horen en daarna zijn andere modules met vergelijkbare functionaliteit aan de beurt.

Nou nee, dat is hier niet aan de hand en probeer nou niet te suggereren dat het om Microsoft rotzooi gaat. Wat er wel aan de hand is staat toch duidelijk in de tekst van het artikel hierboven. Laat ik het speciaal voor jou nog eens uitkauwen:

Lijkt me minder erg dan.

Ik suggereer helemaal niet dat het om Microsoft rotzooi gaat, alleen dat het om (ondoordachte) rotzooi gaat.
Daar sta ik kennelijk ook niet alleen in. Het is niet voor niets dat hele volksstammen zijn blijven hangen op log4j
versie 1.x en nu geen probleem hebben. Die 2.x is gewoon bloatware.

Afgezien de hele wereld momenteel heel druk bezig is met dit issue en dat men vaak geen idee heeft, waar dit nu gebruikt wordt in de omgeving.

Ik heb al heel wat paniek bij klanten voorbij zien komen. En waar net geupdate is, kunnen we nu weer beginnen, omdat de eerste fix niet goed werkte.

Blocklist https://github.com/craiu/iocs/blob/main/log4shell/log4j_blocklist.txt
luntrus

Dat deed je wel alsof het exchange software is. Versie 2 had alleen een feature toegevoegd wat een foute keuze is gebleken. Is nu ongedaan gemaakt. De tijd zal leren of het een exchange klucht wordt. Op voorhand suggeren is niet professioneel.

Let op: Het risico van versie 1.x is stuk lager maar kunnen wel degelijk geraakt zijn.

Ja, dat is inderdaad opvallend. Logisch is het ook, want zodra een kwetsbaarheid wordt gevonden, gaan anderen natuurlijk op zoek of er meer kwetsbaarheden verborgen zitten in de betreffende module.

Exact, precies dat.

Nou moet je niet ineens doen alsof dit minder erg is dan een lek in Windows, dit is het grootste probleem van meer dan 10 jaar.
En de Apache Software Foundation is slechts een sponsor van dit project wat in feite een zolderkamer product is.Sterker nog de functie die nu misbruikt (volgens CVE-2021-44228) wordt is er op verzoek in gezet en omdat er geen overkoepelende club is die dingen controleert is het gewoon geimplementeerd.
De aanvullende CVE is er omdat mensen met een nog antiekere versie stiekem nieuwere functionaliteit includen die dus te misbruiken is.

Je kunt er op rekenen dat dit nog een hele lange tijd blijft doormodderen aangezien vele software boeren deze module als standaard meeleveren.
Eigenlijk kun je zeggen dat juist wat de sterke kant van open source is, het kunnen controleren van code door iedereen, onderuit gaat aangezien niemand dat heeft gedaan blijkbaar. Nu moeten 2 jongens op een zolderkamer een stukje code gaan fixen dat op meer dan een miljard computers gebruikt wordt.

Log4j recap
- two random unpaid folk maintain the code
- a random requested the vuln/feature in 2013
- major IT and security vendors rely on that code
- problem was publicised by teens in Minecraft video game
- scope of problem still unclear days later

Het betreft open source, iedereen kon het zien en jarenlang zag niemand het maar iedereen ging het uit gemak op de raarste plekken er tussen zetten. Iemand anders zou de veiligheid wel garanderen.

Dit zal zich blijven herhalen omdat de uitgangspunten en gedrag niet veranderen.
Wat zal het volgende grote ernstige lek zijn?

Ik zie dat het daar anders is maar krijg de vinger en niet op. Heb je meer dan een veronderstelling? JNDI is er niet..

Ik weet niet waarover je het hebt.


Geen idee.

Er zijn nog mensen die dit niet serieus nemen en zeggen "Mijn server hangt niet aan het internet", de komende tijd krijgen we nog veel gevolgschade te zien.

Een goede strategie tegen aanvallen van buitenaf, maar niet tegen een "inside job" van een "disgruntled employee".

Ook geen goede strategie voor aanvallen van buiten.
Log4j heeft een functie, parsen van logfiles. Stel je hebt een paar webservers, niets bijzonders nginx die wat websites host.
De logs worden geshipped naar een server die niet aan het blote internet hangt maar wel logstash en elasticsearch gebruikt om je logs in op te slaan. Als logstash en elasticsearch niet gepatched zijn parsen die dus gewoon de code die in de logs opgeslagen zijn op je nginx doosje, je elasticsearch server gaat dus gewoon een remote shell connectie opzetten met de buitenwereld.

Dat gebeurd dus gewoon.