Gemeentes Almere en Hof van Twente zetten systemen preventief offline door log4j

Almere en Hof van Twente hebben enkele van hun systemen afgesloten. Dat doen die gemeentes uit voorzorg, vanwege de kwetsbaarheden in Apache log4j. De gemeente Almere bepaalt dinsdagochtend welke applicaties weer in gebruik worden genomen.

Volgens Omroep Flevoland heeft Almere onder andere zijn Citrix-systemen offline gehaald. Die worden gebruikt door medewerkers van de gemeente om in te loggen. De gemeente doet dit uit voorzorg, om een mogelijke cyberaanval op de systemen via de log4j-kwetsbaarheid te voorkomen. De gemeente Almere heeft in de nacht van maandag op dinsdag gewerkt aan de systemen en besluit op dinsdagochtend welke applicaties weer in gebruik genomen kunnen worden. Dan moet ook duidelijk worden wat de gevolgen worden voor inwoners van Almere.

Hof van Twente laat in een Facebook-bericht weten dat de gemeente ook zijn systemen preventief offline heeft gehaald. De website van Hof van Twente verwijst momenteel door naar dat bericht. De gemeente laat daarin weten dat het zijn systemen sinds zondagavond 12 december offline heeft gehaald. Volgens de gemeente is de dienstverlening daardoor 'tijdelijk beperkt', bijvoorbeeld voor het uitgeven van paspoorten en rijbewijzen.

Hof van Twente werd eind vorig jaar slachtoffer van een cyberaanval, waarbij de systemen van de gemeente werden geïnfecteerd met ransomware. De gemeente geeft aan dat het 'alles wil doen om te voorkomen dat zoiets nogmaals gebeurt'. "We hopen dat we de systemen komende dagen, uiterlijk eind deze week, weer online kunnen brengen", schrijft de gemeente.

De kwetsbaarheid in Apache log4j werd eind vorige week aangetroffen. Deze Java-tool wordt in verschillende applicaties en diensten gebruikt om logs bij te houden. De kwetsbaarheid maakt het mogelijk om op afstand willekeurige code te injecteren en uit te voeren met de rechten die de betreffende Java-applicatie heeft. Versies van log4j 2.0-beta9 tot en met 2.14.1 zijn kwetsbaar. Er zijn updates uitgebracht om de kwetsbaarheid op te lossen; het probleem is bij versie 2.15.0 verholpen.

Het NCSC waarschuwde recent voor 'een grote kans op grote schade' op korte termijn en publiceerde een lijst met kwetsbare software, hoewel de organisatie ook benadrukt dat deze nog niet volledig is. Op de lijst staat onder meer software van Microsoft, Cisco, Amazon, Oracle en McAfee, maar bijvoorbeeld ook de Java-versie van Minecraft, waarvoor Mojang recent al een beveiligingsupdate uitbracht. Volgens het NCSC is er al proof-of-concept-code gepubliceerd voor het exploiteren van de kwetsbaarheid. Het NCSC ontvangt ook meldingen dat de kwetsbaarheid actief wordt misbruikt.

Reacties (136)

[Naj_Geetsrev]

Ehmm. Van alles wat ik kan vinden (en van leveranciers te horen krijg) is het voldoende om log4j2.formatMsgNoLookups op true te zetten. Is het compleet offline halen niet een beetje overtrokken dan?

[jochem4207]

En als je dat niet snel kan doen om 20 redenen met als risico dat je systemen gehackt worden.. ik vind t een mooie keuze

[demianmonteverd]

De gemeenten ontwikkelen niet zelf hun software over het algemeen. Ze kopen veel in en dat is niet altijd in 2021 geschreven software. Er is zelfs software op de markt welke een update heeft gekregen in 2021 en toch last van dit probleem heeft.

Een manier om naar dit probleem te kijken is misschien deze:
Heel veel bedrijven gebruiken open source oplossingen om sneller te bouwen, men heeft als het ware een groot deel van de lower level software infrastructuur niet meer zelf gebouwd en indirect uitbesteed met industrie standaard oplossingen, zoals log4j daar een van is. Dit stelt deze leverancier/software bouwers in staat sneller te ontwikkelen/innoveren/bouwen en vaak ook goedkoper. Nu, komt er een probleem naar voren en iedereen die dit heeft gedaan, direct, maar ook indirect (dus als log4j gebruikt word in andere herbruikbare infrastructuur, denk bijv. aan elasticsearch!), moet dus nu hard aan de slag om het op te lossen.

Het zijn niet altijd de klanten die iets verkeerd hebben gedaan, deze software is ook in gebruik bij de zgn. techgiganten. Het is niet een fout van alleen een beheerafdeling of een software ontwikkelaar die iets heeft nagelaten. Was het maar zo.

Ik heb zelfs meerdere backupoplossingen gevonden die hier last van hebben... Backup oplossingen...

[Cergorach]

Een manier om naar dit probleem te kijken is misschien deze:

Er is iets mis met een zekering xyz, als deze gebruikt wordt, moet deze vervangen worden. Nu blijkt achteraf dat deze in alle auto's worden gebruikt. Als de leveranciers dit niet publiceren, is het dan aan de auto-eigenaaren om dit te (kunnen) weten? Tot voor kort werd die informatie niet aan de grote bel gehangen, nu wel en gaan auto-eigenaren bellen met hun dealer, welke weer bij de maker gaat checken, zijn die dingen gebruikt in productie over de afgelopen 10+ jaar.

[demianmonteverd]

Mooie auto versie, top!

[ChillinR]

Dit probleem speelt zich toch al geruime tijd

Want dit had men al geruime tijd kunnen aanpakken

Bijna niemand wist dit. Wij vernomen er afgelopen vrijdag voor het eerst wat van.

hoe incapabel IT afdelingen zijn dat ze het in de eerste instantie zover laten komen.

Dit is bijna niet te voorkomen. In de software-wereld is het heel normaal om third-party libraries te gebruiken en te vertrouwen, en ook ervan uit te gaan dat er door de makers zinnige defaults gekozen worden. Al wordt er soms inderdaad wat te makkelijk gedacht en niet gekeken van wat voor hobbyprogrammeur of organisatie die libraries komen.

Het is onmogelijk (niet eens alleen onwerkbaar, echt onmogelijk) om met 100% zekerheid te zeggen dat er in een stukje (third-party) software geen kwetsbaarheid zit. Dan kan je zelf alles implementeren, maar de kans dat je daarbij kwetsbaarheden introduceert is over het algemeen groter, naast dat het te duur is om zelf voor alles het wiel opnieuw uit te vinden.

[Reactie gewijzigd door ChillinR op 23 juli 2024 03:40]

[gimbal]

Ik ben het met je eens, maar dat neemt niet weg dat ik alsnog heel erg geschrokken ben van eigenlijk hoe groot, gemakkelijk te misbruiken en oppervlakkig dit voorval is, dat het zolang heeft mogen duren voordat het bekend werd dat geeft aan dat er hier iets scheef is gegaan. Men vind de meest verstopte exploits in de meest obscure hoeken en dit moet dan als een totale verrassing komen? In open source code ook nog eens?

Ik doe een aanname: "Ach, het is maar een logging library". Ik denk dat dit wel wat ogen heeft geopend in de grotere wereld van software engineering.

[Noeandee]

Dit probleem speelt zich toch al geruime tijd en gaf niemand hierom totdat het gisteren relatief breed in het nieuws kwam. Tegelijkertijd zoverre we weten zijn ook geen gemeentes (of andere publieke instanties) aangevallen met deze vulnerability. Dit kan natuurlijk wel, maar is die kans inderdaad groot en vervolgens wat zijn de consequenties?

Deze vulnarability is pas zeer kortgeleden ontdekt op minecraft servers. En daarna werd pas bekend, hoe en wat voor impact, dit kon hebben. Op 9 december was er nog geen offcieel CVE van bekend. Maar sindsdien is er verschrikkelijk snel ingegrepen imo. En ik vind de berichtgeving hierover bij github etc erg goed. Bedenk ook, dat voor heel veel software nog niet bekend is, of men geraakt is. En men is vollop bezig met patches, hotfixes en workarounds e.d. Dat kost gewoon tijd om te ontwikkelen en te implementeren.

Service is gewoon even ondergeschikt als je mogelijk kwetsbaar bent. Better safe then sorry.

Apache:

11/24/2021: informed
11/25/2021: accepted report, CVE reserved, researching fix
11/26/2021: communicated with reporter
11/29/2021: communicated with reporter
12/4/2021: changes committed
12/5/2021: changes committed
12/7/2021: first release candidate
12/8/2021: communicated with reporter, additional fixes, second release candidate
12/9/2021: released

[Reactie gewijzigd door Noeandee op 23 juli 2024 03:40]

[MadEgg]

Je noemt zelf al 25-11 als datum van de CVE. Bij het bedrijf waar ik momenteel voor werk werd er al veel eerder dan afgelopen weekend aandacht aan besteed en zodra de fix en workaround bekend was is dat grootschalig uitgerold op tientallen externe en interne diensten.

Als je het nu nog niet op zijn minst geinventariseerd hebt loop je wel heel erg achter de feiten aan.

[Vogel666]

Dat hangt naturlijk van je omgeving af. Als codeklopper houdt je daar als het goed is een dependency tree van bij.
Maar een stap verder in de keten met een beetje kantoor (1000+ medewerkers) en een factory omgeving praat je al gauw over honderd softwarepakketten en honderden devices met web-based configuratie pagina's. En die elektro-boeren..... die kopen hun componenten gewoon in China in en hebben geen flauw idee hoe of wat voor libaries er gebruikt zijn bij het schrijven van die code.

[Cergorach]

First things first, ik ben geen ITer laat staan een beveiligsspecialist echter ...

En dan dit:

Dit probleem speelt zich toch al geruime tijd

https://nvd.nist.gov/vuln/detail/CVE-2021-44228
Van 10 december, dat is de Amerikaanse overheid. Dat was vrijdag.
https://cve.mitre.org/cgi...e.cgi?name=CVE-2021-44228
is aangemaakt op 26 november, maar zegt niet zoveel over daadwerkelijke publicatie. Dat kan daarvoor of daarna bekend zijn gemaakt.

Veel bedrijven waren dus al vorige week hiermee druk bezig, maar het lijkt zeker maandag, dat er steeds meer boven kwam drijven qua software welke deze library gebruikt. Dat is natuurlijk niet vreemd, gezien op vrijdag heel veel mensen in het bedrijfsleven vrij zijn, niet alleen binnen eigen organisaties, maar ook bij leveranciers.

Als ik een gok moet doen, heeft men gister zoveel zaken gevonden dat ze het niet snel en veilig kunnen fixen. Dan is het gewoon verstandig om het uit te zetten totdat het wel veilig gefixt kan worden. Zeker als er nu flink op wordt aangevallen.

Side-note: Als je geen ITer bent en ook geen security expert, hoe had je precies gedacht hier een waarde oordeel over te kunnen maken?

[CAPSLOCK2000]

First things first, ik ben geen ITer laat staan een beveiligsspecialist echter ...

les 1 van IT: het is een puinhoop

Dit probleem speelt zich toch al geruime tijd en gaf niemand hierom totdat het gisteren relatief breed in het nieuws kwam.

Er worden dagelijks problemen ontdekt, het is vaak van te voren niet duidelijk wat de impact is.

Tegelijkertijd zoverre we weten zijn ook geen gemeentes (of andere publieke instanties) aangevallen met deze vulnerability.

Ik kan garanderen dat het wel zo is.

Dit kan natuurlijk wel, maar is die kans inderdaad groot en vervolgens wat zijn de consequenties?

De kans is heel groot, er worden nu wereldwijd systemen gehackt.
De consequentie is dat er bergen data wordt gestolen en dat de gehackte computers worden ingezet voor nieuwe criminel zaken.

Je mag je dan zeker afvragen of dit overtrokken is, zeker gezien hoe incapabel IT afdelingen zijn dat ze het in de eerste instantie zover laten komen.

Het is erger dan je denkt. IT is verschrikkelijk moeilijk. Omwille van de lengte ga ik niet uitleggen waarom. Maar IT is ontzettend moeilijk en duur er is een fors tekort aan goed personeel. Ieder IT-afdeling die ik heb gezien was "incapabel" omdat er te weinig mensen waren, te weinig specialisten, en niet genoeg budget en tijd om te doen wat nodig is (zoals regelmatig software updaten). Dit werkt in de hand dat men bij de dag leeft en weinig aan lange termijn planning doet. Daardoor is er vaak geen goed exit-strategie voor oude software waardoor te lang blijft hangen. Hoe ouder software is hoe moeilijker (en duurder) het onderhoud wordt. Op het moment dat er fouten in oude software wordt gevonden is het economisch gezien niet meer haalbaar om er iets aan te doen. Oude software kan zo een enorme kostenpost worden maar veel organisaties zien dat niet omdat ze vooral naar de aanschafprijs van software kijken. Niet naar wat er nodig is om die software op lange termijn werkend te houden of hoe je er ooit weer vanaf komt (liefst zonder je data te verliezen).
Momenteel is de trend om software en IT zoveel mogelijk kant en klaar in te kopen. Dat komt de kwaliteit van individuele applicaties ten goede. Het nadeel is dat je steeds meer interactie en communicatie hebt tussen applicaties die door verschillende externe partijen worden beheerd. Maar het gebied van interactie en communicatie is nu net het gebied waar de meeste ernstige IT-fouten optreden (omdat de ene kant niet goed weet wat de andere kant doet). En nu heb je twee externe bedrijven die vooral proberen hun eigen straatje schoon te houden met je eigen IT'ers er tussen om te coordineren tussen afstandeljke helpdeskers die zelf niet veel meer kunnen dat het probleem doorgeven.
Ook niet echt een recept voor succes.

Want dit had men al geruime tijd kunnen aanpakken echter veel gemeentes zitten met custom software speciaal voor iedere gemeente op zich ontwikkeld dus dit inderdaad zo'n groot risico is, zullen ze heel lang weer weinig kunnen doen.

In principe ben ik het met je eens maar deze problemen zie je in de hele sector, niet alleen bij de overheid. Sterker nog, ik heb regelmatig de indruk dat, ondanks het slechte imago, de overheid het vaak beter doet dan een hoop bedrijven. Het grote verschil is dat die bedrijven niet in de krant komen als er iets mis gaat. En ik heb de indruk dat de overheid vaak haar best doet om zich aan alle wetten te houden, terwijl in het bedrijfsleven de insteek soms meer "wat is het noodzakelijke minimum" is?

[c-nan]

Dit probleem speelt zich toch al geruime tijd en gaf niemand hierom totdat het gisteren relatief breed in het nieuws kwam.

Hoe bedoel je dit? Eind november wordt Apache door Alibaba geïnformeerd over deze lek. Op 6 december brengt Apache een patch uit. Op 9 december wordt er een PoC gepubliceerd.

Dus hoe speelt het zich al een geruime tijd af en gaf niemand hier wat om?

[Henk Poley]

Ik las elders dat het probleem sinds 2014 heen al een keer of 7 ontdekt was.

Dat er al opties in log4j2 zitten om het een ander af te schakelen ('vulnerable by default'), zijn het resultaat daar van.

[Verwijderd]

als niemand (bijv. NCSC/CERT) IT-afdelingen vertelt dat er iets loos is kunnen en gaan ze ook niets doen.
IT beheert systemen maar zijn zelf geen programmeurs of applicatiebeheerders, dus hoe hadden ze kunnen weten dat er een exploit is in log4j. Men kijkt wel eens op verschillende sites maar je gaat ook niet op elke scheet uit China reageren, zelfs niet op elke CVE.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:40]

[Timoo.vanEsch]

Allereerst is er het feit datdit probleem pas sinds kort op grote schaal bekend werd gemaakt. Daarnaast lezen hackers ook nieuws en is -dus- deze exploit dit weekend op grote schaal geïndexeerd door hackers. Omdat ook zij er niet van op de hoogte waren.

Dus is er sinds kort een serieus verhoogd risico. En beschouw ik dit ook als een slimme zet. Eerst risk assessment uitvoeren, dan fixen, dan weer online gaan.

Jouw 1st world burger-probleempjes van slechte service zijn daaraan serieus ondergeschikt.

[RobbieB]

Het is duidelijk dat je geen IT’er bent ja.

Zucht.

[Zarhrezz]

Ik denk dat je dit een klein beetje onderschat. Collega's van me in de security-hoek bij bv. grote banken hebben het afgelopen weekend een "werkdag" van 32 uur gemaakt om te bepalen welk servers / applicaties weer online mochten. Dat is wat er wereldwijd aan de hand is / geweest is. Java is enorm groot in de server / backend kant "van het internet" en in heel veel gevallen wordt er op log4j geleund.

Kijk voor de grap de lijsten hier eens door:
https://github.com/authomize/log4j-log4shell-affected

Artikeltje op nu:
https://www.nu.nl/tech/61...-registratiesoftware.html
Ruim 800.000 aanvallen de afgelopen dagen. Ga er maar vanuit dat er gemeentes zijn aangevallen en niet weinig ook. De consequentie? 100% controle over de kwetsbare server(s).

Dit is niet overtrokken. Dat je het overgrote deel van alle IT afdelingen wereldwijd wegzet als incapabel geeft te denken.

Het is wachten tot de eerste interplanetary hack-poging plaatsvind:
https://twitter.com/theasf/status/1400875147163279374

[Reactie gewijzigd door Zarhrezz op 23 juli 2024 03:40]

[Djerro123]

Ik had zaterdag ochtend al sporen in de logs van mijn persoonlijke internetfacing nginx server hiervan. Men wordt niet meer uitgekozen als doelwit, je wordt gewoon automatisch gescand en geprobeerd. De kans is daarmee niet groot maar gewoon 100% dat áls je kwetsbaar bent voor het lek en je het nog niet gemitigeerd hebt, het misbruikt gaat worden.

[Henk Poley]

-Dlog4j2.formatMsgNoLookups=true werkt pas vanaf log4j2 2.10.0 (!)

Voor 2.7 - 2.9.0 versies kan je log4j.xml aanpassen:

Voor de volledigheid, je kunt het in die gevallen nog steeds beperken door %m, %msg en %message in log4j2.xml te vervangen door %m{nolookups}

Bron: https://twitter.com/daenney/status/1469320785856770068

[Reactie gewijzigd door Henk Poley op 23 juli 2024 03:40]

[Gropah]

Versie 2.10 van log4j is ondertussen 4 jaar oud. Is het heel raar om te verwachten dat producten die nog gebruikt worden en log4j gebruiken, ondertussen wel op deze versie moeten zitten?

[Snow_King]

Nee, want dit zijn vaak embedded libraries. Daar is het niet heel raar dat deze niet altijd zijn bijgewerkt tot de laatste versie.

[ApexAlpha]

Daarnaast is een 4 jaar oude applicatie niet raar om te vinden in bedrijfsomgevingen. Zeker als de applicatie "achter de firewall" hangt en niet publiekelijk te bereiken is.

Het veraderlijke aan deze kwetsbaarheid is dat het via de logging gaat. Dus ook backend systemen die user input verwerken zijn kwetsbaar, zelfs als ze geen enkele open poort hebben naar buiten toe.

[Skit3000]

Dus ook backend systemen die user input verwerken zijn kwetsbaar, zelfs als ze geen enkele open poort hebben naar buiten toe.

Dat klopt, maar dan moet een aanvaller dus wel een log entry kunnen triggeren op zo'n intern systeem. Als een gemeente als front-end bijvoorbeeld ASP.NET gebruikt en uiteindelijk data die door gebruikers wordt ingevoerd, op een back-end server verwerkt met een applicatie dat haar errors logt via Log4j. Behalve dat van buitenaf niet zichtbaar is dat zoiets plaats vind, moet er dan in de front-end ook nog maar net een fout in de datavalidatie zitten die een dergelijke payload toe laat.

Dus ja, het is theorisch gezien mogelijk maar de kans dat een aanval op deze manier (op zo een korte termijn) succesvol is, is laag omdat iemand hiervoor kennis moet hebben van je interne systemen én moet toeslaan voor je de workaround uitgevoerd hebt (wat elk bedrijf ondertussen al gedaan zou moeten hebben).

Bedrijven die na vandaag nog vatbaar zijn zullen vast ook nog wel op vele andere manieren vatbaar zijn.

[ApexAlpha]

Je hoeft geen kennis te hebben van interne systemen. Je kan namelijk gewoon 'met hagel schieten'. Hier een tweet van iemand die een callback krijgt vanuit Apple door de string als Naam in te voeren op zijn iPhone.

Je kan gewoon in élke user-controlled input die string gooien. Van HTTP headers tot login naam tot cookie string. Alles erin en dan komt er vast wel wat uit.

[Reactie gewijzigd door ApexAlpha op 23 juli 2024 03:40]

[ToolkiT]

4 jaar oude applicatie is zeker niet vreemd, maar idealiter patch je in de tussentijd wel de middleware..

[Skyclad]

Idealiter wel. Maar vaak komt het er op neer dat een pakket wordt gekocht en nooit geupdate of gepatched omdat mensen weten dat die versie werkt (en hoe het werkt) en niet het risico willen nemen dat het na het updaten niet meer werkt. Bovendien is er vaak sprake van dat die oude versie niet meer gratis updates ontvangt en er geen budget is voor een betaalde upgrade. Dus tot het omvalt blijft alles bij het oude.

Bij veel pakketten weet de gebruiker vaak ook niet wat er aan third-party software bij gebruikt wordt. Je installeert een pakket van bedrijf X, en een deel van de gebruikers weet niet eens hoe het pakket zelf heet, alleen dat het 'X' is. Die zoeken ook niet op welke andere software er mee geinstalleerd wordt, en weten al helemaal niet of er onderwater nog spul wordt geinstalleerd wat niet in de lijst van Installed Programs verschijnt (als het pakket een basis Apache server zou installeren om wat informatie in het pakket op die manier te tonen maar niet de volledige server software er op gaat zetten heb je kans dat je alleen een Apache service kan zien draaien maar onder Installed Programs alleen pakket X zal zien).

[martdj]

Precies. De meeste software hier is gelukkig niet kwetsbaar. Niet omdat ze op de laatste log4j versie zitten, maar juist omdat ze nog van log4j versie 1.x gebruik maken. Dat geeft wel een indicatie hoe vaak die library wordt bijgewerkt in software.

[syl765]

Aangezien log4j versie 1.x al heel lang niet meer ondersteund is zou ik mij niet heel veilig voelen. Ik zou zeker voorzichtig zijn en het internet goed in de gaten houden of er niet berichten opduiken waaruit blijkt dat log4j 1.x ook vatbaar is voor dit soort zaken.
log4j ligt nu onder het vergrootglas!

[potjandrie]

Onderschat nooit gemeentes (of andere (semi-)overheid) als het gaat om ouwe zooi draaien. De reden dat we hier bijvoorbeeld niet kwetsbaar waren op een paar systemen was omdat we zo'n oude log4j draaiden dat de jndi lookup er nog niet eens in zat (natuurlijk zijn er nog genoeg andere CVE's op de oudere log4j versies).

[Reactie gewijzigd door potjandrie op 23 juli 2024 03:40]

[Kastermaster]

Er draaiden in 2014 nog genoeg gemeenten op Windows XP en meer recent nog op het eveneens niet meer ondersteunde Windows 7 (bron: https://www.parool.nl/ned...iligheidsrisico~b7dea52e/). Het is vaak ook een hele procedure om (archief)systemen over te zetten. Geen idee of dat voor dit probleem ook geldt.

[TheVivaldi]

En had de Belastingdienst niet nog enkele computers uit de jaren 90 draaien?

Edit: zelfs software uit 1982!
nieuws: 'Meer dan de helft van ict-systemen van de Belastingdienst is verouderd'

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 03:40]

[Kastermaster]

Ja, toevallig ken ik iemand die daar (mede) verantwoordelijk voor was. Omdat de kennis (letterlijk) aan het uitsterven is, hangt de dienst een nieuw groot en duur probleem boven het hoofd, vertelde hij mij.

[Vince_]

Klopt ze leiden daar zelfs intern mensen op om met COBOL aan de slag te kunnen

[pmeter]

Zijn die hele oude talen als COBOL ook onveilig, of juist superveilig omdat het zo archaïsch is dat het geen functionaliteit bevat die lek kan raken?

[DjoeC]

Nee, de taal is niet onveilig maar onjuist gebruik van een taal kan onveilig zijn. Zo kan ook Cobol dynamische SQL verwerken waardoor "fouten" kunnen ontstaan. Het is de programmeur/ontwikkelaar/software specialist waar het probleem zit. Ook bij 4/5/6/7 GL talen en/of frameworks zit er altijd een fout gebruik van de taal achter.

Het feit dat een taal creatieve constructies toestaat maakt niet dat daarmee de taal inherent onveilig is.

[Skyclad]

Natuurlijk kunnen er wel fouten in zitten die voor vulnerabilities kunnen leiden. Maar malware wordt over het algemeen gemaakt voor software dat op miljoenen systemen draait, niet op 3 antieke computers. Tenzij het een gecoordineerde aanval op die computers is natuurlijk. En je hebt kans dat de TCP/IP implementatie zwaar verouderd is en ook niet meer erg veilig, dus als je ze aan het Internet hangt is dat ook weer een probleem. Afgezien van het feit dat die Cobol programma's mogelijk niet onder Windows 10 of andere moderne OSes draaien en ze dus een oude, onveiliger OS moeten gebruiken.

[coolkil]

Cobol heeft nog een 'update' gehad in 2014
https://en.wikipedia.org/wiki/COBOL#COBOL_2014

[Globber]

Maar dit geldt voor heel veel bedrijven ook hoor, ik ben ook bij bedrijven binnen geweest waar alles via VBA macro's ging waarvan eigenlijk niemand wist hoe ze werkten dus die bleven maar draaien. Alleen zul je het bij bedrijven niet zo snel zien behalve als er iets fout gaat.

[Kastermaster]

Ik draai zelf mijn hele administratie via VBA macro's (maar daarvan weet ik dan weer wel hoe die werken ).

[DjoeC]

Computers is niet hetzelde als systemen is niet hetzelfde als software.

Wat is "verouderd"? Doet niet meer wat het doen moet?

Je wilt alles veilig houden en dat zal daar ook wel gebeuren. Een computer uit de negentiger jaren of ouder met ingebakken software die betrouwbaar deuren open of dicht laat gaan kan nog prima. Adressen software of databases uit de jaren negentig kan nog prima mits de structuur niet te veel veranderd is.

Belastingsoftware uit de jaren negentig kan eigenlijk niet meer want met de wijigingen die elk jaar komen wordt dat een hele grote soepzooi. Aan de andere kant: Opnieuw maken is erg complex omdat je "het oude" vaak toch weer moet mee bouwen.

[TheVivaldi]

Correctie: belastingsoftware uit de jaren 80. Ja, opnieuw maken is erg complex, maar zoals de Belastingdienst zelf al aangaf kan de oude software o.a. omzetbelasting niet verrekenen. Dat is een groot probleem en dan zul je toch een keer wat nieuws moeten maken, zelfs al is dat over 10 jaar wederom verouderd. Maar beter wat verouderd dan prehistorisch waarbij bepaalde dingen die moeten van de wet niet eens mogelijk zijn.

[coolkil]

ik vind het eerder een kunst dat software uit 82 blijkbaar nog steeds relevant is voor hedendaagse processen.

Volgens mij draait er bij de belastingdienst weinig op hardware uit de jaren 90. Software met een lange historie zal er nog genoeg draaien

[TheVivaldi]

ik vind het eerder een kunst dat software uit 82 blijkbaar nog steeds relevant is voor hedendaagse processen.

Heb je het artikel wel gelezen? De Belastingdienst zegt zelf namelijk dat de software allang niet meer voldoet.

[coolkil]

Niet voldoen is wat anders dan relevant zijn. Niet voldoen betekent dat het niet aan hedendaagse standaarden voldoet en das redelijk logisch voor 50 jaar oude software.

Als het ook niet meer relevant was hadden ze het gewoon weg kunnen gooien.

[Globber]

Dit heeft niet zo heel veel met overheid te maken hoor, dat is natuurlijk makkelijk bashen omdat het uit komt maar wees er maar zeker van dat heel veel commerciele bedrijven die jij gebruikt echt wel software draaien die 4 jaar of ouder is.
Ik zou dus vooral zeggen: Overschat niet hoe goed bedrijven dit doen ten opzichte van de overheid, uiteindelijk draait gewoon het meeste op oude software.

[phjk]

Trust me, dat gebeurt in het bedrijfsleven ook gewoon hoor

[Powermage]

Log4j zit in zeer veel zaken mee gebundeld, als beheerder heb je vaak geen idee dat dit component in gebruik is in bepaalde software, sterker nog, ik zag voorbeelden waar een software leverancier zelf log4j niet gebruikte, maar wel een bepaald component gebruikte voor een zoek en index functie die ook weer log4j gebruikte waardoor uiteindelijk die hele software vatbaar was.

[TonnyTonny]

Elastisearch gebruikt Log4j onder de motorkap. Zit in heel veel producten.
Ik heb hier ook al een aantal mensen uit de droom moeten helpen dat het alleen Apache en Tomcat servers zou betreffen. Je kunt dit ook gewoon onder je ISS website hebben zitten.

Zelfs in een applicatie die helemaal niet web-based is kan je aan de achterkant nog steeds een log4j logger hebben.

[Yoshi]

het kan zelf op hardware draaien, je moet het maar weten op dat moment. Efin, plotse toename in de communicatie naar de leveranciers, en die weer naar hun leveranciers van bepaalde componenten. Het stopt soms niet :-)

[satya]

Vaak gebundeld, maar niet geconfigureerd voor gebruik.

[jj71]

Het is helemaal niet vreemd dat software nog gebruik maakt van de kwetsbare versies, ook al zijn die 4 jaar oud of nog ouder.

Vaak wordt bij de start van het project een aantal libraries ingericht, en dan wordt de huidige versie van dat moment genomen. En vervolgens wordt de versie van die libraries niet zomaar meer bijgewerkt; dat gebeurt meestal pas als er een reden is om dat te doen, zoals wanneer er bijvoorbeeld zo'n security bug in blijkt te zitten.

In een aantal projecten voor een klant waar ik nu voor werk worden nog veel oudere versies van Log4j gebruikt (versie 1.2) die niet kwetsbaar zijn. We kunnen en gaan nu niet zomaar updaten naar 2.15 want de API van Log4j is tussen de 1.x en 2.x versies ook veranderd, dus updaten betekent ook dat we de software die er gebruik van maakt moeten aanpassen en dat is veel werk.

[gimbal]

Normaal wel ja, maar logging libraries worden altijd als ondergeschikte kindjes behandeld. Gevalletje "lekker belangrijk".

Dit zal de eerste keer in een lange tijd zijn dat men software gaat updaten specifiek om een logging library te upgraden.

[P1nGu1n]

Voor de volledigheid, je kunt het in die gevallen nog steeds mitigeren door %m, %msg en %message in log4j2.xml te vervangen door %m{nolookups}

Die optie wordt ook pas ondersteund vanaf 2.7.0

[Henk Poley]

Ah, cool. Commentaar hierboven aangepast. Daarnaast kan je de JndiLookup klasse uit de applicatie strippen. Wel even backuppen, voor het geval het niet meer start, binnen log4j2 schijnt het gewoon te werken.

locate log4j-core-2 # Of rust's sharkdp/fd ofzo
zip -q -d pad/naar/log4j-core.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

https://community.ui.com/...3c-4230-9d44-7394e4ba2542

Na iedere reboot je applicance 'vaccineren' is ook een optie 🤡: https://github.com/Cybereason/Logout4Shell

Daar worden ook nog wat JRE >=8u121 instellingen rondom 'trustURLCodebase=false' genoemd. Die klinken alsof ze inladen van code dat direct door Java werd gedownload blokkeren. Maar kennelijk kan dat weer gebypassed worden zolang jndi zelf nog werkt en de aanvaller iets op 127.0.0.1 toegankelijk kan neerzetten: https://twitter.com/marcioalm/status/1470361495405875200

[Reactie gewijzigd door Henk Poley op 23 juli 2024 03:40]

[jj71]

Je noemt een Twitter-bericht als bron. De informatie klopt inderdaad, maar een meer officiële bron is de pagina Apache Log4j Security Vulnerabilities op de website van Apache zelf.

[King4589]

Klopt, en als je log4j versie 1 gebruikt ondanks dat deze al ~6 jaar EOL is maar oa door/voor Red Hat nog "bijgewerkt" wordt is de kwetsbaarheid ook aanwezig maar geen work around. De POC's die vrijdag volop gebruikt werden werkten daar niet op maar ondertussen is duidelijk dat de in v1 gebruikte module ook kwetsbaar is en ook daar is een exploit voor beschikbaar.

[erwn]

Heb je daar meer informatie over? Of een link? https://github.com/apache...08#issuecomment-990494126 suggereert dat v1 enkel kwetsbaar is via configuratie.

[King4589]

Inderdaad die link die je stuurt bevat de meeste nuttige informatie al, de exploit zelf voor v1 kan ik nu even niet vinden. Maar het mag duidelijk zijn dat ook v1 een vergelijkbare kwetsbaarheid heeft, zoals jou remkop daar aangeeft. en dan heb je nog de andere kwetsbaarheden in een eol product.

[satya]

Je kunt het stuk wat verantwoordelijl is voor jndi uit de jar file halen, dat hebben we hier op een omgeving ook gedaan.

[Wasp]

log4j wordt regelmatig gebundeld met andere software, en is het zelfs onduidelijk óf log4j gebruikt wordt onderwater. Dus better safe than sorry.

[Keypunchie]

Als jij de JVM opstart met die parameter, dan kan er onderwater nog zo veel gebeuren, het wordt geblockt...

[bzzzt]

Sommige software wordt met een volledige Java omgeving gebundeld die 'onder water' opgestart wordt zonder dat je invloed hebt op de opstartparameters. Het is niet heel onredelijk om 'better safe than sorry' aan te houden, zeker als je al eerder een doelwit bent geweest.

[elmuerte]

export JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true
export LOG4J_FORMAT_MSG_NO_LOOKUPS=true

Dan zijn ook child java processen die opgestart worden mogelijk* beschermd.
*) mogelijk omdat het subprocess misschien gestart wordt met een lege enironment.

[bzzzt]

Lekker makkelijk, maar:

1) Niet iedereen draait op Linux/Unix
2) Weet je zeker dat die opties ook geparsed worden als je de JVM via libjvm.so opstart ipv command-line java?
3) Weet je zeker dat je die environment bij de goede user hebt ingesteld
4) Weet je zeker dat je log4j versie die argumenten ondersteunt
5) Als je in een strikte omgeving werkt: geeft je software leverancier nog wel garantie op de juiste werking als je aan die instellingen zit? En ben je dan nog wel gecertificeerd?

[elmuerte]

1) in Windows werken environment variables ook. Op de commandline met set, en anders via de Windows UI.
2) JAVA_OPTS niet, maar LOG4J_FORMAT_MSG_NO_LOOKUPS wel

Je hoeft de hulp voor andere mogelijkheden om het probleem aan te pakken in gevallen waar je geen directe controle hebt over de opstart parameters niet te accepteren. Maar om zou aan te komen met "lekker makkelijk"... Heb je liever dat deze opties geheim gehouden moeten worden zodat mensen die wel weten wat ze doen (3), zien of er log4j2-2.10.0.jar of later gebruikt wordt (4), geen rare software garanties hebben (5), niet nog een extra mogelijkheid hebben om de problemen aan te pakken?

[thePiett]

log4j2.formatMsgNoLookups=true werkt pas vanaf 2.10.0. En als je daarnaast geen idee hebt welke software allemaal gebruik maken van log4j, dan is het denk ik verstandig om de boel af te sluiten en een goede inventarisatie te maken.

[demianmonteverd]

Begrijp niet waarom je maar op +1 bent blijven hangen. Ik heb je plus 3 gegeven in elk geval. Deze RCE is zeer ernstig en er zijn te veel mensen die de impact onderschatten, zelfs hier heb ik de indruk dat mensen denken dat het wel mee zal vallen.

[thePiett]

Dank je wel!

[Freeaqingme]

Dat werkt pas vanaf versie log4j2 2.10.0 volgens mij. Verder moet je dan wel in kaart hebben welke applicaties allemaal log4j gebruiken. Dat is in een complex applicatielandschap niet altijd onmiddelijk duidelijk.

Ik vind het offline halen wat dat betreft ook wel verstandig. Als er ergens in een gebouw een prullenbak in de fik staat ontruimen we vaak ook eerst het hele gebouw, totdat we zeker weten dat alles veilig is, om daarna pas iedereen weer binnen te laten.

In de IT laten we vaak alles door draaien, ook als dat betekent dat je 'eventjes' vulnerable bent. Al met al zie ik dit ook in de toekomst wel opvolging krijgen.

[Verwijderd]

Het is afbakenen van risico's. Je ziet nu dat HvT de gehele publieke dienstverlening platlegt (inclusief website). Is dit proportioneel met de risico's?

De gemeente (en bedrijven) weten echt wel welke diensten extern beschikbaar zijn. Daar kun je op acteren maar het risico vanuit intern is kleiner dan vanuit extern. Waarom leggen ze dan de publieke balie's plat?
Ik vermoed (uit ervaring) dat de echte reden is dat niemand verantwoording durft te nemen en dat men daarom maar alles stil legt. Ze hebben zich al gebrand en willen niet nogmaals in de krant (anders dan, kijk ons even veilig zijn)...

Als er ergens in een gebouw een prullenbak in de fik staat ontruimen we vaak ook eerst het hele gebouw, totdat we zeker weten dat alles veilig is, om daarna pas iedereen weer binnen te laten.
Daarvoor moet je wel eerst vuur hebben. Dit is als iemand denkt dat er mogelijk een prullenbak in de fik kan vliegen. Daarom nu het gebouw ontruimen zodat we alle prullenbakken kunnen controleren op brandbaar materiaal. Is dat proportioneel?

In de IT laten we vaak alles door draaien, ook als dat betekent dat je 'eventjes' vulnerable bent. Al met al zie ik dit ook in de toekomst wel opvolging krijgen.
Sorry, ik weet niet welke sector je werkt maar in de 'IT' doen wij dat helemaal niet. We nemen adequate acties waar nodig. We gaan zeker niet 'eventjes' doordraaien als we vanaf buiten vulnerable zijn. Maar dat wil ook niet zeggen dat we maar gelijk intern alles platgooien als er iets gebeurd.

[Jeroen73]

Als er ergens in een gebouw een prullenbak in de fik staat ontruimen we vaak ook eerst het hele gebouw, totdat we zeker weten dat alles veilig is, om daarna pas iedereen weer binnen te laten.
Daarvoor moet je wel eerst vuur hebben. Dit is als iemand denkt dat er mogelijk een prullenbak in de fik kan vliegen. Daarom nu het gebouw ontruimen zodat we alle prullenbakken kunnen controleren op brandbaar materiaal. Is dat proportioneel?

Als de prullenbak niet in de fik staat, maar de brandweer of de EOD belt, dan ga je inderdaad evacueren.

[Verwijderd]

Er staat niets in de brand, er is geen rook, de brandweer belt dat je op moet passen voor brandbare items in de prullenbak en jij evacueert.....

Hoeveel bedrijven leggen hun dienstverlening momenteel neer?
Alle grote cloud providers worden getroffen door dit probleem.. Zie je die de boel maar platleggen?

De hele reactie van HvT is buiten proportie.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:40]

[EgMaf]

In denk dat je beter kunt zeggen dat het water tegen de gevel aan klotst, maar je zelf nog niet maar de begane grond bent afgedaald

[Freeaqingme]

Sorry, ik weet niet welke sector je werkt maar in de 'IT' doen wij dat helemaal niet. We nemen adequate acties waar nodig. We gaan zeker niet 'eventjes' doordraaien als we vanaf buiten vulnerable zijn.

Ja dat doe ik ook. Maar dat betekent niet dat 'we' dat sector-breed doen. Zie bijvoorbeeld ook dit bericht: CISA Tells Federal Agencies To Patch Log4Shell Before Christmas

Kerst is nog een dag of 10. Dan laat men het dus weldegelijk 'eventjes' doordraaien.

[RonnieKo]

@Naj_Geetsrev

Nou, ik kan mij voorstellen na dit akkefietje Tweakers: Gemeente Hof van Twente heeft geen toegang tot systemen door grote cyberaanval dat ze wat voorzichtiger geworden zijn. Wat op zich heel logisch is. Dan kan je relatief rustig uitzoeken wat je allemaal moet doen om het weer op niveau te brengen. Dan maar even wat ongemak voor de burgers en het personeel. De gevolgen als je niets doet zijn groter zie ook Tweakers: Opbouw IT-infrastructuur Hof van Twente na ranomware gaat twee jaar duren

[Reactie gewijzigd door RonnieKo op 23 juli 2024 03:40]

[c-nan]

Heel wat organisaties draaien hun applicaties in containers (van derden). Je hebt vaak geen inzicht hoe de image in elkaar zit en dat pas je ook niet zomaar even aan. Vaak is het dan wachten op een patch vanuit de leverancier.

[satya]

Dat klopt, wij draaien containers voor klanten die veiliger zijn dan de standaard die de grote jongens leveren, vaak staat log4j idd aan om data naar een logging omgeving van de klant te stream en.

[Skit3000]

Gemeente Almere had ook hun firewall tijdelijk zo kunnen inrichten dat medewerkers alleen toegang hebben tot de Citrix-servers vanaf interne IP-adressen. Dan nog kan er een rotte appel tussen zitten die iets probeert uit te halen, maar het beperkt het aantal mogelijke aanvallers tot zo'n 2000.

[GrooV]

Er was een hoop mogelijk maar als je niet snel genoeg kan handelen is dit dan maar de beste keuze. Hof van Twente heeft al een keer helemaal platgelegen door ransomware, ik snap ze wel.

Wat er beter kan is voor later, nu moet er gehandeld worden en dat hebben ze gedaan

[Skit3000]

Ik snap de actie wel, maar hier tot zondagavond mee wachten lijkt mij rijkelijk laat. Je zou verwachten dat het de eerste actie is die direct donderdag of vrijdag genomen zou worden om rustig de boel te kunnen patchen, en dan zondagavond het systeem weer vrij te geven.

[gaskabouter]

In ons ziekenhuis is eerst alle externe toegang uitgezet, vervolgens tegen maatregelen genomen, daarna uitvoerig getest en toen pas weer aangezet.

Allemaal heel lastig als je thuis zit en dienst hebt maar de enige juiste keuze denk ik.

[segil]

Nee, niet als je bijvoorbeeld afhankelijk bent van een externe partij die de server beheert en die bijgeschakeld moet worden. Die zal het ook wel druk hebben. Of als je vermoed dat het systeem al gecomprimeerd gecompromitteerd is.

[Reactie gewijzigd door segil op 23 juli 2024 03:40]

[Somoghi]

Heb je dat systeem in een drukpers gestopt?
Of bedoel je gecompromitteerd?

[segil]

[P1nGu1n]

Dat werkt alleen bij gebruik van versie 2.10 en hoger, toen werd die property pas toegevoegd.

[Barryke]

Inderdaad die workaround kan ipv updaten.
Misschien is nog niet in kaart welke software kwetsbaar is, of is er geen capaciteit om snel actie te ondernemen, waardoor ze deze voorzorgsmaatregelen nemen.

[Moortn]

Mogelijk willen ze eerst ook uitzoeken of er al hacks hebben plaatsgevonden en troep is geïnstalleerd. Als het niet al te veel problemen gaat geven kan het veel grotere problemen voorkomen door eerst alles te controleren en te patchen zodat ze zeker weten dat het weer veilig is.

[gitaarwerk]

Vind het eigenlijk wel een verstandig besluit. Zeker met data bij overheden die niet de capaciteit vaak hebben om direct alles te kunnen fixen en testen. Vervelend, maar liever dit dan alles lekken...of erger.

[Stijnvi]

Better safe than sorry
Stekker eruit en er kan niks gebeuren
Dan kan je vervolgens in een afgesloten omgeving testen of de fix werkt en dan alles weer opstarten

Het systeem fixen terwijl het nog online is, is hetzelfde als een bank die hun kluisdeur vervangt terwijl de voordeur open staat
Er hoeft er maar eentje net optijd binnen te zijn en je bent de pineut
Als je eerst de voordeur op slot doet kan je daarna op je gemak de kluisdeur vervangen en controleren of deze wel goed op slot gaat

[tweaknico]

Voor een aantal versies, voor andere versies moet je de code in een .jar aanpassen...
En je moet dit over een veelheid aan systemen en mogelijk meerdere applicaties.
log4j wordt ook vaak stilletjes meegeleverd.

[Tozz]

Dat is oud nieuws. Er is een nieuwe CVE waarbij dat niet meer werkt.
De enige fix op dit moment is Log4J JARs verwijderen.

[Kaaj]

Ik snap niet helemaal waarom de gemeentes hun Citrix systemen offline halen, op de github van NCSC wordt deze expliciet als 'not vuln' gekenmerkt. Iemand met meer verstand van zake die dit kan toelichten?

[dcm360]

De software die in de volksmond Citrix genoemd wordt (Citrix heeft ruim meer producten), is eigenlijk nooit het programma dat je echt gebruikt. In een Citrix-omgeving maak je gebruik van programma's die daar beschikbaar zijn gemaakt, en van al die programma's zijn de gemeenten nu aan het vaststellen of ze vatbaar zijn of niet. Door Citrix af te sluiten, zijn mogelijk vatbare programma's nu ook afgesloten.

[Bender]

Ik kan me voorstellen dat in een Citrix omgeving meer software draait waar gebundeld dan weer alsnog log4j aanwezig kan zijn.

[Woesjah]

https://support.citrix.com/article/CTX335705
Volgens mij is het onderzoek nog niet afgerond, dus wellicht dat NCSC iets te voorbarig is, maar dusver niks impacted.

[DJMaze]

Als er al eens bij je is ingebroken dan is meestal de reactie exponentieel.

Zo ken ik mensen waarbij de TV of wasdroger ooit in de fik vloog.
Nu zijn 's nachts en bij afwezigheid alle stekkers uit de stopcontacten.
Het is dat nog net niet de hoofdschakelaar in de meterkast wordt omgezet. want dan werkt Toon niet...
Anderen accepteren het risico en schatten een tweede keer als "nihil".

[Verwijderd]

https://nl.wikipedia.org/wiki/Paniekvoetbal

[satya]

Omdat er achter die citrx systemen misschien wel kwetsbare omgevingen zitten

[tweaknico]

Als je op de achtergrond bv een ELK stack gebruikt dan kan de ELK stack sneuvelen als de webserver/loadbalancer een bepaalde logregel aanmaakt en aan de ELK stack stuurt.

[japio010]

Misschien een rare vraag.
Maar interne systemen (die wel internet hebben, maar geen poorten open vanaf het internet) zijn die wel zo kwetsbaar? Ik neem aan dat externen hier niet bij kunnen.

[MR501]

bij log4j gaat het om de logs, kortom als zoektermen bijvoobeeld worden gelogd kan iemand in de zoekbalk van de site een log4j injectie gooien om vervolgens met een eigen script dat op een externe server gehost wordt de hele server over te nemen

[japio010]

Helder

[david-v]

Hele moeilijke vraag om te beantwoorden. Als je informatie die de klant kan opgeven (direct én indirect) door log4j2 laat wegschrijven op je interne systeem, dan is je interne systeem met internet toegang niet veilig. Het is zoals MR501 zegt een soort injectie aanval. Het beste is dan ook om overal waar log4j2 wordt gebruikt de lookup uit te zetten. In de nieuwste versie van log4j2 is jndi standaard uitgechakeld.

[Keypunchie]

Relatief late aktie, maar goed, beter ten halve gekeerd dan ten hele gedwaald.

Wat ik wel denk: Er zijn andere mitigaties mogelijk totdat je gepatcht bent, zoals je JVM herstarten met de juiste parameter en/of in je WAF de requests blokkeren.

Aan de andere kant, als gemeente heb je een complex applicatielandschap met vaak custom software, waar een update ver weg is, dus ik snap de uitdaging wel.

[BytePhantomX]

In denk niet dat een gemeente de skills heeft om de JVM met de juiste parameters te herstarten. De beheerders daar hebben heel veel complexe applicaties te beheren met vaak te weinig mensen en niet genoeg kennis, zoals je zelf ook al beschrijft. Ik zie dit dan ook als een mooie lessons learned wat de daadwerkelijke kosten zijn van het complexe IT-landschap in combinatie met te weinig en niet goed genoeg opgeleide IT-ers. Dit soor security incidenten maakt dat (eindelijk) eens pijnlijk duidelijk.

Verder zie ik hier allemaal oplossingen, waarbij het niet duidelijk is of ze houdbaar zijn of al is bewezen dat ze niet genoeg doen. Zo is al aangetoond dat WAF request blokkeren niets doen, aangezien de lijst met obfuscations bijna oneindig lijkt.

Ook is al duidelijk dat systemen die misschien alleen als backend van een website fungeren ook gehackt kunnen worden. Een gemeente die een formulier online heeft staan op een website die niet kwetsbaar is, maar waar het formulier in de backend wordt verwerkt door een kwetsbare server, is nog steeds kwetsbaar.

Gezien de complexiteit van een gemeente, beperkte kennis en het continu veranderende beeld over de kwestbaarheid, is het bijna ondoenlijk om echt adequaat te reageren en zeker te weten dat je niet meer kwetsbaar bent.

[satya]

Hangt af van de gemeente, hoe groter die is, hoe meer ze zelf doen. Een beetje gemeente heeft meer ITers in dienst dan menig IT bedrijf.

[segil]

Gemeente waar ik als externe werk, heeft ook enkele systemen uitgezet voor verder onderzoek naar patching / mitigatie.

[CyberTijn]

Better safe than sorry. Verstandige keuze.

Ik zie de mitigerende maatregelen en workarounds hier volop voorbij vliegen in de comments, en zelfs Tweakers elkaar tegenspreken over wat wel werkt en wat niet. Veel gemeenten beheren slechts een beperkt deel van hun IT infrastructuur, en voeren regie over de rest waarbij ze leveranciers aansturen. Als zelfs grote leveranciers (nog) niet kunnen aangeven welke producten kwetsbaar zijn, kun je ook niet van een (vaak kleine) IT afdeling verwachten dat ze direct op het netvlies hebben wat wel en niet kwetsbaar is, en even in een paar uurtjes de verschillende workarounds voor de verschillende versies van log4j toepassen.

[david-v]

Hof van Twente laat in een Facebook-bericht weten dat de gemeente ook zijn systemen preventief offline heeft gehaald.

Eigenlijk best wel triest dat je moet uitwijken naar een commerciële partij om aan je burgers uit te leggen dat de website tijdelijk uit de lucht is. Ik snap wel waarom ze offline moeten, als je voor dergelijke calamiteiten op deze manier moet uitwijken. Misschien zaken wat beter op orde krijgen?

[Wachten...]

Er is overigens ook een Patch voor Unifi controllers
https://community.ui.com/...bb-4979-8b10-99db36ddabe1

Net mijn Unifi Dream Machine maar even geupdate.

Hierover heeft Lawrence Systems een video gemaakt !
https://www.youtube.com/watch?v=_sC7ntv0PUY

[Wachten...]

Weet iemand of dit ook een beveiligingsprobleem is bij Synology NAS apparaten?

[c-nan]

Synology apparaten zijn niet kwetsbaar, zie https://www.synology.com/...dvisory/Synology_SA_21_30

[Wachten...]

Supersnelle reactie. Dank je wel dit stelt mij weer gerust. Niet dat ik ooit zulke oude dingen draai op mijn systemen, maar zoals sommige al aangeven hier komt software soms gebundeld en weet je het welke versie ergens in verwerkt zit.

[JaymzHetfield]

Wel even opletten als je evt. Docker containers op je Synology NAS draait, zoals Unifi Controller (voorbeeld).

[Michael_OsGroot]

Officiele reactie Synology:

https://www.reddit.com/r/...l_zero_day_vulnerability/

I confirmed with our PSIRT task force that Synology does not implement or use log4j across any of our products.

However, this obviously may not apply to any 3rd-party packages, containers, and VMs you have on your devices. Make sure you update those or apply the mitigation.

[Reactie gewijzigd door Michael_OsGroot op 23 juli 2024 03:40]

[Wachten...]

Top dank je wel voor de extra bevestiging!

[Cobalt]

Update het artikel. 2.15.0 is vervangen door 2.16.0 https://logging.apache.or...anges-report.html#a2.16.0

[Zidane007nl]

Waarom? In 2.15.0 is de CVE opgelost. In 2.16.0 hebben ze JNDI standaard uitgezet en ondersteuning voor message lookups verwijderd. Dat kan een breaking update zijn.

Update: ik zie dat de security pagina van Log4j is geüpdatet met een nieuwe kwetsbaarheid (CVE-2021-45046)

[Reactie gewijzigd door Zidane007nl op 23 juli 2024 03:40]