KVK haalt website en diensten dit kerstweekend offline vanwege log4j

Vanwege de log4j-kwetsbaarheid zijn de website en diensten van de Kamer van Koophandel dit weekend niet beschikbaar. De Kamer haalt deze diensten offline vanwege de kwetsbaarheid in log4j, om zo aanvallen te kunnen voorkomen.

Alle online diensten zijn van vrijdag 18.00 uur tot maandag 7.30 uur niet te gebruiken, zegt de KVK. Het gaat om het Handelsregister, UBO-register en LEI-register. Het aanleveren van documenten zoals jaarrekeningen is dan ook niet mogelijk. Aansluitingen op de api van het KVK, de KVK Dataservice en KVK App Handelsregister zijn eveneens niet mogelijk.

De Kamer zegt de diensten offline te halen naar aanleiding van een waarschuwing van het Nationaal Cyber Security Centrum over de feestdagen. Criminelen zouden deze volgens het NCSC mogelijk gebruiken om met de log4j-kwetsbaarheid IT-systemen aan te vallen. De Kamer zegt haar gegevens te willen beschermen en zegt dat ze onderdeel is van 'verschillende ketens met andere partijen', waarbij de log4j-kwetsbaarheid ook misbruikt zou kunnen worden.

Daarom worden 'in ieder geval gedurende de kerstdagen' de online diensten offline gehaald. Verder meldt de Kamer sinds de NCSC-waarschuwing extra maatregelen te hebben getroffen, zoals continue monitoring en het uitvoeren van updates en patches zodra deze beschikbaar zijn.

De NCSC waarschuwt niet alleen de KVK voor de log4j-kwetsbaarheid en de kerstdagen, ook andere bedrijven krijgen van de NCSC het advies om alert te zijn. Tweakers schreef eerder een achtergrondartikel over log4j-library-kwetsbaarheid Log4Shell.

Reacties (105)

[Wraldpyk]

Wel opvallend dat het nu pas offline gehaald wordt, terwijl deze kwestbaarheid al eventjes bekend is. Veel websites die hier last van hebben zijn allang gepatched door updates te installeren. En ook kwalijk dat ze eerst een melding moeten krijgen.

Toen het uitkwam gingen wij gelijk kijken of we geimpact waren, en dezelfde dag hadden we al een rapport klaar dat we dat niet waren, en waren klanten van ons geinformeerd dat er problemen waren waar dat nodig was. Dit was allemaal binnen 24 uur geregeld.

Degene die bij de KVK in dienst is die deze dingen op z'n bureau heeft qua functieomschrijving had meteen moeten weten dat ze 't gebruiken, of maximaal een paar uur aan research moeten besteden.

[wildhagen]

Wel opvallend dat het nu pas offline gehaald wordt, terwijl deze kwestbaarheid al eventjes bekend is.

Niet zo raar, als je bedenkt dat de komende week de bezetting zeer dun is bij veel bedrijven, ook op IT-afdeligen, ivm verlof etc. Je kunt dan minder snel op actuele ontwikkelingen inspringen.

Veel websites die hier last van hebben zijn allang gepatched door updates te installeren. En ook kwalijk dat ze eerst een melding moeten krijgen.

Helaas is dat niet zo makkelijk altijd, omdat je ook met compatibiliteit-testen etc zit in hele complexe produktieketens. Wij hebben over alle klanten verspreid vele duizenden applicaties, dat patch je niet in een week tijd, zonder grondig alles te testen.

[djexplo]

As a cyber security analyst, you will protect IT infrastructure (including networks, hardware and software) from a range of criminal activity. You will monitor networks and systems, detect security threats ('events'), analyse and assess alarms, and report on threats, intrusion attempts and false alarms, either resolving them or escalating them, depending on the severity.

Dit is wat veel mensen vergeten. Bij de grotere bedrijven zijn er 24uur per dag medewerkers die continue allerlei systemen, in de gaten houden van netwerk-logs, log in attemps, tot antivirus warnings.
Eigenlijk net als de bewaker, die beneden bij de deur zit/staat. Dat wil niet zeggen een bedrijf de beveiling niet op orde heeft. Maar juist een bedrijf die gelijk iemand paraat heeft om in te grijpen. Die ook al verdachte situaties kan linken zonder dat de indiviuele tools het opmerken.

Het is dus helemaal niet gek dat bedrijven bepaalde services niet beschikbaar hebben in het weekend, of tijdens feestdagen.

Je wilt niet na kerst terug komen, en zien dat er 1000en mislukte inlog attemps zijn geweest op verschillende user-accounts en dat nummer 1001 blijkbaar succesvol was en nu al je netwerk drives zijn ge-encrypt.

[init6]

De vraag is of een dienst offline moet. Ik hoop toch altijd dat diensten failover methodes hebben of een fallback.

Daarnaast: Dit is niet tijdens kerst gebeurt. Ik snap niet zo goed waarom de feestdagen erbij gehaald worden, maar dit is op 9 of 10 December gemeld. In mijn omgeving is dat een eeuwigheid geleden.

Sinds een paar jaar is het ook niet abnormaal om meerdere services te draaien van 1 applicatie, ik snap dat heel wat instellingen nog in het jaar kruik opereren, maar misschien dat dit soort momenten een wake up call kunnen zijn dat er zoiets is als high availability, microservice architecture, load balancing etc word bekeken... Daarnaast je testen zoals unit test, contract tests, api tests, integration tests beter inrichten zodat je sneller kan uitrollen is ook niet iets wat abnormaal is.

Die duizenden meldingen zagen wij al de eerste paar uur, heb al gesproken met partijen die datzelfde weekend miners hadden draaien op hun clusters. Nu pas wat ondernemen... Als KVK klant ben ik nu erg bang dat mijn data op straat ligt, zoveelste keer al dit jaar door een overheids instelling.

[Heroic_Nonsense]

Twee redenen: bezetting: er is weinig personeel paraat en men wil iedereen ook een rustige kerst gunnen na alle weken overwerk die dit lek met zich meebracht.

De tweede: Russische hackers zijn tijdens de kerst zeer actief; een soort traditie. Men weet ook dat de bezetting bij hun prooien minimaal zal zijn deze dagen natuurlijk.

[Frame164]

Daarnaast: Dit is niet tijdens kerst gebeurt. Ik snap niet zo goed waarom de feestdagen erbij gehaald worden, maar dit is op 9 of 10 December gemeld. In mijn omgeving is dat een eeuwigheid geleden.

Of het snel opgelost kan worden hangt helemaal van de situatie en complexiteit af. In een simpel netwerk met slechts een paar applicaties kan het inderdaad heel snel worden opgelost. Bij mijn klanten worden nu plannen gemaakt om de eerste applicaties in januari te gaan patchen, domweg omdat het niet eerder kan. De meeste services die zijn bieden bestaan uit een keten van applicaties. En je zult voordat je de patches in productie uitrolt toch echt eerst end-to-end moeten verifiëren of het allemaal blijft werken.

[MadEgg]

Want als je alles uitzet met kerst blijft het werken?

Bij het bedrijf waar ik voor werk is in een periode van 1 week een enorm applicatielandschap tweemaal gepatched, eerst naar 2.15 en later naar 2.16. Als je dat niet snel kunt uitrollen met vertrouwen heb je je testprocessen niet op orde.

Mocht de upgrade echt niet kunnen kun je altijd nog de boosdoener, JndiLookup.class verwijderen uit je applicaties. Geen dependency checks en geen kwetsbaarheid meer.

En ook met kerst moet je natuurlijk een fatsoenlijk standby team hebben die de boel in de gaten houdt.

Maar voor een semi-overheidsbedrijf als KVK is dat natuurlijk niet weggelegd. Blijkbaar is security een ondergeschoven kindje en availability niet erg belangrijk. Is ook een keuze.

[Sterk1]

Volgens mij hebben jij en vele anderen geen idee hoe het werkt bij grote bedrijven / instanties.

De afgelopen jaren heb ik bij veel van dit soort bedrijven gewerkt. Je ziet dat ze last hebben van de wet op de remmende voorsprong.
In de jaren 70 begonnen met de automatisering en in 50 jaar tijd is dat stap voor stap geëvolueerd tot de huidige ICT omgeving, waarbij tientallen applicaties aan elkaar zijn geknoopt.

Dit is dus heel anders dan dat je een paar jaar geleden met een greenfield mocht beginnen. Veel van die grote bedrijven hebben wel geprobeerd om die spaghetti op te ontwarren, maar dit bleek in de praktijk enorm tegen te vallen en zeer kostbaar te zijn.

Aangezien niet iedereen het leuk vindt om met Kerst te werken en de meeste hackers weten dat de waakzaamheid en bereikbaarheid dan minder is, is met kerst de ideale tijd om flink los te gaan. Heel verstandig dus van de KvK om het zekere voor het onzekere te nemen en met kerst even dicht te gaan.

Zeker nu men verwacht dat er nog wel meer kwetsbaarheden in de log4j code zitten. 2.16 is echt niet de laatste patch in 2021.

[MadEgg]

Tja wat is groot. Duizenden medewerkers waarvan tegen de 1000 IT’ers. Honderden interne en externe applicaties. Niet uit de jaren zeventig maar dat is, met alle respect, ook geen excuus. Bedrijven die toen bestonden hebben hun wagenpark ook wel eens vervangen. Of hun kantoor. In de jaren zeventig bestond log4j 2 ook nog niet. Legacy applicaties gebruiken vaak nog log4j 1 die niet kwetsbaar is.

Je moet je ICT gewoon op orde hebben als het een deel van je core business is. Zoals bij de KVK. Je hoeft niet met 1 ICT’er alles te patchen. Werk met een taskforce die de kwetsbaarheid onderzoekt en de mogelijke mitigaties in kaart brengt en laat die de rest instructies geven hoe en wat ze moeten doen.

Ik blijf erbij, ongeacht je schaal, als je niet binnen een week of 2 een kwetsbare dependency in je applicatielandschap kan traceren en vervangen heb je de boel niet goed op orde.

[ReTechNL]

Honderden, zoniet duizend applicaties welke hiervan gebruik maken. Allemaal applicaties die door derde partijen zijn ontwikkeld en door klanten zijn aangeschaft. Wel dan niet in beheer bij een it partij wat ook weer een 3de partij is. Het detecteren van de kwetsbaarheid is het probleem niet. Het contacten van klanten en leveranciers die op hun beurt ook weer eventueel maatwerk applicaties hebben geleverd aan het werk zetten om dit probleem te verhelpen duurt soms wel even. Vaak zit het ook nog nested in applicaties verwerkt.

[Reactie gewijzigd door ReTechNL op 22 juli 2024 15:23]

[laptopleon]

Heeft er volgens mij meer mee te maken dat het een (semi)overheidsorganisatie is. Die hebben wel vaker grote moeite om de zaak veilig etc te houden.

Amazon, Bol, Apple, gaan nooit een paar dagen dicht omdat iets niet op tijd gepatcht is.

[Sterk1]

Inderdaad kan de overheid haar tent dichtgooien tijdens de feestdagen, nat als de banken met Pasen altijd doen.

Je winkel dichtgooien is voor Bol en Amazon inderdaad lastiger, maar hun applicatie landschap is een stuk jonger.

Al met al een beetje appels met peren vergelijken.

[MadEgg]

Nee, dat zijn gewoon smoesjes, geen appels en peren. Grote organisaties, veel applicaties. Appels met appels. Als ze ononderhoudbaar zijn is dat een aanvullend probleem, niet een excuus voor niet adequaat handelen naar deze kwetsbaarheid.

[Kabouterplop01]

Ik blijf erbij, ongeacht je schaal, als je niet binnen een week of 2 een kwetsbare dependency in je applicatielandschap kan traceren en vervangen heb je de boel niet goed op orde.

eensch, maar 2 weken vind ik wel heel lang.

[9000rpm]

Helaas is versie 1.2 weldegelijk lek voor een zelfde issue. Doordat 1.2 al een paar jaar wil is is dat echter niet zo urgent meer. De llog4j wordt op dit moment actief geexploit een er zijn ook al bedrijven geransommed.

Link naar lek in log4j 1.2
https://www.cvedetails.com/cve/CVE-2019-17571/


Voor log4j 2 kun je met lijsten snel kijken of een applicatie vulnerable is:
https://github.com/cisago.../develop/SOFTWARE-LIST.md

Tot de een scanner gebouwd hebt in powershell die snel de kwetsbare versies opspoort.

[nullbyte]

Zeker nu men verwacht dat er nog wel meer kwetsbaarheden in de log4j code zitten. 2.16 is echt niet de laatste patch in 2021.

Niet alleen log4j, alle open libraries zullen doorgespit worden

[MadEgg]

Net zoals altijd. Closed source ook trouwens.

[Metalfreak]

Waarom toch altijd dat beschuldigende vingertje en die houding van "kijk ons eens goed bezig zijn"?

Het komt niet in je op dat misschien de ICT-ers al compleet overwerkt zijn door het gedoe van de afgelopen tijd en dat ze nu gewoon de afweging gemaakt hebben om het zekere voor het onzekere te nemen en de diensten gewoon offline te halen omdat ze weten dat die diensten tijdens de kerst toch nauwelijks worden geraadpleegd? En we hebben de afgelopen werken ook gezien dat je vandaag alles gepatcht kunt hebben om vervolgens de volgende dag op je werk te komen en weer van voren af aan te moeten beginnen. Misschien dat ze hun mensen gewoon ook eens even de rust gunnen. Is het nu echt een drama dat die diensten er op 1e en 2e kerstdag uit liggen? Wie heeft er precies écht last van?

Er is een groot tekort aan ICT-ers, dus misschien hebben ze inderdaad dat standbyteam momenteel niet op orde of kiezen ze ervoor om dat minimaal uit te voeren tijdens kerst, want ja, mensen hebben ook wel eens behoefte om eens niet aan hun werk te hoeven denken. Ik weet dat dat soms voor mensen hier op de frontpage onbegrijpelijk is, maar laten we de menselijke maat niet vergeten.

[jmvdkolk]

Ik vind dit wel lastig. Volgens mij heb je de keuze tussen:
1. Patches meteen uitrollen met het risico dat services het tijdelijk niet doen
2. Patches niet uitrollen en bijna zeker weten dat je services het ergens in Q1 van 2022 niet meer doen omdat je ransomware binnen hebt gekregen

De vraag is dan welke van de twee outages erger is.

[vinsterdamus]

Ik werk voor een grote organisatie wat vitaal is voor de Nederlandse markt en in mijn ervaring hebben we dit probleem kunnen oplossen binnen een week. Dit heeft veel tijd en aandacht gekost maar we moeten niet vergeten dat het voor veel applicaties een update van je dependency management systeem is. Letterlijk een update van 1 tot 3 cijfers in iets anders. Voor vendor applicaties is het natuurlijk anders of wanneer het gaat om servers die tal van applicaties in grote webservers. Maar wanneer wij met onze 3000 plus applicaties dit kunnen fixen dan moet een KVK dit ook kunnen zou ik zeggen.

[geerttttt]

Nou ja binnen een paar uur patchen is niet zo gedaan met deze CVE. Het probleem is dat het overal bijna in zit en je het ook moeilijk overal kan vinden.

[MadEgg]

Het is Java, dus je zoekt op .jar, .war en eventueel .class files naar log4j2 en jndilookup. Waar gevonden sloop je dat eruit of patch je. Laten we het niet moeilijker maken dan het is.

[Sterk1]

Hier is de lijst met kwetsbare applicaties.
Tel en huiver

https://github.com/cisago.../develop/SOFTWARE-LIST.md

geen idee wat wel en niet werkt na je find en replace.
Ook lekker zoeken welke replace je incident veroorzaakt. Je changemanagers gaan waarschijnlijk op tilt als een systeembeheerder zo los gaat.

[MadEgg]

Als je testlandschap op orde is vervang je je dependencies en draai je de testsuites. En als het goed is is er voor elke applicatie in gebruik een of enkele personen die verantwoordelijk zijn voor die applicatie zodat ze ook verantwoordelijkheid kunnen nemen voor het patchen van de applicatie.

Als dat allemaal niet het geval is heb je je zaakjes niet op orde en is je website met kerst dichtgooien niet meer dan symptoombestrijding. Twee weken geleden was het log4j maar volgende maand is het weer een andere kwetsbaarheid. Ze volgen elkaar aan de lopende band op dus je moet altijd alert blijven en patches blijven uitrollen.

[Sterk1]

In theorie heb je helemaal gelijk.
Helaas heb ik nog geen grote organisaties / bedrijven gevonden met enorme legacy applicaties die dit zo mooi op orde hebben.

[geerttttt]

Nou ja het gaat niet om je eigen applicatie x, maar mogelijk om elke willekeurige server of pc die in je bedrijfsnetwerk actief is. En wat dacht je van zips met daarin applicaties die log4j gebruiken, of software op sticks, of byod? Noem maar op...

[XBL]

De verwachting is dat systemen die al gehackt zijn, maar waarbij dat niet gedetecteerd is, tijdens de feestdagen misbruikt zullen worden (ransomware activeren oid). Dit omdat er veel minder adequaat gereageerd kan worden bij veel bedrijven, als de IT'ers aan de kerstdis zitten.

[anboni]

Daarnaast: Dit is niet tijdens kerst gebeurt. Ik snap niet zo goed waarom de feestdagen erbij gehaald worden, maar dit is op 9 of 10 December gemeld. In mijn omgeving is dat een eeuwigheid geleden.

Die hack bij Universiteit Maastricht is ook niet met kerst gebeurd. De infectie was half oktober. Met kerst hebben de criminelen wel de trekker overgehaald. Ik zal echt geen moment verbaasd zijn als er deze kerst wereldwijd tientallen of zelfs honderden bedrijven het haasje zijn.

[CodeCaster]

Hoe zie je die termen voor je qua implementatie? Dat een platform dubbel wordt uitgevoerd, maar dan op een totaal andere technologiestack? Want je kunt schalen tot je een ons weegt, maar als de core nog steeds op Java draait en je wil loggen, dan gebruik je de facto log4j.

[Reactie gewijzigd door CodeCaster op 22 juli 2024 15:23]

[supersnathan94]

Nee. Die van 9 en 10 december waren leuk, maar dat is ws al gemitigeerd. De NCSC heeft deze week een nieuwe advisory afgegeven met daarin een aantal waarschuwingen voor nieuwe hacks deze week.

Dit is niet nu pas wat ondernemen. Dit is ju extra maatregelen treffen.

[ceesiebo1]

9 December is inderdaad de meldingsdatum. Maar de kwetsbaarheid bestaat al sinds 2013. Ik maak me vooral zorgen dat dit niet al veel langer misbruikt wordt. Veel van de systemen die ik ken gebruiken Log4J V1 en daar schijnt de kwetsbaarheid niet in te zitten. Daarnaast is het ook nog eens zo dat dus heel veel bedrijven afhankelijk zijn van vrijwilligers die dit in hun vrije tijd nu aan het patchen zijn zoals de meeste open source software. Er zit niet echt een bedrijf achter. En omdat software tegenwoordig vaak samengesteld wordt uit libraries die weer libraries gebruiken dat het bijna ondoenlijk is om alles te blijven controleren. Ook Black Duck kijkt alleen maar naar meldingen op OS libraries.

[Ossebol]

Het vervelende aan de Log4j-kwetsbaarheid is dat je nog steeds kwetsbaar kunt zijn, óók als je alle systemen hebt gepatcht.

Toen het lek net bekend was, was het bijna helemaal zeker dat je binnen kon komen. Als je een aanvaller bent die écht schade wil toebrengen aan ondernemers of Nederland in het geheel, dan zorg je dat je een backdoor hebt, en blijf je voorlopig in stealth-modus. Zo kun je ook binnenkomen ná het patchen.

De gedachte dat de systemen met Kerst offline gaan is niet vreemd. Zoals hier eerder gezegd, zijn de meeste medewerkers dan vrij (en dus groter slagingspercentage voor een aanval).

[aikebah]

Dan mis je er heel veel hoor. Je moet een grep doen voor iets met een l, een d, een a en een p... en dan nog vang je niet alles. Jouw grep vangt alleen de simpele profiteurs, niet de cybercriminelen waar je het meest geducht voor moet zijn.

[ChillinR]

Dat werkt alleen als de aanvalspoging niet succesvol was.

Bij een succesvolle poging is de ldap-string geëvalueerd door Log4j en komt het resultaat van die evaluatie in je log. Dus weet je niet waarop je moet greppen.

En daarnaast wat @aikebah zegt.

[init6]

Het is puur hoe de omgeving en processen is ingericht en de reactiesnelheid binnen je organisatie.

Binnen onze organisatie hebben we 1 tool gehad die 3 dagen niet geupdate kon worden doordat de pull requests door de open source developers gemaakt moesten worden. Gezien deze tool geïsoleerd draait was het risico minimaal. Alle overige tools waren binnen een uur bekend wat de status was en gepatched waar nodig (We hebben een retro aan besteed omdat we management informeren te lang vonden). Gaat ook over duizenden applicaties.

Dit soort momenten zie ik zelf als leermomenten en momenten om je procedures nog eens tegen het licht te houden, op het moment dat je tijdens dit process aangeeft dat het nou eenmaal zo is is meestal een teken dat er iets niet goed gaat.

[Reactie gewijzigd door init6 op 22 juli 2024 15:23]

[latka]

Als het open source is doe je of zelf de patch of betaal je de maker ervoor. 3 dagen wachten en wijzen klinkt niet echt best.

[9000rpm]

Niet zo raar, als je bedenkt dat de komende week de bezetting zeer dun is bij veel bedrijven, ook op IT-afdeligen, ivm verlof etc. Je kunt dan minder snel op actuele ontwikkelingen inspringen.

Voor een lek dat 9 december al bekend was, ver voor de kerstperiode, vind ik dit toch echt een kwalijke zaak en een duidelijk teken dat de KvK zijn zaakjes echt niet op orde heeft.

[ShadowBumble]

Degene die bij de KVK in dienst is die deze dingen op z'n bureau heeft qua functieomschrijving had meteen moeten weten dat ze 't gebruiken, of maximaal een paar uur aan research moeten besteden.

Dat is wel heel kort door de bocht, als het zo simpel was denk je dat men zich er dan zo druk om zou maken ? De praktijk laat vaak zien dat het vaak niet eens bekend is, omdat een commerciële leverancier zijn software (lees source code) niet bekend maakt maar wel de library gebruikt of gewoon omdat het onduidelijk is dat hij soms precompiled mee komt in pakketten of zelfs images die men gebruikt.

Bij zelfs een "klein" IT landschap het je dan niet binnen een paar uur "research" bovenwater waar het exact gebruikt is, sterker nog de grote(re) entiteiten hebben zelfs ruim anderhalve week na release nog niet eens inzichtelijk waar het allemaal draait.

[Reactie gewijzigd door ShadowBumble op 22 juli 2024 15:23]

[Cyb]

Bij zelfs een "klein" IT landschap het je dan niet binnen een paar uur "research" bovenwater waar het exact gebruikt is, sterker nog de grote(re) entiteiten hebben zelfs ruim anderhalve week na release nog niet eens inzichtelijk waar het allemaal draait.

Ligt eraan wat je "klein" noemt. Als je bijv. een Java webapp die gebruikt maakt van Log4j, hebt draaien op de veel gebruikte Tomcat webserver, dan moet je binnen een minuut wel kunnen zien of een foute versie Log4j gebruikt wordt. Je hoeft eigenlijk maar naar één file patroon te zoeken. Je hoeft daarbij geen source files te bekijken. Wel is het ontbreken van het file patroon nog geen garantie dat het niet gebruikt wordt, maar dat speelt eigenlijk alleen bij afwijkende build methodes, wat bij een groot systeem als dat van KVK natuurlijk gemakkelijk het geval kan zijn. Heb je wel de source, dan kan je met de facto build tools als Maven en Gradle (indien gebruikt) gemakkelijk alle transitieve dependencies achterhalen.

[rynoo]

Klinkt eerder dat ze de beheerders een rustige kerstweekend willen geven en niet alles willen monitoren en bij moeten springen als iets bij een leverancier mis gaat.

[Metalfreak]

Dit ja, dit heeft al voldoende onrust opgeleverd de afgelopen weken. En als je weet dat deze diensten in het kerstweekend toch vrijwel niet gebruikt worden, waarom zou je dan een onnodig risico willen lopen en je beheerders weer opzadelen met weer geen rust.

[anoniem987654]

Dit is een wijder probleem hoor. De Universiteit Maastricht heeft ook te maken met log4j en heeft ook pas besloten om de soortgelijke systemen (de remote desktop) vanaf 22 dec tot na de kerst dicht te gooien, terwijl ze vanaf 10 december al bekend waren met het probleem. In "ons" geval hebben ze de tijd nodig om alle computers individueel te checken.

[Zer0]

Veel websites die hier last van hebben zijn allang gepatched door updates te installeren.

Woor lang niet alle systemen zijn patches beschikbaar, en er is al gebleken dat een aantal patches niet voldoende bescherming biedt, en verdere patches noodzakelijk zijn.

[sjimmie]

Toen het uitkwam gingen wij gelijk kijken of we geimpact waren, en dezelfde dag hadden we al een rapport klaar dat we dat niet waren, en waren klanten van ons geinformeerd dat er problemen waren waar dat nodig was. Dit was allemaal binnen 24 uur geregeld.

Heel goed van jullie. Schouderklopje.
Maareh, lees jij ergens dat de KVK dat niet zo heeft geregeld dan?

Er zijn legio organisaties die complexe applicaties van derde partijen gebruiken waarvan je niet zelf even log4j gaat updaten. Zij hebben dan bv wel alle mogelijk mitigerende maatregelen genomen, maar wachten nog op een definitieve update.

[Reactie gewijzigd door sjimmie op 22 juli 2024 15:23]

[fastedje]

Ik denk precies hetzelfde: als je nu nog geen maatregelen hebt genomen tegen log4shell dan ben je vrees ik al te laat. Die systemen hadden dan al veel eerder offline gehaald moeten worden.

[Brahiewahiewa]

Je gaat er nu van uit dat dit de enige maatregel is die KvK heeft toegepast om zich te beschermen tegen de log4j kwetsbaarheid. Dat is niet het geval. KvK heeft, net als de meeste andere Nederlandse bedrijven, zo goed mogelijk gepatched.
Als additionele maatregel zetten ze hun systemen tijdens de kerst uit, zodat hun personeel lekker thuis kan zijn. En omdat KvK een publieke functie heeft, melden ze dat even in een persbericht

[downtime]

Wel opvallend dat het nu pas offline gehaald wordt, terwijl deze kwestbaarheid al eventjes bekend is.

Wie zegt dat ze nog niet gepatched hebben? Bij mijn werkgever werden ook binnen 24 uur de meeste systemen gepatched en een dag later konden we opnieuw beginnen omdat er in de gepatchte versies weer nieuwe kwetsbaarheden gevonden werden. Misschien wil de KVK voorkomen dat ze tijdens de Kerstdagen verrast worden door nog onbekende kwetsbaarheden.

[Northside]

Alleen het waarschuwen van iedereen in de keten dat je je dienstverlening gaat platleggen en deze partijen een kans geven daar hun eigen mitigerende maatregelen voor te nemen kost veel tijd. En als ze ondertussen continue monitoren, tsja...

[kameleon20]

Zelfde dag van de waarschuwing is cjib paar uur offline geweest om deze log4j kwetsbaarheid aan te pakken. Ergens kan het dus wel!

[air2]

Het gaat er volgens mij niet om of ze kwetsbaar zijn, maar is het meer uit voorzorg, omdat er best kans is dat het leg misschien wel gepatched is, maar een of andere slimme hacker er toch nog in kan komen. Dan kan ik me voorstellen dat je de systemen in de kerst uitzet als toch bijna niemand er gebruik van maakt en je weinig bezetting hebt. Er wordt nerges gezegd dat KvK geen patches heeft uitgerold.

[moonlander]

Dus we kunnen nu nog lekker aanvallen op systemen die nu bekend zijn gemaakt die mogelijk kwetsbaar zijn. Waarom niet per direct offline halen als met het nu al niet vertrouwd?

[Fluks]

KVK heeft na de eerste melding van het NCSC op 10 december 2021 direct extra beschermingsmaatregelen getroffen. Er wordt continu gemonitord (24/7) en KVK voert alle updates en patches uit zodra die beschikbaar zijn.

Net zoals veel bedrijven zullen ze genoeg maatregelen hebben genomen en continu monitoren op verdachte activiteit. Maar als ik het goed begrijp, is de verwachting van het NCSC dat juist deze vakantieperiode gebruikt wordt om aanvallen te doen door lage bezetting bijvoorbeeld.
Als ik me even in de gedachten van een hacker/misbruiker verplaats: ik zou ook niet direct proberen om het uit te voeren wanneer het nog heet in het nieuws is, maar misschien juist op een rustig moment (zoals Kerst) kijken of ik dan nog ergens binnen kan komen. Lukt het in dat geval, dan heb je vervolgens vrij spel.

[Cobalt]

Besef dat mensen ook vrij willen zijn tijdens het kerstdiner in plaats bezig te moeten met aanval pogingen. Als jij oproept en zelf pogingen wil doen dan zou het goed zijn wanneer de politie jou preventief tijdens de kerstdagen vast zet.

[Newjersey]

Is dit niet te blokkeren met een WAF? Of die ik dat verkeerd? Je kan die bekende string toch blokkeren op je WAF?

[Zenix]

Jazeker. Ik snap ook niet dat zo'n organisatie als de KVK dat niet heeft. Maar vanuit security oogpunt wil je defense in depth.

In dit geval zijn dit de maatregelen die wij hebben getroffen
- WAF
- IDS met signatures
- Alle systemen scannen
- En daarnaast alles patchen
- Alles dichtzetten wat niet nodig is.

[Reactie gewijzigd door Zenix op 22 juli 2024 15:23]

[nl-x]

Een WAF hoeft natuurlijk niet voldoende te zijn. Zelfs al zou je WAF de string herkennen, zou het misschien mogelijk zijn dat je de string zo weet in te pakken (ik roep maar wat, base64 encoded), dat deze voorbij de WAF komt, ergens uitgepakt wordt en plots kwaad kan in een systeem.

[Ventieldopje]

Immunify360 adverteert dat je met hun WAF de kwetsbaarheid inderdaad kan blokkeren. Maar ik snap dat veel bedrijven toch liever kiezen om de boel offline te halen in plaats van afwachten of de WAF goed zijn werk doet.

Zeker met de kerstdagen

[Reactie gewijzigd door Ventieldopje op 22 juli 2024 15:23]

[zalazar]

Met IPS en de juiste signatures hou je dit ook tegen.
Er blijft wel een risico dat bij een kleine aanpassing qua aanval er toch requests doorheen gaan.
Als je de webservers niet direct aan het Internet koppelt dan verklein je het risico.
Er zijn inmiddels voldoende mogelijkheden om het probleem op te lossen.
Als het niet valt te updaten of de parameter niet afdoende werkt dan zou je de bestaande (oudere) log4j jar kunnen aanpassen en de probleem class (code) er uit kunnen halen.

[Reactie gewijzigd door zalazar op 22 juli 2024 15:23]

[tweaker2010]

Apart om te zien dat het KVK eerst zelf advies geeft, en nu blijkt dat ze de zaakjes zelf ook niet op orde hebben. Lijkt me dat je pas offline gaat als het echt niet anders kan en er niet tijdig gepatched kan worden.

[kodak]

Aangezien advies kunnen geven niet de betekenis heeft dat er geen risico is klopt je opmerking niet.

[killercow]

Als ze lek waren, dan zijn ze waarschijnlijk al te laat.

[satya]

Dat hoeft niet, misschien hebben ze all mitigaties genomen maar spelen nu op zeker.

Maar als je een beetje firewall hebt dan filter je die jndi oproepen gewoon uit lijkt mij. dat gebeurt hier ook al.

[Cyb]

Een firewall kan zeker helpen. Bij Cloudflare WAF doen ze dat ook, maar het is geen garantie. Data kan op allerlei manieren een systeem bereiken, waar je mogelijk net niet niet aan hebt gedacht, bijv. data per email of data in DNS lookups. Ook zijn expressies mogelijk in Log4j, waardoor simpelweg een firewall laten zoeken naar "jndi", niet voldoende is.

[killercow]

Log4J is zo flexibel dat je geen remote payload meer nodig hebt. Zodra je dus een payload weet in te schieten die executed wordt ben je potentieel al de sjaak,

[satya]

Als de zaak goed is ingericht niet wat deze kwetsbaarheid betreft. Wij zien heel wat geavanceerde excepties binnen komen, maar als je niets toestaat met jndi:jndi wordt het hem niet.

[Ma_rK]

Er zijn hier een aantal zaken die bijzonder zijn. Eerst even de tijdlijn.

• Op 9 december wordt de Log4j vulnerability bekend gemaakt
• KvK geeft geen melding van enige kwetsbaarheid richting haar klanten
• Op 20 december geeft NCSC haar waarschuwing
• Op 23 december mail KvK haar klanten "morgen gaan de diensten offline". In die mail wordt Log4j niet genoemd.

Dan de bijzonderheden

• Binnen de SLA van de KvK mag ze dit doen. Sterker nog, ze biedt alleen een SLA voor kantooruren.
• In de release notes van de nieuwe API zijn geen security patches te vinden. De oude API gaat in maart 2022 offline.

Wij maken zelf gebruik van deze API en hebben vandaag ook een aantal andere organisatie gesproken. We zien allemaal het belang van security. Je voelt je als klant alleen niet serieus genomen. Het feit dat je een kantoortijden SLA hebt, je klanten zo laat bericht en je klanten niet op de hoogte brengt van het feit dat je kwetsbaar bent is gewoon niet professioneel. Daarnaast wend je de kosten en het werk van je eigen security problematiek nu af op je klanten. Die moeten de dagen & het weekend van/voor kerst op zoek naar alternatieven om hun systemen die gebruik maken van deze API beschikbaar te houden.

[Reactie gewijzigd door Ma_rK op 22 juli 2024 15:23]

[Tubby]

Blijft de nieuwe API wel online dan?

[raudypater]

De hoeveelheid ICT'ers die er maar van uit gaan dat alles binnen complexe systemen/omgevingen dicht getimmerd is na het patchen van een lek op deze schaal vindt ik erg zorgwekkend.

[DutchHammer]

Verbaas ik me ook over, wij hebben alle eigenbouw software kunnen patchen inmiddels. Morgen deployen we de laatste op prod. Systemen zijn veilig door genomen maatregelen maar we wilde toch dit jaar de permanente fixes toepassen, vendor fixes volgen in loop van de week. Die willen we iets beter door de test straat halen, maar ook daar zijn we veilig.

Best trots dat we met een team op n halve kracht hebben kunnen oppakken. Was buffelen en dus werken op een feestdag maar dat kunnen we weer compenseren.

Wel een les om ons dependencies management even onder de loep te nemen...

Maar het verbaasd me inderdaad echt dat er IT'ers zijn die denken dat even een library updaten een fluitje van een cent is. Maar goed ik verbaasde me ook altijd dat desktop beheer updates van java, onaangekondigd op de desktops ramde; waardoor ineens applicaties onderuit gingen. Pas toen het een keer echt goed mis ging, begonnen ze met het aankondigen van Java updates en kregen we de kans om te testen..

[ralphm]

Gelukkig is er altijd nog https://openkvk.nl/. Raar dat dat project nog steeds relevant is.

[sjimmie]

Gelukkig is er altijd nog https://openkvk.nl/. Raar dat dat project nog steeds relevant is.

Tsja, ik denk dat de echte KVK iets meer biedt dan dat.
Er is (voor dit weekend: was) meer dan de algemene KVK website met de openbare informatie.

[ralphm]

De toegevoegde waarde van de Kamer van Koophandel staat al jaren ter discussie. Ik ken geen één ondernemer die zegt: gelukkig bestaan ze nog. In tegendeel. OpenKVK werd in een weekend in elkaar geklust door Stefan omdat de informatie van hun enige echte wettelijke taak, het publieke bedrijvenregister, elke nacht van 00:00 tot 08:00 uur onbereikbaar was vanwege "onderhoud".

[Stefan Mensink]

Het KvK erkent hiermee niet lek te zijn, maar moet elke hackpoging waarschijnlijk wel onderzoeken, en daar gaan er veel van zijn.

Op deze manier kunnen de werknemers nog een beetje van de kerst genieten. Goede keuze van het management denk ik.

[Anoniem: 30722]

want na 2 weken de boel opgelost hebben bleek niet haalbaar... 🙄

[wildhagen]

In een complex applicatielandschap met soms wel honderden (of nog meer!) applicaties, in soms hele complexe ketens, is dat inderdaad zeker niet altijd haalbaar.

Niet zonder grondig te testen etc. Je bent afhankelijk van zoveel verschillende partijen, dat kost nu eenmaal tijd. Soms véél tijd.

[TwiekertBOB]

In het algemeen ben ik het met je eens, maar juist voor de log4j niet.

Er is een patch beschikbaar.

Het bedrijf waar ik voor werk heeft direct na de melding alle systemen dichtgezet en per applicatie is bekeken wanneer gepatched kon worden en dat was inclusief communicatie binnen 4 dagen geregeld.

En dan hebben we het over een grote multinational.

Overigens was het best prijzig om 4 dagen lang geen business te kunnen doen. Maar het kan dus wel en het gebeurt ook.

[anboni]

Juist voor log4j wel. Er zijn zo onbeschrijfelijk veel producten waar log4j in zit verweven. Dan heb je het over geinstalleerde software, maar ook behoorlijk gesloten appliances. Die patch kun je in lang niet alle gevallen zelf deployen, dus dan ben je afhankelijk van de leverancier. Bedrijven als VMware en IBM hebben tientallen producten waar log4j in zit en ook voor een emergency update als deze moeten ze rigoreus testen, want als er na zo'n patch dingen stuk gaan gaat dat hun klanten ook serieus geld kosten.

[TwiekertBOB]

En juist bij die applicaties was de patch snel beschikbaar.

Nogmaals: bij de multinational waar ik zit, was de volledige infrastructuur in 4 dagen gepatched.

[fastedje]

Zo heel lastig is het nu inderdaad ook weer niet om al je deploy files (wars/hard/ears) te scannen om de JndiLookup.class. uiteraard motEt je besteld archives ook meescannen. Als dit class er nog in zit en je hebt niet de laatste log4j dan weer je dat je kwetsbaar kan zijn. Een beetje batch scripten en dit moet echt wel in een aantal dagen uit te voeren zijn.

[DutchHammer]

Dat kan dus echt niet elke multinational doen. Die kunnen dan net zo goed de boel sluiten.. Niet alleen door een mega verlies maar denk ook aan de reputatieschade

[TwiekertBOB]

4 dagen niet open versus een ransomware aanval of welke hack dan ook?

Ik denk dat iedere multinational dezelfde uitkomst zou hebben op deze afweging.

en deze laatste weken zijn ook nog eens de topperiode voor de multinational waar ik voor werk.
Overigens waren niet alle systemen 4 dagen offline. De contracten en customer applicaties waren in 1 dag gepatched.

[DutchHammer]

Degene waar ik voor werk kan echt geen 4 dagen dicht. Dan loopt de gehele economie flinke schade op zeg maar...

Gelukkig waren wij en de andere teams gewoon instaat de boel snel op orde te hebben....

[CTVirus]

Misschien een controversiële mening, maar als je niet in staat bent omdat te doen als organisatie, moet je geen honderden applicaties hosten/gebruiken.

[anboni]

Afhankelijk van waar je log4j allemaal in hebt zitten, is dat inderdaad zeker niet altijd haalbaar. Log4j zit echt in verschrikkelijk veel producten van verschrikkelijk veel leveranciers, mogelijk nog naast in huis ontwikkelde applicaties. Zeker bij third party producten is het soms niet eens bekend dat er log4j in zit. Voor al die producten zul je moeten patchen of mitigations toe moeten passen, maar die zijn lang niet altijd al bekend en in sommige gevallen bieden mitigations ook geen volledige zekerheid. Dus nee, na 2 weken deze boel opgelost hebben is inderdaad niet haalbaar.

Daarnaast is het ook zeker niet ondenkbaar dat er door criminele elementen al nieuwe lekken zijn ontdekt. Log4j ligt op dit moment aan alle kanten onder een vergrootglas, dus er zullen de komende dagen/weken zeker nog nieuwe problemen in geconstateerd worden. Ik zou niet graag in de schoenen staan van een beheerder die als eerste slachtoffer wordt van een door criminelen ontdekte zeroday.

Tenslotte is er ook nog een heel reeel risico dat een van de vele lekken al eerder is misbruikt en dat criminelen juist tijdens de aankomende kerstdagen de knop omzetten om hele netwerken te kapen (vergeet niet dat ze bij Universiteit Maastricht ook op kerstavond de trekker hebben overgehaald, nadat ze al ruim twee maanden in het netwerk hadden kunnen grasduinen)

[CAPSLOCK2000]

Afhankelijk van waar je log4j allemaal in hebt zitten, is dat inderdaad zeker niet altijd haalbaar. Log4j zit echt in verschrikkelijk veel producten van verschrikkelijk veel leveranciers, mogelijk nog naast in huis ontwikkelde applicaties. Zeker bij third party producten is het soms niet eens bekend dat er log4j in zit. Voor al die producten zul je moeten patchen of mitigations toe moeten passen, maar die zijn lang niet altijd al bekend en in sommige gevallen bieden mitigations ook geen volledige zekerheid. Dus nee, na 2 weken deze boel opgelost hebben is inderdaad niet haalbaar.

Ik kan moeilijk ontkennen dat het in praktijk zo gaat, maar heel erg sterk is het natuurlijk niet. Of je het nu zelf doet of niet, je bent uiteindelijk wel verantwoordelijk. Het idee van externe dienstverleners is uiteindelijk dat die beter kwaliteit kunnen leveren dan je zelf kan voor een lagere prijs.

Eigenlijk zou je omgekeerd over dit soort dingen moeten denken. Je moet je eerst afvragen welke responsetijd je nodig hebt en dan zorgen dat de applicaties/producten/leveranciers die je gebruikt daar aan voldoen, typisch op grond van Service Level Agreements. Ik snap dat die keuze niet altijd mogelijk is, maar nu lijkt het vaak alsof het helemaal geen rol speelt. Er wordt wel eens gezegd dat communicatie het zwakste punt van IT is. Hoe meer er gecommuniceerd moet worden tussen losse onderdelen hoe meer kans op fouten en problemen. In situaties als deze zal je razendsnel moeten kunnen schakelen om een acceptabele responsetijd te krijgen. Lastig is wel dat het al snel onbetaalbaar wordt.

Op een bepaalde manier leven we wat IT betreft allemaal boven onze stand, maar af en toe wordt de rekening opgemaakt en afgerekend. Dit is zo'n moment dat we de rente moeten betalen over onze opgebouwde technische schulden.

[anboni]

Ik kan moeilijk ontkennen dat het in praktijk zo gaat, maar heel erg sterk is het natuurlijk niet. Of je het nu zelf doet of niet, je bent uiteindelijk wel verantwoordelijk. Het idee van externe dienstverleners is uiteindelijk dat die beter kwaliteit kunnen leveren dan je zelf kan voor een lagere prijs.

Een van de problemen is natuurlijk dat voor heel veel bedrijven IT nog steeds vooral een kostenpost is. Die externe dienstverleners worden in veel gevallen primair geselecteerd op laagste prijs. Deze bedrijven worden op dit moment hardhandig wakkergeschud, maar ik ben bang dat er een heleboel zullen zijn die even snel wat pleisters plakken en vervolgens weer op dezelfde voet door zullen gaan.

[Transportman]

Het is niet alleen dat IT vooral een kostenpost is, maar binnen die kostenpost is LCM bij veel bedrijven ook nog eens een sluitpost, want "het werkt toch?". En doordat het een ondergeschoven kindje is, wordt het probleem ook steeds groter.

Ik heb de afgelopen weken ook de nodige PO's/managers gehoord bij klanten die blij waren geen LCM gedaan te hebben op de software die wij leveren, want daardoor zaten ze nog niet op softwareversies waar log4j2 in was gebouwd, maar nog log4j. Dan heb je het als manager niet goed begrepen, want log4j is al jaren EOL, heeft ook de nodige beveiligingsproblemen, en doordat ze niet bij zijn gebleven zitten ze met een enorm probleem als er een keer een log4shell-probleem breed in het nieuws komt voor log4j, want doordat ze zover achterlopen zijn de upgrades niet triviaal meer. Terwijl de upgrade voor de teams die wel bij zijn gebleven niets meer is dan het versienummer aanpassen.

Nu moet ik ook wel eerlijk zijn, niet alle software is zo makkelijk te upgraden als de onze, onze software is relatief licht en kan zonder veel overhead en kosten in kleinere instanties worden opgesplitst (tot microservice-level aan toe). Ik heb ook wel eens met software gewerkt die zoveel overhead had dat je het niet in je hoofd haalde om te veel op te splitsen, want dat was betalen per core en met een paar instanties had je alweer een extra core nodig. En doordat je niet op kan splitsen, worden de upgrades ook gigantisch veel werk, want het is alles of niets en als het fout gaat verzuip je meteen in de problemen.