Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

Beveiligingsonderzoekers melden opnieuw kwetsbaarheid in log4j-library

Beveiligingsonderzoekers melden opnieuw een kwetsbaarheid te hebben gevonden in Java-feature log4j, die het mogelijk maakt om op afstand code uit te voeren. Volgens de onderzoekers doet de nieuwe kwetsbaarheid de update tegen de Log4Shell-kwetsbaarheid deels teniet.

In een blogpost schrijven onderzoekers van LunaSec dat het niet betekent dat updaten van log4j helemaal geen zin heeft, maar dat er een kans is dat gebruikers nog steeds kwetsbaar zijn voor Log4Shell, ook als hun systemen versie 2.15.0 hebben geïnstalleerd. In de omschrijving van de nieuwe kwetsbaarheid, CVE-2021-45046, staat dat update 2.15.0 niet volledig beschermt, waardoor denial of service-aanvallen alsnog mogelijk zijn. Daarom is er vrij snel na 2.15.0 nu ook 2.16.0 van log4j uitgebracht.

De onderzoekers schrijven dat naast een DOS-aanval, ook remote code execution mogelijk is. Het is volgens hen wat lastig te begrijpen, maar het komt er op neer dat de fix die Log4Shell moet fixen niet goed werkt in bepaalde niet-standaardconfiguraties van log4j, waardoor aanvallers alsnog toegang kunnen krijgen tot de systemen. De tijdelijke mitigaties die moeten beschermen tegen Log4Shell in versies 2.7.0 tot 2.14.1 van log4j beschermen ook niet tegen deze kwetsbaarheid, zeggen zij.

In tests die de onderzoekers uitgevoerd hebben, blijkt dat de instelling %m{nolookups} niet beschermt tegen Log4Shell en dat remote code execution nog steeds mogelijk is als de noMsgFormatLookups-flag ingesteld is. Volgens de onderzoekers kan logica om JNDI-lookups uit te schakelen worden omzeild via deze instellingen, wat het systeem kwetsbaar maakt. De onderzoekers raden aan om zo snel mogelijk te updaten naar versie 2.16.0, omdat deze de message lookup patterns uitschakelt en standaard JNDI-functionaliteit uitzet.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Stephan Vegelien

Redacteur

15-12-2021 • 07:43

121 Linkedin

Submitter: StePri

Reacties (121)

Wijzig sortering
"This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class)."

Er is geen jndi lookup vulnerability als je jndi lookup weggooit :+
En tamperen met gesignde libraries. Ook niet goed ;-)
Sig files in de meta-inf directory eruit halen. Het leeuwendeel van de 3rd party libraries zijn ook niet signed.
Beter dan dat de kwetsbaarheid uitgebuit wordt.. :)
Doen we op het werk ook gewoon met bijna alle packages die we binnenhalen, gewoon eenmalig downloaden, kopie in git zetten en dan zelf aanpassen in plaats van dat we bijv. een PR inschieten.
En dan daarna nooit meer updaten want dan zijn je aanpassingen weg :+
Ouch,, ga je dan zelf alle mogelijke vulnerabilities opzoeken en elke change release van elke gemiste update door om te kijken of je wat gemist hebt of af en toe nog even een pull?

Nooit meer updaten,, dayumm
Nee man, dat is toch niet te doen?

We updaten gewoon nooit meer, en als we dan 1x in de 5 jaar ofzo écht moeten updaten dan gaan we handmatig onze aanpassingen door en passen we die opnieuw toe na de update :+
Is vragen om problemen... Scan je product maar eens met iets als jfrog of nexus naar vulnerable libraries, wordt je wss niet blij van.
Niet mijn keuze, mijn voorgangers hebben bewust gekozen om niet met industriestandaarden te werken en de mensen die op dit moment meer te zeggen hebben dan ik zijn het daar mee eens, dus kan niet veel meer doen dan een keer zeuren dat het anders moet en me er dan maar bij neerleggen tot ik ergens anders werk gevonden heb.
Of doen zoals ik zei en ze met de feiten op de neus drukken en punten scoren.. . Zit zelf ook in een soort gelijk project... 15 jaar oude applicatie, devs die er al sinds begin der tijden op zitten, dependencies manueel gemanaged in een git repo, antieke Ant build. Is een drama in mij ogen... Maar we zijn langzaam bezig met al deze problemen op te lossen, te beginnen met dependency management te gebruiken (ivy). Ben zelf meer fan van Maven maar het is vooruitgang....
15 jaar oude applicatie, devs die er al sinds begin der tijden op zitten,
Dit lijkt mij niet per se een probleem. Want 15 jaar geleden was er ook amper dependency management. Probleem ligt meer bij devs die vastroesten in hun methodes. Af en toe eens wat olie kan geen kwaad. Sowieso neem je daar (onbewust) dingen uit mee. En er toevallig even composer inzwieren zal hun gedachte op termijn ook aanpassen.
Klinkt lekker, als dat hier op de zaak zo zou gaan, dan hadden ze heel snel mijn ontslagbrief binnen gekregen. Ergens anders werk vinden zou toch een eitje moeten zijn in de huidige markt.
Maar er is ook geen logging. Wat in veel gevallen ook niet wenselijk is.
Hoezo niet? Je gooit Log4j niet weg he ;)

Hou er wel rekening mee dat je mogelijk bepaalde processen om zeep kan helpen als je dit doet. Voorbeeld: een service verwerkt berichtenverkeer. Je forceert een log in berichtenverkeer, je hebt gerommeld met het classpath en je service ligt er uit. Geen idee of dit écht zo is in dit geval though.

[Reactie gewijzigd door Makkelijk op 15 december 2021 08:03]

Log4j is een opensource library (bibliotheek), geen Java feature of tool zoals eerder genoemd.

Edit: goed om dit juist te benoemen voordat er managers gaan roepen dat Java lek is

[Reactie gewijzigd door GrooV op 15 december 2021 08:21]

Eens, verschillende nieuwsoutlets noemen het software, zorgt ook voor verwarring.
Wat mij als non-professional tech nerd ook totaal niet duidelijk is, is of deze vulnerabilities nou alleen een probleem zijn aan de server kant van veel programma's of dat het ook daadwerkelijk impact heeft op de user side apps (zoals Netflix app bijvoorbeeld). Waar ligt nou precies het gevaar? Bij de bedrijven of bij de consument?
Zowel client als server lopen in potentie evenveel risico, maar het ligt aan het specifiek geval. Het is voor een eindgebruiker heel lastig om te bepalen, maar de regel is: draai je een java applicatie en stuurt deze logs van een niet-vertrouwde bron naar een ongepatchde versie van Log4j? Dan ben je kwetsbaar.

Een mooi voorbeeld is de Minecraft client, geschreven in Java, die ontvangen chatberichten van derden door Log4J heen haalt, en dus kwetsbaar is.

Realistisch gezien is dit voor de eindgebruiker niet te bepalen zonder geïnformeerd te worden.

[Reactie gewijzigd door RienBijl op 15 december 2021 09:04]

Het probleem is op alle plaatsen waar een string langs log4j v2 gaat en die string bevat ${jdni:SOME URL}
(al of niet met escapes. Je zou het mogelijk zelfs in een adres label van zeg DHL/POSTNL kunnen printen en dan is er vast ergens een scanner die het oppakt en mogelijk via een java. met log4j)
jndi:... opnemen in een hostname... er is vast een systeem dat een hostname logt...

kortom Het kan OVERAL waar input aan te sturen is, en de logging via een kwetsbare log4j loopt een hoop ellende veroorzaken.
Bij de bedrijven, of je moet lokaal een Java applicatie draaien waaraan je mensen laat connecten.
Het probleem doet zich voor als de (applicatie/server) iets gaat loggen wat direct door een gebruiker is ingevoerd. Zeg bijvoorbeeld dat jij inlogd bij Netflix, je kunt dan speciale code in het veldje van je gebruikersnaam invoeren dat dan op de server wordt uitgevoerd.
Zolang je zelf thuis geen services draait die naar buiten zijn opengesteld heb je nergens last van.
Zolang je zelf thuis geen services draait die naar buiten zijn opengesteld heb je nergens last van.
Fout! Als je thuis een applicatie hebt die kwetsbaar is voor Log4Shell dan kan die ook worden uitgebuit zonder dat deze van buitenaf bereikbaar is. De gebruiker kan bijvoorbeeld een Word-document openen waar een trojan in zit die de kwetsbaarheid misbruikt.

Dit lek is vele malen groter dan alleen de online diensten. Je moet beseffen dat vroeg of laat iedere ongepatchte versie van Log4j wordt misbruikt.
Ik denk beide, hackers kunnen systemen binnenkomen of plat leggen door de logging.

Als je via die systemen weer makkelijk bij andere systemen kunt komen kun je ook de dienstverlening plat leggen. Helemaal als de logging op hetzelfde systeem ligt.
Server, maar software die "intern", ook met elkaar praat, kan ook intern server-cliënt based zijn
Aan de server obviously. Het loggen wat dat programma of script doet controleert de input helemaal niet; je kunt dus gewoon een willekeurige query meesturen die je normaal helemaal niet uit mag voeren. Omdat het vaak onder root draait (als ik me niet vergis) kunnen die queries meteen op root niveau uitgevoerd worden.

Voordat dat dit op T.net stond kreeg ik al email dat ook Cloudflare hun verkeer beschermd tegen dit soort traffic. Dus al zou je nu unpatched draaien, via Cloudflare wordt je wel beschermd.
Applicaties zijn ook gevoelig hiervoor. Er is enkel meestal geen mogelijkheid om het uit te buiten zonder user-interactie - een gebruiker zal een op dat product targeted document moeten openen (of bij applicaties die spullen van internet plukken zal een hacker een corrupt document op de gebruikte internetlocatie moeten zien te krijgen). Of de applicatie al dan niet gevoelig is ervoor hangt van veel condities af.

Maar als een log4j-core.jar in een applicatie verwerkt zit is de verstandigste keus om die niet te gebruiken totdat die ge-upgrade of gepatcht is.

En vertrouwen op Cloudflare zou ik niet al te hard. Want hackers verzinnen telkens nieuwe escapes om om de filteringpatronen heen te werken, dus hoewel datastromen scannen a la Cloudflare handig is om veel pogingen af te stoppen is het onvoldoende om met zekerheid veilig te zijn tegen dit probleem.

Heb in de interne communicatie over dit issue al leuke encoding voor het dollar-accolade-jndi:ldap:// coderen gezien die bedoeld was om door pattern-matching webapplicationfirewalls heen te breken en op log4j alsnog de RCE te triggeren.
Het risico is daar waar de applicatie draait.
De naam Apache gaf ook al de nodige verwarring merkte ik, men ging ervan uit dat ze niet geraakt waren want ze draaien immers geen (Apache) webserver.
Tja, da's hetzelfde als zeggen 'Microsoft' heeft een lekje (in Excel), waarmee niet iedereen getroffen is die 'Microsoft' draait, maar de term is wel te generiek. Als we het Log4j2 noemen is het in elk geval duidelijk.

Apache is een stichting met verschillende projecten onder zich, waarvan de bekendste de webserver is, maar er zijn er nog veel meer (Maven, en Log4j zijn ook grote).
Probleem is dat de webserver zelf geen echte goede naam heeft.
Het heet 'Apache HTTP Server Project' maar niemand noemt het Apache HTTP Server, iedereen noemt het Apache Webserver of zelfs gewoon Apache.

En probeer daarmee maar eens via een zoekmachine er achter te komen of Apache HTTP Server kwetsbaar is door het lek in Apache log4j.
Als ik even snel google op "apache httpd log4j" krijg ik op de eerste pagina al 3 hits die me vertellen dat dat niet het geval is (en een paar die vertellen dat het niet hetzelfde programma is). Dus of ik google er teveel op (zit voor werk dagelijks met meerdere Apache-producten te stoeien) of het is niet zo moeilijk ;)

Verder: als je er niet genoeg verstand van hebt om ze uit elkaar te houden zou je het ook niet zelf in productie moeten hebben, maar een capabele sysadmin vinden om dat te beheren. Dan kan die je vrij snel vertellen of je risico loopt O-)
Dat is nu precies mijn punt.
Als je op apache httpd zoekt zal je inderdaad vinden wat je zoekt.
Maar veel mensen zoeken daar niet op wanneer ze zoeken naar iets van de webserver. De webserver wordt veel gebruikt door hobbyisten en schieten in de stress bij het horen van Apache in dit nieuws.

Ik heb er al een paar moeten geruststellen, vandaar dat ik het punt maak ;)
Was mijn eerste gedachte ook dat er iets met apache logging was.
Dit ging bij vele nieuwsdiensten inderdaad verkeerd. Die schreven dat er een lek in Apache zat. Meestal wordt daar de HTTPD software mee bedoeld natuurlijk. Maar die is niet lek.
Bij ons op het werk ook.. Veel paniek van applicatie owners waar apache httpd in zat. Heb het wel 10x uit moeten leggen de afgelopen dagen.
Maar wel een library voor Java geschreven in Java, toch?
Ja, maar dat is heel wat anders dan een lek in Java zelf. Log4j(2) wordt in een beperkt deel van alle Java applicaties gebruikt. Een lek in Java zelf zou vele malen groter en erger zijn dan dit.
Een beperkt deel van alle Java applicaties zou ik het niet noemen.

Apache Log4j is jarenlang de de facto standaard geweest qua Java logging libraries, voor zover dat niet nog steeds het geval is.
Je wil niet weten hoeveel software hier rechtstreeks of onrechtstreeks gebruik van maakt!
Ik zeg niet dat er niet heel veel software is die gebruik maakt van log4j; wel dat het aandeel in het totale aantal Java applicaties beperkt is. Het merendeel logt helemaal niks, doet botweg System.out.print(ln), gebruikt JUL (voor al deze opties geen extra libraries nodig) of pakt simpelweg wat de default is van het development framework (voor Spring bijvoorbeeld is het gebruik van Logback 11x groter dan het gebruik van log4j, zie tweet van Andy Wilkinson op dit gebied).

Ja, dit lek is erg, maar zeker niet zo erg als wanneer het in de JDK/JRE zelf had gezeten.

[Reactie gewijzigd door NLxAROSA op 15 december 2021 10:54]

Log4J versie 1 is jarenlang de de facto geweest. Versie 2 (die getroffen is) is een complete rewrite, en is veel minder populair. Zelfs nu nog (ondank dat de laatste release van versie 1 in 2012 was), is versie 1 populairder dan versie 2.
Het is in ieder geval een indicatie of je systeem kwetsbaar is. Als je geen java (runtime) op je computer geïnstalleerd hebt, kun je dan wel of niet worden getroffen door dit lek?
Als je zeker weet dat er nergens op je computer een java runtime staat niet. Maar vergis je niet: als er geen java runtime in je 'installed software' lijst staat kun je alsnog (embedded JRE) java op je systeem hebben staan omdat een java-gebaseerde applicatie de JRE zelf meeinstalleert.
Als die dan ook nog log4j 2.x gebruikt voor z'n logging hoef je alleen nog een manier te vinden om die applicatie een RCE-trigger te laten loggen.
Dus toen Heartbleed bekend werd heb jij alles geschreven in C maar de deur uit gedaan?
Nee, nogal wiedes. Java en de library log4j doe ik nu ook de deur niet uit.

Kijk even waar ik op reageerde:
Log4j is een opensource library (bibliotheek), geen Java feature of tool zoals eerder genoemd.
Je kan wel zeggen het is geen Java feature/tool, maar het is wel degelijk een Java library. Dat is waar ik op reageerde.
Haha of deze: hoe leg je je klanten uit dat een library in de programeertaal java een issue heeft waar jullie software in geschreven is zonder je klant het idee te geven dat de issue bij jouw bedrijf ligt
Bij Java staat de kraan toch per definitie open :+

Zonder gekheid, welke taal je ook gebruikt, je moet altijd oppassen met libraries en gedegen onderzoek doen. Je komt er niet onder uit om bepaalde zaken te gebruiken, maar net als een paar maanden terug dat een simpel 1-functie paar-line library uit het CDN gooien het halve internet platlegt is natuurlijk achterlijk.
Nu zitten wij relatief extreem aan de veilige kant en proberen we het echt te minimaliseren, wat neerkomt op veel zelf maken met alle risico's van dien, maar ik zie vaker dat men gewoon bij de eerste zucht al een greep doet naar een library inclusief de 30 dependencies zonder enige controle.
Die dependency hell is overal wel een issue, en vereist een beetje kennis van je programmeur over security en design. Als je nooit geleerd krijgt dat je beter niet teveel troep naar binnen kunt slepen dan gaat het een keer mis. Af en toe een rondje door alle deps lopen en weggooien wat er niet/minimaal gebruikt wordt scheelt sowieso al in je onderhoud. Als je dan ook nog af en toe een update-ronde uitvoert ben je weer ietsje veiliger. Daarnaast kun je sneller die laatste fix meepakken als er toch iets gebeurt met een pakket, zoals nu met Log4j. Als je nog met Log4j 2.3 zit, is een upgrade naar 2.15/16 toch een stap. Zat je al op 2.13 ofzo dan ben je zo bij. (en ja, 2.3 kwam uit in 2015... die mag een keer geupdate worden)
Je kan gedegen onderzoek doen, maar op de werkvloer (nu werk ik niet voor een "gewoon" IT bedrijf vooralsnog) denk ik dat het doel toch eerder snelheid is dan veiligheid. Daarom hebben we de sprints en agile en hoe kan je sneller coderen, door gebruik te maken van libraries.
Het is een beleidskeuze, maar ook deels verantwoordelijkheid van een ontwikkelaar. De groter het bedrijf, de meer de verantwoordelijkheid ligt bij een juiste aanpak. Een eenvoudige "geen externe libraries, tenzij..." die moet worden voorgelegd bij een ander team om te bepalen of de argumenten stand houden t.o.v. het risico. Kost geld, ja, maar dat is goed omgaan met je code base. Het ligt ook aan je product, al is dat met AVG steeds minder relevant geworden.
Wat je zelf al zegt, zelf maken is over het algemeen een stuk risicovoller. Je enige geluk hierbij is het security by obscurity principe.
Grote bugs in opensource libraries zijn altijd wel fijn, want het resulteert vervolgens in veel mensen die nog eens wat dieper naar de library gaan kijken. Zeker security researchers die een beetje naam willen maken.
Het jammere is altijd dat er veel geklaagd wordt vanuit alle hoeken over de veiligheid van de software die ze gratis gebruiker, en waar ze zelf geen tijd in steken in meehelpen met verbeteren. Exact hetzelfde verhaal met OpenSSL toen heartbleed bekend werd.
Klopt ja, ik zou idd graag zien dat de bedrijven gaan meehelpen aan de code of een donatie doen bijv. om ze te ondersteunen.
Sommige bedrijven doen dit, ooit welleens wat gedaan voor apache spul. Het voelt alleen somehow minder cool en een stuk afstandelijker/minder gewaardeerd dan de issues van je eigen werk op te lossen
Dat kan ik me voorstellen, het vergt een bepaalde instelling dan denk ik ook. Hoewel ik veel IT gebeuren op mijn voormalige werk ook niet vaak als gewaardeerd voelde. :)
Het jammere is altijd dat er veel geklaagd wordt vanuit alle hoeken over de veiligheid van de software die ze gratis gebruiker, en waar ze zelf geen tijd in steken in meehelpen met verbeteren.
Het jammere is dat er nog teveel mensen zijn die er van uitgaan dat opensource, gratis software of een OS zoals Linux o.i.d. automatisch betekent dat het veilig is.
[...]


Het jammere is dat er nog teveel mensen zijn die er van uitgaan dat opensource, gratis software of een OS zoals Linux o.i.d. automatisch betekent dat het veilig is.
Omgekeerd is hetzelfde aan de hand, met betaalde software heb ook geen garantie dat hij veilig is,
onderhoud, constant alert op mogelijke problemen is ieder type software aangewezen.
Deze bug is wel veel minder kritiek dan de vorige. Je bent enkel kwetsbaar als je:
- een custom layout pattern hebt gedefinieerd in de Log4j2 config
- én, die layout pattern een ThreadContext variabele gebruikt
- én, die ThreadContext variabele ingevuld wordt met user-supplied data, zoals bvb. een HTTP header
Met de kanttekening dat het eerste punt alleen opgaat als uitsluiter van risico als je degelijke anti-tampering beveiliging op je log configuratiefile hebt zitten, anders hoeft iemand enkel nog een log config file overwrite lek te vinden in de rest van je systeem en krijgen ze met een combinatie van 2 lekken een unauthenticated remote code execution kado.
Maar inderdaad wel al iets minder kritiek dan de jndiLookup op basis van strings in de messagetekst. Voor de lookups in de context is tenminste in het logfile zichtbaar dat er 'magic' gedaan wordt, al zal de gemiddelde beheerder er op rekenen dat wat er uit de eerste magic binnenkomt gewoon direct als string wordt weggelogd (en niet nog weer een keer aan lookup-magic gevoerd wordt)
Uniek dit
-------
T-professionals opgelet: om 16:00 organiseren we samen met @DTC_NL en CSIRT-DSP een informatiesessie over de kwetsbaarheid in Log4j software. Aanmelden kan hier 👉 https://t.co/LD5RH05whb?ssr=true
Het goede nieuws is dat iedereen ondertussen weet waar het geïnstalleerd is, toch?
In theorie wel maar er is zoveel software dat gebruikt wordt waarvan bedrijven wellicht niet eens door hebben dat het log4j gebruikt. Genoeg bedrijven die totaal geen resources besteden aan IT hebben het vast en zeker nog draaien.

Dat er gevolgen gaan komen met hacks o.i.d. is wel vrij aannemelijk, het goede nieuws is meer dat we nu weten dat de IT wereld de bedreigingen serieus neemt als er echt iets aan de hand is. Afgelopen weekend was enorm druk met iedereen die massa's werk verzette om systemen te controleren.
Helaas niet. Gelukkig niet vanuit de professionele hoek (daar ga ik er vanuit dat onze IT het regelt). Maar wel persoonlijk. Ik heb een NAS (Asustor) draaien met een aantal websites die via Docker geserveerd worden. Maar ik heb nog niet kunnen achterhalen of Log4J daar een rol in speelt.

@DiedX Heb je wellicht tips waar ik kan beginnen met zoeken? Of kan ik de 'hack' simpelweg proberen op mijn eigen systeem?
Er is een tool gemaakt waarmee je kan testen of log4j aanwezig is op je systeem (wat nog niet persé wil zeggen dat die effectief gebruikt wordt): https://github.com/mergebase/log4j-detector

Daarnaast kan je gebruik maken van canarytokens (https://canarytokens.org/generate) om een log4j string aan te maken die je dan als user agent kunt instellen of in input velden kunt zetten. Als (een kwetsbare versie van) log4j door de applicatie gebruikt wordt, dan zal deze een callout doen en krijg je een mail (tenzij een outbound firewall rule deze applicatie gaat afschermen).
Het spijt me, ik zit niet in de java-wereld. Ik zou systemen in hun eigen bubble zetten, zodat je iets meer weet waar ze naar toe willen communiceren (firewalling dus).

Maar ik weet weinig van het java-ecosysteem af. Aan de reacties boven te zien lijkt het dat Java niet altijd zo is ingericht dat het makkelijk patchen is van modules.
Da's dus het punt, normaal is je JVM een prima container, maar logs zitten op de grens ervan, en worden naar buiten getransporteerd.
Verder zit je met containers ook al een stuk beter, maar het biedt in alle gevallen wel een extra ingang die je niet verwacht.

As for makkelijk patchen van modules; bij dit soort changes zul je een nieuwe release moeten bakken, en als je een beetje CI/CD pijplijn hebt staan (juist bij dit soort dingen heel nuttig) dan kun je binnen een dag de boel hebben geupdate.
Als je op .jar en .war files zoekt in die omgevingen op je NAS, kun je bijv. de CLI tool van Lunasec gebruiken die deze files vervolgens voor je scanned op kwetsbare log4j classes: https://github.com/lunasec-io/lunasec/releases/ en https://www.lunasec.io/do...lly-scanning-your-package
Kijk eens op canarytokens.org, misschien kan je er iets mee.
Het is in de praktijk toch wel heel lastig na te gaan. Vooral voor grotere organisaties is het heel lastig om te bepalen waar Log4j allemaal in word gebruikt. In de eerste instantie moet je je netwerk afscannen, acteren op emails van leveranciers, en bij je application owners alles nagaan.
Vervolgens moet je nog je mitigations instellen, die verschillen per versie, en volgens dit artikel in sommige gevallen niet eens voldoende zijn. Dan nog wachten tot er een nieuwe release is van de software die de library gebruikt.

Al met al geen fix van een kwartiertje.
En als je dan wat gevonden hebt, met de bewuste kwetsbaarheid, moeten dan ook alle gebruikers die hier ooit gebruik van hebben gemaakt hun wachtwoord aanpassen?
Overigens is dit ook voor kleine organisaties heel lastig. Ik ben meer een Windows beheerder en zit nu allerlei linux machines af te struinen. En ook Windows machines natuurlijk, want Log4J is niet alleen voorbehouden aan Linux. Ik zag een Desktop Central server die een Log4j-1.2.15.jar bestand bevatte.
Dat is natuurlijk afhankelijk van of de de exploit is toegepast op jouw netwerk.
Dat het lek er is wil natuurlijk niet per defnitie zeggen dat het lek ook is uitgebuit.
Het beste kan je je logs nakijken op jndi: ldap en DNS queries, MS heeft hier ook een artikel over geschreven:
https://www.microsoft.com...228-log4j-2-exploitation/

Met dank aan een medetweaker onder het vorige artikel deze (zeer duidelijke) uitleg:
https://www.fastly.com/bl...ce-exploit-found-in-log4j
Ik had begrepen dat je feitelijk niet kan controleren of er misbruik is gemaakt van de kwetsbaarheid omdat dit juist niet gelogd wordt...
Ik had begrepen dat je feitelijk niet kan controleren of er misbruik is gemaakt van de kwetsbaarheid omdat dit juist niet gelogd wordt...
Ze bedoelen dat je niet in de log files geproduceerd door log4j (wat applicatie logs zijn) moet kijken, maar in je httpd/nginx/proxy logs voor die jndi/ldap strings. Het klopt dat die in de log4j geproduceerde logs al vervangen zijn.
En toen had je een java-based proxy die log4j2 gebruikte voor zijn logging.
Of een populaire opensource applicatie of library die message-payload of custom headers ergens in het log stopt (en een proxy die alleen de reguliere headers en request-url logt)

Veel succes (zeg niet dat het niet zinvol is om naar te kijken omdat het wel een 'zekere' poging tot hacken aan het licht kan brengen, enkel dat het geen afdoende maatregel is om een aanval uit te kunnen sluiten).
klopt deels, hangt ervanaf waar je gaat kijken. In de Log4j log gaat het idd niet staan. maar in de JNDI (ldap en dns) log kan je het wel terugvinden.
Het eerste wat een gerichte aanvaller doet nadat hij binnen is, is de Nginx- en Apache-logs proberen op te ruimen om tijd te winnen, omdat dit hem/haar kan verraden. Hoe kun je dan nog verder zien dat iemand binnen is geweest?
Doordat je logs weg zijn :Y)
Als van een willekeurige applicatie je logs verdwijnen is dat alleen al reden om grondig te zoeken, want dat gebeurt niet. Zou ook alerting op moeten zitten.
Dir /s log4*.* En je vindt ze zo. Ik ken iig. geen applicatieservers die geen exploded wars gebruiken. Alleen als leveranciers besluiten libraries te hernoemen vind je ze niet. Ook embedded is zo niet te vinden. Maar een quickscan is niet zo heel complex.
Embedded is lastiger, maar met een simpele oneliner kan je op zoek gaan naar de naam van de jndi-class in iedere .jar en .war op je bestandssysteem. Als je daarnaast nog eens een remote vulnerability scanner gebruikt (github heeft er meerdere), kan je tenminste al 1 oog dichtdoen 's nachts.

Ik heb nu fail2ban ingesteld en heb 8 ip-adressen van aanvallers gevonden sinds gisterenavond, en dat op een server die door 6 mensen gebruikt wordt. Fail2ban helpt uiteraard niet, want zal hooguit een tweede poging van hetzelfde ip-adres tegenhouden, maar het kan toch wel perspectief bieden bij de interne rapportering...
Niet complex? In een kleine organisatie is dat misschien het geval, maar in grote organisaties waar je ook nog eens veel appliances hebt draaien, soms producten hebt die je zelf niet beheerd, elementen in de cloud hebt draaien,.. is het allemaal zo eenvoudig niet om vast te stellen of je wel of niet getroffen bent.
Correct. Als je niet bij de machine kan/mag is het lastig. Maar hopelijk zijn de sla's dan goed ingericht en is het al gefixed voordat je de accountmanager spreekt (maar dat zal meestal wel niet)
Dat zegt dan nog niet of die tool/dll/jar file ook echt gebruikt wordt door een proces.
Correct. Dynamic loading etc. Maar is er een reden te verzinnen om niet over te gaan tot patchen? Leg maar uit aan je auditor dat de log4j bug in kwestie niet van toepassing is omdat je in je configuratie bestand geen %MDC hebt staan of dat je de jar file opengemaakt hebt om JNDILookup.class eruit te halen. Voor een korte termijn (max. 1 week) is dit te overzien. Maar daarna moet toch echt die jarfile vervangen zijn.
JBoss EAP gebruikt volgens mij een zipfilesystem ipv het uit te pakken. Daarbij pak je ook de fat-jar deployments er niet mee.

[Reactie gewijzigd door aikebah op 15 december 2021 16:48]

JBoss gebruikte vroeger iig exploded wars. En meestal doe ik iets met 'find . -name "*.jar" -exec unzip -lv; | grep BlaBla" maar dat leest minder makkelijk dan een dir /s ;-)
(of -name ".?ar" als het complexere middleware is met par/rar/war/ear etc. files).

[Reactie gewijzigd door latka op 15 december 2021 17:37]

Dat is wel mijn ervaring: iedere leverancier heeft de afgelopen dagen netjes gemeld of ze log4j gebruiken.
Ik ben vooral geschrokken van de gelatenheid waarmee een aantal leveranciers deze kwetsbaarheid behandelen. Van een van de grotere partijen kregen we maandagmiddag pas bericht, nadat we zelf vrijdagavond al contact hadden gezocht. De ernst en mogelijke impact werd duidelijk onderschat.

Zelf actie ondernemen is lastig als het een 3rd-party appliance is en offline halen doe je ook niet zomaar als er een grote afhankelijkheid binnen de organisatie.

Maar ook intern, met tientallen development teams wereldwijd en een nog groter aantal cloud accounts/subscriptions, bleek het erg lastig om te achterhalen waar log4j in gebruik was.

[Reactie gewijzigd door Vullisbak op 15 december 2021 08:54]

Leveranciers zijn een ding ja...

Adobe kwam gisteravond(!) pas op de proppen met die nolookup workaround die iedereen die een bepaald gevoel had bij de ernst van dit issue allang toegevoegd had aan hun java argumenten en ze weten nogsteeds niet of hun gebruik van log4j2 op enig moment exploitabel was in hun geval.
Wel handig dat je zelf het antwoord hebt waarom die grote partij ook vrij laat was met een correct antwoord :-)
Zelf hebben we weinig van het weekend kunnen genieten en hadden maandagochtend het meeste wel gepatcht of op de radar. En uiteraard zullen er instances zijn die we nog niet hebben.

Van een grote(re) partij, die voor een niet al te bescheiden bedrag storage producten verkoopt zou je toch iets meer verwachten. Althans, verwachtten wij iets meer van. Zeker als de data van de klant een risico loopt.

Er is in ieder geval weer een onderwerp om met de leverancier over te praten :)
Belangrijke nuance die steeds wordt weggelaten:

Beide lekken zitten niet in log4j, maar in log4-core. Dat is een aparte module die je apart moet binnenhalen. Applicaties die geen log4j-core gebruiken zijn niet kwetsbaar.
Als je applicatie bijvoorbeeld gebruikmaakt van het Spring Framework heb je wel log4j-api en log4j-to-slf4j, maar ben je alsnog niet kwetsbaar omdat je geen log4j-core gebruikt. (Tenzij je via een andere dependency alsnog log4j-core binnen trekt en gebruikt.)

Als dat wat duidelijker was gecommuniceerd (ook door bv het NCSC) zouden er waarschijnlijk heel wat manuren aan uitzoekwerk bespaard zijn. Nu het bij dit lek weer niet duidelijk erbij wordt gezegd doe ik het maar bij deze. Graag gedaan :)

Eerste wat je dus als developer moet doen is even kijken of log4j-core-*.jar aanwezig is in de lijst van dependencies in je IDE. Als dat niet zo is hoef je alleen maar je gebruikers en managers te vertellen dat je niet kwetsbaar bent en dan kun je verder met de rest van je werk ;)

[Reactie gewijzigd door Jerrythafast op 15 december 2021 10:05]

Ehm... er zijn 3000+ java jar files op Maven central gepubliceerd die log4j classes embedden en niet allemaal log4j in de jar file naam hebben staan. Je moet echt alle jar files doorzoeken op het bestaan van de geaffecteerde log4j classes met behulp van https://github.com/mergebase/log4j-detector

Wanneer een bibliotheek de log4j classes erin uberjart, zal die ook direct die api's aanroepen en dus ben je via die route alsnog vatbaar.

Het snelst is dit te controleren door op de ontwikkelpc alle [ewj]ar files in je lokale maven repository te scannen met bovenstaande tool, aangezien alles wat gebruikt wordt daarin terecht komt als het goed is.
Tenzij je het in je JAR geshade hebt... Dan euhm, handmatig zoeken?
Als het goed is kun je in je IDE ook nog zien welke dingen erin gaan voordat het geshade wordt.
Ik heb mijn bericht geüpdatet om dit duidelijk te maken.

[Reactie gewijzigd door Jerrythafast op 15 december 2021 10:05]

Ehm, ook weer niet compleet. Een beetje afhankelijk hoe de scopes van je dependencies zijn, en waar de log4j2 code zich bevindt. Als je zelf gaat shaden dan is het een dependency van jou. Maar als jij een dependency gebruikt die het zelf al in zich geshade heeft, game over.

Kijk eens op wat er allemaal die log4j class in zich heeft op maven central:

https://search.maven.org/...4j.core.lookup.JndiLookup

3000+ jar files :X
Oh getver dat is wel heel erg vies. Kun je daarvan überhaupt nog terugzoeken welke versie van log4j-core er ooit in is verstopt? Zo wordt het onbedoeld bijna een soort trojan :X
Ik denk dat je in de POM die in de jar zit nog of bij maven central staat wel kan zien met welke versie er geprobeerd is te bouwen. Die log4j 2 code moet ergens vandaan gekomen zijn. En anders naar de source repo gaan om daar te zien of ze een fatsoenlijke release gedaan hebben en het ding getagged of zo.

[Reactie gewijzigd door dashorst248 op 15 december 2021 17:37]

Betekent dat dat ik alweer mijn minecraft server moet updaten om dit te patchen?
Goed gelezen inderdaad, laatste zin van het artikel:
De onderzoekers raden aan om zo snel mogelijk te updaten naar versie 2.16.0, omdat deze de message lookup patterns uitschakelt en standaard JNDI-functionaliteit uitzet.
Moet er wel een nieuwe versie komen, ik heb mijn servers allemaal op 1.18.1 lopen en ik kan nog geen nieuwere vinden...
@StePri Stephan Vegelien: foutje in artikel, er staat "niet goed werkt in bepaalde standaardconfiguraties" in de CVE tekst staat "was incomplete in certain non-default configurations"
Niet in de spel-en tikfoutjes Stefan, want dit is geen een spel- of tikfoutje, dit is een fout die in de 'gewone' foutjestak feedback thuishoort, aangezien het de boodschap van het bericht significant verandert. Standaard configuratie versus niet-standaard configuratie (extra context patronen toegevoegd aan de logconfiguratie)
Deze kwetsbaarheid is alleen een probleem als je je logging een template geeft dat automatisch variablen uit de ThreadContext logt én je informatie uit het verzoek van de client in je ThreadContext instelt.

Mogelijk doen frameworks dit automatisch, maar ik denk niet dat veel Log4J-gebruikers dit snel zullen doen. De kans dat dit misgaat is dus niet zo groot. De DoS-aanval lijkt ook zonder aparte configuratie kwetsbaar te zijn, maar ook die vereist dat je dingen in de ThreadContext invoegt.

Onder de streep dus nog steeds een kwetsbaarheid, maar één die veel minder vaak zal voorkomen dan de eerdere kwetsbaarheden.

Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone SE (2022) LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S22 Garmin fēnix 7 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True