Waar is de log4j-apocalyps gebleven?

Overdreven angst of toch goed patchbeleid

Waar is de log4j-apocalyps gebleven?

In december van 2021 stond de securitywereld even op zijn kop toen een kwetsbaarheid in Java-library log4j naar buiten kwam: overal onbewust aanwezig, uit te buiten tot volledige overname van machines door slechts een regeltje code te sturen met een mailtje... Het leek een perfecte storm voor een ict-ramp, maar die bleef uit, tegen de meeste verwachtingen in. Hoe kan dat? Had de beveiligingswereld het bij het verkeerde eind? Was Log4Shell helemaal niet zo'n probleem? Of heeft het koortsachtige patchen toch goed gewerkt?

Openbaring

In het begin dacht systeembeheerder Johan (niet zijn echte naam) niet dat het net geopenbaarde lek Log4Shell zo ernstig was. Hij begon op vrijdagochtend 10 december met zijn werkdag en las dat er een groot lek zat in de Java-library log4j, maar rondde eerst zijn gewone werkzaamheden af. "Toen alle andere taken afgerond waren, kreeg ik pas door hoe groot het was en heb ik er met een collega uitgebreid naar gekeken. De rest was al weekend vieren", vertelt de programmeur aan Tweakers. Voor hem begon dat weekend pas veel later, want log4j bleek een van de ernstigste kwetsbaarheden te zijn die de securityindustrie ooit had gezien. Johan werkte daarom het hele weekend door om patches door te voeren en uiteindelijk systemen van klanten uit te schakelen. "Ik belde met een collega en ook hij kwam tot dezelfde conclusies als ik: dat de applicaties bij de klanten eigenlijk niet door konden blijven draaien zonder update." Zijn verhaal is exemplarisch voor wat meerdere ontwikkelaars aan Tweakers vertellen over Log4Shell. In het begin leek Log4j een vrij rechttoe-rechtaankwetsbaarheid, maar hoe meer erover bekend werd, hoe ernstiger het probleem bleek te zijn. Zo ernstig zelfs, dat Johan de drastische beslissing nam om systemen van klanten maar helemaal uit te zetten. "Ik heb de directeur gebeld en uitgelegd wat er aan de hand was. Na een hele dag bellen in groepsgesprekken met directeur en collega's besloten we om de klantsystemen op zaterdagavond uit te zetten."

De zwakte in log4j leek een waterscheidingsmoment te zijn voor de securityindustrie. Natuurlijk, er zijn in het verleden al honderden, zo niet duizenden ernstige kwetsbaarheden geweest met een potentieel grote impact, maar Log4Shell leek echt apocalyptisch te kunnen worden. Het gevaar van de bug zat in een combinatie van drie dingen. Ten eerste was het probleem wijdverspreid: de kwetsbare library zat in praktisch ieder netwerkapparaat en zat op de een of andere manier in veel andere software ingebakken. Ten tweede was er de kinderlijk eenvoudige methode van uitbuiten. In theorie was dat mogelijk door alleen een bericht te sturen naar een apparaat waar log4j op draaide en je kon er al veel mee doen. Dat was het derde ernstige punt: na een infectie leek het dat er direct remote code executions konden worden gedaan en zo bijvoorbeeld een reverseshell kon worden opgezet, een achterdeur kon worden opengezet of door netwerken kon worden bewogen. Die drie factoren maakten Log4Shell een groot risico. Toch lijkt de ernst van het lek in de praktijk mee te vallen. Er zijn, in ieder geval voor zover bekend, amper grote aanvallen geweest waarbij log4j de belangrijkste aanvalsvector bleek te zijn. De ransomwareaanvallen op kritieke infrastructuur bleven uit, de grootschalige phishingcampagnes waar Log4Shell voor gemaakt zou zijn, werden niet uitgevoerd.

Hoe zat het ook alweer?

Hoe zat het ook alweer met die ernstige kwetsbaarheid? Daarover schreven we in december al een achtergrondartikel, maar om het kort samen te vatten: beveiligingsonderzoeker Chen Zhaojun van Alibaba's Cloud Security Team vond in november een kwetsbaarheid in log4j, de standaard logginglibrary in Java. De kwetsbaarheid kreeg al snel de naam Log4Shell, omdat uitbuiting het makkelijk maakte om shelltoegang te krijgen tot een apparaat. In het begin leek het erop dat de bug kon worden uitgebuit door te zorgen dat een bepaalde string op een of andere manier in de logs verschijnt van software waarop log4j draait.

Log4j is opensourcesoftware en net als veel van zulke programma's wordt dat onderhouden door een handjevol ontwikkelaars die daar niet voor betaald krijgen. Toch kwam er al snel een patch beschikbaar. Veel systeembeheerders zagen al snel dat dat het probleem niet helemaal oploste. Johan: "Op zondagochtend hebben we weer vergaderd. Toen werd ons ook duidelijk dat de patch slechts een lapmiddel was en nog steeds niet alle kritieke problemen oploste." Het probleem met de nieuwe patch was dat denial-of-serviceaanvallen nog steeds mogelijk bleven. Bij niet-standaardconfiguraties van de library bleef het bovendien mogelijk om remote code executions uit te voeren. Weer andere onderzoekers ontdekten een manier om gevoelige data uit systemen met log4j te lekken. "Ik verwachtte dus in de loop van de week erna nog een nieuwe patch en die kwam er, meerdere zelfs", zegt Johan. "Op zondag hebben we met drie developers de patches doorgevoerd en werd alles klaargezet, zodat consultants op maandagochtend gelijk konden patchen."

De eerste aanvallen

In de eerste dagen na de bekendmaking van de kwetsbaarheid leek de paniek bij veel systeembeheerders en beveiligers net zo groot als bij Johan. Dat vertelt ook Robert Mengerink, die bij een bedrijf werkt dat beveiliging doet voor onder andere zorginstellingen en het midden- en kleinbedrijf. "Er werd een doemscenario voorgehouden toen deze bug bovenkwam. En in potentie was die aanname vooral de eerste week wel juist, vooral omdat de paniek en impact totaal niet te overzien waren."

In die eerste dagen werd dat doemscenario met cijfers gesteund. Veel systeembeheerders zagen al snel grote hoeveelheden scans en infiltratiepogingen, zowel op livesystemen als op de honeypots die ze later opzetten. Mengerink onderzocht in de weken na de exploit 'veel machines op indicators of compromise'. "We zagen echt doelgerichte aanvallen en aanvalspogingen, maar er zijn voor dit type exploits best nog veel afhankelijkheden."

Beveiligingsbedrijven zoals ESET zeggen dat ze met name in december een gigantische stijging zagen van aanvallen. In heel 2021 telde log4j mee voor maar liefst vijf procent van alle netwerkinfiltraties, terwijl de kwetsbaarheid pas in december aan het licht kwam.

Veel beveiligingsbedrijven draaiden honeypots waardoor spikes te zien waren. Daar waren de meeste onderzoekers unaniem over: honeypots werden overal aangevallen. Maar in alle paniek viel één ding ook op: het ging vooral om scans naar kwetsbare systemen en niet meteen om actieve aanvallen. Sommige onderzoekers viel het ook op dat veel scans juist afkomstig waren van andere beveiligingsonderzoekers.

Cryptominers en botnets

Er waren twee duidelijke manieren waarop Log4Shell direct werd misbruikt door aanvallers. Het werd ingezet om cryptominers te installeren en om apparaten op te nemen in botnets. Die soorten malware staan erom bekend dat ze kwantiteit boven kwaliteit verkiezen. Hoe meer apparaten kunnen worden geïnfecteerd met malware met een relatief laag risico, hoe beter. Onderzoeker Vesselin Bontchev merkt daarbij op dat veel van de URL's waarmee de miners moesten worden gedownload al kort na de bekendmaking van Log4Shell niet meer actief waren. "Sommige botnets implementeerden log4j-aanvallen en sommige aanvallers gebruikten het om toegang tot systemen te krijgen en zo cryptominers te installeren", vertelt hij aan Tweakers. "Dat is zeker geen apocalyps en zelfs die aanvallen zijn nu opgehouden."

Ook ziet Bontchev dat aanvallers toegang tot systemen doorverkopen aan ransomwaregroepen. Die kunnen het dan vervolgens gebruiken voor verdere aanvallen. Er is een voorbeeld bekend van aanvallers die informatie verkochten aan de beruchte Conti-ransomwarebende. Wat daarmee is gebeurd, is niet bekend. Conti kwam onlangs weer in het nieuws toen de bende informatie van woningcorporaties lekte op het internet, maar een link met Log4Shell is er niet. Het is nog onduidelijk hoe de criminelen daar binnenkwamen. In theorie zou dat via log4j kunnen zijn, maar Conti staat erom bekend voornamelijk via RDP binnen te komen.

Ook andere onderzoekers zien weinig concrete aanvallen buiten de paar automatische scans die zijn uitgevoerd tijdens die eerste dagen nadat de exploit bekend was. "Ik heb redelijk wat contacten in het veld en kan nou niet zeggen dat bedrijven gehackt zijn met log4j", zegt Robert Mengerink.

Moeilijk scannen

Dat zou kunnen komen omdat zelfs het scannen toch tegen leek te vallen, zegt ook een andere softwarebouwer waar Tweakers mee sprak. "Het scannen is niet altijd even makkelijk, vooral als Java als subcomponent gebruikt wordt. Dat wordt nog niet zo vaak opgepakt door scanners." Bovendien speelt mee dat veel applicaties die log4j gebruiken niet direct aan internet zijn gekoppeld. Die systemen vallen in een publieke scan niet op.

In het begin waren er wat beveiligingsonderzoekers die waarschuwden dat log4j kon worden misbruikt om lateraal door een netwerk te bewegen, want aanvallers die eenmaal 'in een netwerk' zitten, kunnen daarmee niet direct een hele organisatie platleggen. Daarvoor moeten ze zich eerst lange tijd stilhouden en verbindingen leggen tussen verschillende machines en netwerken. Met log4j zou dat in theorie makkelijk moeten zijn: geïnfecteerde server Alice hoeft alleen maar een simpel JDNI-commando naar server Bob te sturen en de aanvaller heeft toegang tot die laatste. "Dat zou natuurlijk kunnen," zegt Robert Mengerink, "maar op die manier zijn er buiten log4j veel meer bekende exploits bekend."

Het is moeilijk te zeggen hoeveel aanvallen er wel en niet hebben plaatsgevonden door het uitbuiten van Log4Shell. Misschien komen die nog, zegt Mengerink: "Entiteiten breken in door middel van log4j en plaatsen eventueel een achterdeur. Dan doen ze niks, laten het een paar maanden met rust en gaan dan pas weer verder via die ingang. Daar komen we pas achter als het te laat is." Hij voegt er meteen aan toe: "In de zaken die ik onderzocht heb, kan ik zeggen dat ik die manier van werken niet gezien heb."

Oorzaken

Wat in ieder geval duidelijk is, is dat grootschalige uitbuiting niet heeft plaatsgevonden. Er zijn niet veel méér ransomware-infecties geweest dan in een vergelijkbare periode een jaar eerder, of in ieder geval geen infecties die direct aan log4j te relateren zijn. De grote vraag is waarmee dat te maken heeft. Hadden beveiligers het mis toen het lek uitkwam? Of was de log4j-saga vergelijkbaar met de millenniumbug en werd er achter de schermen zo veel gerepareerd dat niemand merkte dat er iets mis was?

De uitblijvende ellende is waarschijnlijk een combinatie van goed patchen én moeilijke uitbuiting"Het saaie antwoord is dat het waarschijnlijk een combinatie van beide is", zegt Dave Maasland van ESET. Het vele patchen heeft zeker geholpen, denkt hij. Vesselin Bontchev bevestigt dat. Ook hij ziet dat er veel patches zijn doorgevoerd door de securityindustrie. "Dit was een prominente kwetsbaarheid die relatief makkelijk uit te buiten leek en waarvan ook aannemelijk was dat dat zou gebeuren. Door al die factoren komen beveiligers sneller in actie en voeren ze hun patches sneller door." Ook de verhalen van systeembeheerders als Johan bevestigen dat beeld.

Tegelijkertijd is nog steeds veel software kwetsbaar. De lastige scans die eerder werden genoemd, gelden ook voor interne scans: veel systeembeheerders weten simpelweg niet of ze nog kwetsbare systemen hebben. De doorgevoerde patches zijn dus maar een deel van het antwoord.

Te ernstig ingeschat

Beveiligingsonderzoekers denken ook dat Log4Shell misschien wel te ernstig werd ingeschat. Met name het uitbuiten ervan bleek lang niet zo simpel als in het begin werd aangenomen. Sommige aanvallen waren eenvoudig uit te voeren, zoals het installeren van een cryptominer of het meenemen in een botnet. Dat lukte nog wel met het versturen van één string met data. Maar een serieuze aanval opzetten, dat bleek een stuk moeilijker. "Hoewel de kwetsbaarheid overal in zat en makkelijk te exploiteren leek, was generieke exploitatie zonder goede kennis van het netwerk niet makkelijk", zegt Vesselin Bontchev.

Hij legt uit dat de kwetsbaarheid zich op veel verschillende plekken kon bevinden, bijvoorbeeld in een firewall of juist in het programma dat firewalllogs kan uitlezen, in een e-mailserver of browser of juist in een obscuur tooltje dat bijna niemand kent. "Om de kwetsbaarheid uit te buiten, moet je exact weten wat de kwetsbare software is, waar het zijn input vandaan haalt en dan zorgen dat malafide input op die manier wordt aangeleverd." En dan ben je er nog niet als aanvaller: "Je moet daarna ook nog een of andere vorm van feedback krijgen, zodat je weet of een aanval is gelukt of niet."

Dat is uiteraard niet onmogelijk om te doen, zegt Bontchev, maar het is een stuk moeilijker om een generieke exploit te bouwen die willekeurige IP-adressen scant en kwetsbare apparaten zoekt en daar vervolgens een exploit op probeert.

Meer kennis nodig

De eerdergenoemde programmeur zegt dat ook. "Een aanvaller die scant op kwetsbare systemen, moet weten wat er precies draait en hoe dat draait. Initieel stuurden aanvallers een payload naar elke http- of https-poort op een IP-adres, zonder de juiste hostnames of afwijkende endpoints te specificeren." Zoiets heeft volgens zowel onderzoekers zoals Bontchev weinig effect. Zelfs voor exploits met laaghangend fruit, zoals botnets, is dat niet zo makkelijk. Bontchev: "Botnets zoals Mirai probeerden in het begin veel te scannen en apparaten op te nemen, maar blijkbaar bleek de succesratio niet de moeite waard te zijn. Na een tijdje zijn ook zij gestopt met scannen."

Dave Maasland van ESET ziet dat het uitbuiten wel is geprobeerd door aanvallers, maar niet op een schaal zoals andere bekende kwetsbaarheden. Hij noemt de Citrix-kwetsbaarheid van 2020 en die op Forticlient-vpn's als vergelijking. "Doordat log4j in verschillende producten anders is geïmplementeerd, is het lastig om het op een dergelijke schaal uit te buiten. Dat bleek lang niet zo makkelijk en evident als vooraf gedacht. Een applicatie kon soms wel kwetsbaar zijn, maar niet op een manier dat het makkelijk uit te buiten was."

Met de details over Log4Shell was er ook wel direct een proof-of-concept beschikbaar dat aantoonde hoe het lek kon worden misbruikt, maar een werkende exploit liet langer op zich wachten. Voor een deel is dat omdat log4j zo anders werd geïmplementeerd, maar het speelt ook mee dat je met een dergelijke exploit niets verdient. Bontchev denkt dat als een bug als Log4Shell een paar jaar geleden bekend was geworden, er al snel een worm voor zou zijn gemaakt. "Dat is nu zeker nog wel mogelijk. Een dergelijke worm zou lang niet alle kwetsbare apparaten infecteren, maar wel genoeg om zichzelf te kunnen blijven vermenigvuldigen. Dan had er weer iemand anders een worm gemaakt die geïnfecteerde machines zou opsporen en de malware zou verwijderen. Maar zo werkt het niet meer. Hacken is tegenwoordig of door de staat gesponsorde spionage, of georganiseerde misdaad. Je verdient geen geld als je een worm loslaat op internet. Je verdient geld door een achterdeur te openen en die aan criminelen te verkopen of door een cryptominer te installeren. Dat is wat er nu ook is gebeurd."

Conclusie

De ernst van log4j maakte dat in december alle alarmbellen afgingen op beveiligingsafdelingen. Terecht, want log4j komt op zo veel plekken voor dat bijna iedereen wel kwetsbaar kon zijn. De vele patches die snel zijn doorgevoerd hebben volgens experts zeker geholpen bij het afwenden van een grootschalige ramp, maar de gevreesde apocalyps bleef achter en dat komt met name omdat experts de impact toch te hoog leken in te schatten. Log4Shell bleek in de praktijk veel moeilijker uit te buiten dan gedacht, omdat het verschil in hard- en software-implementaties groter bleek. Dat wil niet zeggen dat log4j een The Boy Who Cried Wolf-verhaal was. Het is niet te zeggen hoeveel systemen op dit moment nog geïnfecteerd zijn of bij welke aanvallen log4j ergens toch een rol speelde. Ook kan een aanvaller met genoeg wilskracht log4j nog steeds relatief eenvoudig inzetten voor een infectie, maar vaak lukt dat ook wel met zwakke RDP- of vpn-credentials.

Reacties (36)

[kodak]

de gevreesde apocalyps bleef achter en dat komt met name omdat experts de impact toch te hoog leken in te schatten.

Dat is geen redelijke conclusie. Er is namelijk niet duidelijk wat de gevreesde apocalyps zou moeten betekenen, er is zelfs niet duidelijk wat de schaal is dat het wel of niet ernstig genoeg zou zijn. Dus op basis van een maar het had niet dezelfde gevolgen als iets anders kun je achteraf niet stellen dat het te hoog of te laag was ingeschat.

Iets is niet zomaar minder enstig omdat er minder getroffen systemen zijn, aangezien het bijvoorbeeld ook gaat om het soort systemen en de omvang van afhankelijkheden daarvan.
Ook kan er niet zomaar door complexiteit gesteld worden dat het daar aan zou liggen, terwijl nagenoeg niet bekend is wat het op tijd patchen voor invloed had om hele grote problemen te voorkomen.

Het probleem is dus niet zomaar de complexiteit voor criminelen, maar een hele groot aantal onbekende factoren en het wel en niet mee willen en kunnen wegen van factoren.
Er is daarbij wel een mogelijkheid om via bijvoorbeeld een CVSS-score een inschatting te maken, maar niet om achteraf zomaar in het algemeen te gaan stellen dat de inschatting dus maar niet klopte. Dan is het ook niet redelijk om dat op willekeurige en bijna niet meetbare argumenten een algemene conclusie te trekken.
Een score als CVSS is daarbij zelfs al niet zomaar bedoeld om in het algemeen conclusies te trekken. Het vraagt om voldoende kennis van afhankelijkheden. Hoe willekeuriger er maar aannames worden gedaan, hoe groter de kans dat een uitkomst niet van toepassing is. Dus een 9.9 kan dan net zo goed een 7.5 zijn en andersom. Maar dat wil niet zeggen dat die 9.9 zomaar te hoog is ingeschat als er juist het probleem is dat heel veel gebruikers, leveranciers, fabrikanten en ontwikkelaars niet eens duidelijk genoeg hebben hoe afhankelijk ze er werkelijk van zijn.

[Reactie gewijzigd door kodak op 23 juli 2024 00:01]

[closefuture]

Ik snap echt niks van de conclusies die getrokken worden. Maar ook het stuk zelf staat vol met rare dingen. Neem bijvoorbeeld dit stuk:

Met name het uitbuiten ervan bleek lang niet zo simpel als in het begin werd aangenomen. Sommige aanvallen waren eenvoudig uit te voeren, zoals het installeren van een cryptominer of het meenemen in een botnet. Dat lukte nog wel met het versturen van één string met data. Maar een serieuze aanval opzetten, dat bleek een stuk moeilijker.

Als je een cryptominor kan installeren kan je alles installeren. Je hebt gewoon remote code execution (RCE) te pakken. Wat wil je nog meer? Dat de rest na de initiële entry ook nog voor je gedaan word ofzo? Hoe zou dat uberhaupt werken? Natuurlijk heb je na entry dat je moet kijken hoe je je toegang vanuit daar gaat uitbreiden. Hoe je administrator rechten gaat krijgen, hoe je op andere servers komt, etc.

[lenwar]

Natuurlijk heb je na entry dat je moet kijken hoe je je toegang vanuit daar gaat uitbreiden.

Hier geef je je eigen antwoord al. Bij de meest succesvolle aanvallen bleek dus dat de aanvaller ‘slechts’ met lage/‘weinig’ privileges de code kon uitvoeren.
Dat is in de regel natuurlijk al ernstig genoeg en drie stappen te ver, maar de aanvaller kon blijkbaar moeizaam/niet, bij bedrijfsdata, beschikbaarheid aantasten, enz, enz.

[berchtold]

Kwetsbaarheden op zichzelf leveren meestal ook weinig op. Maar als je nu low-priv hebt en je hebt een escalation kwetsbaarheid die je kan gebruiken …

[lenwar]

Uiteraard, zoals ik al zei is het überhaupt binnenkomen al erg genoeg en drie stappen te ver. Maar blijkbaar kwamen ze dus met deze kwetsbaarheid niet verder dan dat (of in elk geval niet op grote schaal). (Zoiets als inbreken tot in de hal, maar niet in de woonkamer kunnen komen - Het is al niet goed dat ze in de hal konden komen, maar de waardevolle spullen lagen in de woonkamer)

[The Third Man]

Ja en wat wil je precies op een CPU gaan minen tegenwoordig, dat is toch klein bier? Ik zou eerder verwachten dat men machines voor botnets inzet of bijvoorbeeld relays voor spam of ander verkeer. Het noemen van een cryptominer installeren als voor de hand liggend bij RCE voelt wel heel populair geschreven…

[zaphod_b]

Dat is inderdaad klein bier. Totdat je er 10.000 hebt geïnfecteerd en je 10.000 keer klein bier binnenharkt. Dat is een aardige vrachtwagen bier, genoeg voor een heel studentencorps .

[lenwar]

Maar om verkeersrelays te creëeren heb je vaak wel hogere rechten nodig en dat lukte hier dus niet. Op Linux of UNIX-achtige systemen heb je root-rechten nodig om op lage poorten te werken. (Windows zou ik eigenlijk niet weten, maar ik verwacht dat ook wel). Ook worden die poorten vaker beter gemonitord, juist omdat dit zo veel gebeurd.

Zoals @zaphod_b al aangeeft is het ook een kwestie van grote getallen. 1 kind van 10 kan een gezonde volwassen man niet aan, maar met 30 goed georganiseerde kinderen van 10 die op je in staan te timmeren/schoppen kunnen dat wel. (wel eerder ook). Één CPUtje laten minen (zonder dat het opvalt ook nog) schiet inderdaad niet op, maar als jij een miljoen CPUtjes laat minen voor je zal je toch wel iets hebben denk ik? (geen ervaring mee, maar ik kan het me zo voorstellen)

[The Third Man]

Één CPUtje laten minen (zonder dat het opvalt ook nog) schiet inderdaad niet op, maar als jij een miljoen CPUtjes laat minen voor je zal je toch wel iets hebben denk ik? (geen ervaring mee, maar ik kan het me zo voorstellen)

Natuurlijk als je van iedereen in Nederland een cent krijgt ben je aardig binnen. Maar mijn punt is dat het relatief tot andere inkomstenbronnen nou niet heel hard loopt, vandaar dat ik me afvroeg of botnets oid niet meer voor de hand zouden liggen.

[Tubby]

ja; de RCE werd wel wat extreem ingeschat.

De meeste Java applicaties draaien niet met admin rechten omdat dat niet nodig is en in feite is een Java VM al een sandboxed Virtual Machine met beperkte mogelijkheden en laten we realistisch zijn. Wanneer heb je dat nou nodig?

Het "enige" wat wel mogelijk zou zijn is op bestaande (db) connection pools queries gaan uitvoeren en de results daarvan via java libs richting eigen upstream streams toe uploaden. Dat is blijkbaar een vrij lastig exploit scenario gebleken.

En gelukkig waren er ook best wel wat fixes die toegepast konden worden (met en zonder dat applicaties opnieuw gecompileerd moesten worden)

[Tonkie1967]

Wat je noemt is niet het enige probleem met het artikel.kijk alleen maar naar Johans baan: soms systeembeheerder en dan weer programmer...
En ook de conclussies zijn vreemd.
Maar wil wel wat ervaringen van mezelf delen. Week bij een grote hardware en systeem fabrikant die PC's, laptops, servers, storage en netwerk equipment maakt. Zelf werk ik als escalation engineer voor onze networking systems en onze eigen system waren niet vulnerable. Alleen 1 bepaald systeem (mx7000 chassis) was gettoffen waarbij networking zijdelings bij betrokken kan zijn maar desondanks waren we er druk mee: vragen van klanten beantwoorden, scanned en patchen van onze tech support lab omgevingen in Halle, Montpellier en Dublin. Overleg met engineering van MX (compute en networking) over verwachtte patch release date. Voor MX hebben we normaliter 2 versies per jaar en de laatste was net 2 dagen unit toen 1e melding kwan. Uiteindelijk besloten om binnen een week een extra patch uit te brengen bovenop de net releasde versie 1.40.00.. En begin Jan 22 ook een patch voor oudere release/baseline 1.30.10 omdat niet alle klanten Hun hele chassis naar baseline 1.40.xx willen of kunnen brengen.
En voor klanten die nog op baseline 1.20.xx zaten brachten we een versie uit waarbij alleen het vulnerable element naar 1.30.20 werd gebracht maar verder alles op 1.20.xx blijft...
Dus als support engineer van een niet direct gettoffen product line toch heel druk....
Bovendtaande puur ter illustratie wat de impact was bij een grote hardware en systeem fabrikant (voorheen vooral bekend als dozenschuiver.. )

[Muncher]

Ik krijg een beetje Y2K vibes bij dit artikel. Daarvan werd achteraf ook gezegd: zie je wel, er was niets aan de hand. Daarbij werd wel voorbij gegaan aan het feit dat er enorm veel werk is verzet door allerlei organisaties om het probleem op te lossen. Dat is bij Log4J ook gebeurd, voor zover ik kan zien.

Ja, de informatievoorziening en inschatting vanuit de verschillende partijen had beter gekund. En ja, de tooling leverde wel eens false positives op. Dit neemt niet weg dat menig sysadmin/securitypersoon/opsengineer die weken enorm veel werk hebben verzet om in kaart te brengen waar eventuele problemen zaten, deze te verhelpen of maatregelen te treffen zodat echt grote problemen uitbleven. Het is de preventieparadox in optima forma, iets waar security medewerkers op dagelijkse basis mee te maken hebben,

Bijkomend voordeel is dat veel organisaties hun hele toeleveringsketen hebben doorgenomen (welke leveranciers hebben we, welke zijn kwetsbaar, etc) en intern beter inzichtelijk hebben kunnen maken waar welke software draait (al dan niet op package/library niveau).

Het had inderdaad allemaal veel erger kunnen zijn.

[slaapkopje]

Wat mij opviel bij log4shell, was de hogere bereidheid en het begrip om te patchen. Het vervangen van de log4j jar's is niet zo moeilijk, maar vroeger werd het nogal eng gevonden, maar nu ging het vrij geruisloos.

Het is zeker geen overdreven paniek om te patchen, want het gat is aantoonbaar. En ook al is het niet direct aan te vallen, je weet nooit wanneer zoiets toch nog misbruikt wordt om lateraal door je netwerk te hoppen. log4shell is al toegevoegd aan de attack playbooks. Het is een simpele manier om een remote code execution te krijgen. Een bitcoinminer of botnet is een teken dat de attacker het gat meteen te gelden wil maken, hij kon er ook voor kiezen je direct aan te vallen. Dat is net ze simpel.

[Polderviking]

Wat mij opviel bij log4shell, was de hogere bereidheid en het begrip om te patchen. Het vervangen van de log4j jar's is niet zo moeilijk, maar vroeger werd het nogal eng gevonden, maar nu ging het vrij geruisloos.

Is psychologisch toch niet heel raar.
Als je verantwoordelijk bent voor productieverlies als gevolg van aan servers trekken werken reguliere updates mentaal nets iets anders dan iets wat echt moet omdat er een acuut risico is op iets met ernstige consequentie voor je data.
Het verhaal was immers "mensen lopen gewoon bij je naar binnen", dan is het risico van wat down time opeens een peuleschil en worden dingen als teststraten overgeslagen (en mag het eventueel geld kosten door het gewoon helemaal uit de lucht te halen).

Kleine dreiging overstemt door grote dreiging.

[Reactie gewijzigd door Polderviking op 23 juli 2024 00:01]

[Transportman]

Deze was groot in het nieuws en dan is er opeens wel ruimte om snel te handelen, want niemand wil het voorbeeld zijn dat ieder nieuwsbericht genoemd wordt omdat ze geen actie hadden ondernomen.

Kromme is inderdaad ook wel, hier is meteen actie op ondernomen, maar de klant waar ik voor werk heeft nog genoeg draaien met oude niet meer ondersteunde versies van allerlei software en dat vinden ze allemaal prima, want dat komt niet groot in het nieuws en "het werkt toch?".

[Dreacus]

Ja, dit dus. Ook bij een klant van ons veel haast haast. Bleek enkel in een kleine externe module aanwezig te zijn... Maar dan wel een versie die al jaren niet meer ondersteund werd, en 'dus niet geraakt werd'. Dat er dan uberhaupt geen security support meer voor is en dus mogelijk kwetsbaar voor andere, niet gemelde risico's is dan niet relevant voor ze. Zucht.

[Polderviking]

Ik hoop vooral op meer aandacht voor dependancy gebruik door dit soort incidenten.
Heel veel bedrijven (software leveranciers) moesten uitzoeken wat dit inhield voor hun software in plaats van dat ze dat ergens gedocumenteerd hebben staan waar ze de betreffende module voor gebruiken.

En misschien ook wat meer geld of mankracht naar de Apache Foundation uit de enterprise wereld.

Ontzettend dure softwarepakketten die op dit soort modules leunen waar de Adobe's van de wereld bizarre sommen geld aan verdienen.
Ondertussen loopt het gehele internet op software uit de stallen van Apache in meerdere of mindere mate maar ze doen het op jaarbasis met 1 tot 2 miljoen aan donaties ofzo.

[Reactie gewijzigd door Polderviking op 23 juli 2024 00:01]

[elmuerte]

Er zijn maar weinig developers van Apache Foundation software die door Apache Foundation betaald worden. De meeste developers zijn in dienst van andere bedrijven.
Maar je punt is wel terecht, er zijn veel bedrijven die niks teruggeven aan de Apache Foundation terwijl een groot deel van hun business wel draait op het werk van van deze community.

[gimbal]

log4j upgraden is vrij triviaal en impactloos dus die apocalypse was niet erg waarschijnlijk. We waren de meeste tijd kwijt aan achterhalen waar log4j stiekem mee was gepackaged eigenlijk.

De recente bug met betrekking tot certificates... dat was en is een tikkie vervelender omdat er JDKs met haastige spoed geupdate moesten worden. En dan kom je erachter dat systemen nog AdoptOpenJDK draaien die nu obsolete is dus dan moet je ineens weer over op Eclipse Temurin voor de laatste patches. Olievlek.

[Transportman]

Als je bij bent met software en LCM was de upgrade van log4j2 vrij triviaal omdat de meeste softwareleveranciers vrij snel met patches waren waarin alleen de bijgewerkte log4j2 zat. Alleen zijn veel organisaties zaken als updates en LCM sluitposten en zijn ze helemaal niet bij, waardoor iets dat een kleine upgrade zou zijn, opeens toch een gigantische upgrade is.

Maar leren er van en zorgen dat ze toch bij zijn en bij blijven? Nee, dat dan weer niet.

[scsirob]

Dus doordat iedereen alles ging scannen werd het een self-fulfilling prophecy. Zo maak je elkaar wel gek. Maar wat ik ook uit het verhaal opmaak is dat er nog heel veel apparatuur met deze kwetsbaarheid rondzwerft die *nog* niet aan het internet hangt, maar dat in de toekomst mogelijk wel zal zijn. Dus dit blijft op de achtergrond nog wel even doorsudderen.

Terzijde: Uit de tekst is vrij makkelijk op te maken dat "Johan" een dame is, er is wat slordig met de zoek/vervang functie omgesprongen?

[_Pussycat_]

Leuk artikel, met dank!! Had hem al helemaal vergeten... Ik hoop niet dat er een Y2k-verhaal van wordt; daar hebben alle gewone mensen in de werkvloer het er altijd over dat "er helemaal niks aan de hand was", de ultieme preventieparadox.

[Reactie gewijzigd door _Pussycat_ op 23 juli 2024 00:01]

[Transportman]

Ik denk dat enorm scheelde dat er vrij snel mitigerende maatregelen bekend waren met relatief weinig impact, en dat het risico voor (grote) partijen al snel vrij beperkt was doordat dat alle naar buiten gaande verbindingen vandaf servers dicht staan (beveiliging met meerdere lagen).

[Kwistnix]

Is 'waterscheidingsmoment' niet wat letterlijk vertaald vanuit het Engelstalige 'watershed moment'. Is er iets mis met keerpunt?

OT: Wat mij betreft was het een beetje een storm in een glas water, in ieder geval voor veel van de Java gebaseerde oplossingen waar ik op het moment mee werk. Het gaat nu zelf zover dat de vulnerability scanner die periodiek m'n laptop scant, continue log4j versies die ergens in mijn lokale Maven cache hangen, aanmerkt als kritieke kwetsbaarheid.
Van een andere collega ZZP-er begreep ik dat vanuit management bij zijn klant de beslissing is genomen om Log4J volledig te bannen als dependency. Gaat nergens over natuurlijk.

[tvdweij]

Zeer ergerlijk taalgebruik, zelfs al mocht het toch een obscuur Nederlands woord zijn.

[The Third Man]

Eerste wat me opviel toen ik de tekst las inderdaad, heb ook een hekel aan overduidelijk letterlijke vertalingen. Kranten krijgen helaas hier tegenwoordig ook een handje van. Ik zou inderdaad ‘keerpunt’ gebruiken of ‘aardverschuiving’ als het wat groter is.

[tweaker2010]

Log4j werd in veel organisaties verkeerd geïnterpreteerd. Wat je zag is dat zelfs directies en management zich ineens met techniek gingen bemoeien waar ze geen verstand van hebben.

Om te beginnen, hoe ga je scannen. De meeste systemen maakten er geen actief gebruik van log4j, maar als je maar hard genoeg roept dat er een security incident is terwijl er feitelijk nog geen (actief) misbruik van is gemaakt, schiet iedereen al snel in de paniek. Je kan hooguit wat servers uitzetten als er geen patch is.

Resultaat is dat er een volgende keer de schouders wordt opgehaald als het NCSC de zoveelste high-high afkondigd.

[elmuerte]

Misschien als het NCSC want minder blundert in hun informatie voorziening.
Bijvoorbeeld in de log4j verhaal, als je letterlijk het advies van NCSC overneemt dan ben je _niet_ beschermt, want de informatie was verkeerd. In 1 van de advies gebruikten ze een n-dash '–' ipv van het min teken '-'. Dat maakt nogal een verschil in interpretatie van commandline argumenten. Een ander deel van het advies bevatte verkeerde variabele namen.
Recentelijk voor de JRE issue mbt null ECDSA signatures hebben ze ook foutieve info dat het ook versies voor Java 15 betreft, terwijl dat niet waar is.
Deze foute informatie staat er allemaal nog steeds.