Belgisch ministerie van Defensie kan maand na log4j-aanval weer extern mailen

Het Belgische ministerie van Defensie kan bijna vier weken nadat het werd aangevallen via een log4j-kwetsbaarheid weer e-mails sturen naar externe mailadressen. Daarmee zijn de gevolgen van de aanval nog niet voorbij; veel hr-diensten werken bijvoorbeeld nog niet.

De overheid bevestigt volgens HLN dat er weer e-mails naar externe adressen gestuurd kunnen worden. Daarbij geeft een woordvoerder wel aan dat die heropstart van het mailverkeer 'mondjesmaat' zou gebeuren. Pas op 12 februari moeten de gevolgen van de aanval voorbij zijn. Defensiepersoneel kon eerder al intern mailen naar @mil.be-adressen. Het kabinet zegt ook dat de aanval nooit een impact heeft gehad op Defensie-missies en dat deze communicatie via andere kanalen verloopt.

Naast de mailsystemen, werd ook internettoegang voor militairen getroffen. Dinsdag konden militairen nog niet 'iets op internet opzoeken', schrijft het medium. Hr-diensten waarmee militairen extra vergoedingen kunnen aanvragen voor bijvoorbeeld wachtdiensten of buitenlandse operaties waren toen ook nog niet beschikbaar. Het is onduidelijk of deze internettoegang en hr-diensten inmiddels weer toegankelijk zijn.

Het Belgische ministerie werd op donderdag 16 december slachtoffer van een aanval die van een log4j-kwetsbaarheid gebruikmaakte. Het ministerie nam daarop quarantainemaatregelen om de systemen te isoleren en te kunnen controleren of de systemen veilig zijn. Tot woensdag waren de precieze gevolgen van die maatregelen niet duidelijk.

Reacties (58)

[Verwijderd]

Bijzondere mailserver hebben ze dat er Java in zit… 🙄 vraag me af welke exotische software dat is.

[Blokker_1999]

Het systeem dat kwetsbaar was hoeft niet noodzakelijk de mailserver te zijn. Maar dat systeem kan wel als toegangspunt gebruikt zijn om verder in het netwerk te bewegen. Het is ook niet dat alleen maar de mailservers bij defensie eruit lagen. Heel de internettoegang was afgesloten, voor alle systemen.

[WhiteDog]

Apache James, zou dat kunnen?

[Verwijderd]

Wow, nog nooit van gehoord, maar wellicht ja. Bedoel, mail implementatie in Java, je verwacht het niet. 🙈

[Carharttguy]

Ik denk dat het eerder omgekeerd is, en dat het eerder een uitzondering is als je iets zou vinden waar geen Java implementatie van is.

[michielRB]

Ik moet zeggen dat ik in het verleden ook in de doctrine zat dat 'java is een resource hog' en 'vol met gaten'
newsflash, _iedere_ slecht geprogrammeerde applicatie is een resource hog en zit vol met gaten. Dat ligt niet aan java.
Ik ben inmiddels met een aantal java applicaties geconfronteerd die toch werkelijk erg goed en veilig in elkaar steken. Als voorbeeld: [url="https:savapage.org"]SavaPage[/url], een print management applicatie die boven op CUPS werkt.
Overigens een Nederlandse ontwikkelaar die opensource en open content hoog in het vaandel heeft staan. (bedankt Rijk!)
En zo zijn er wel meer voobeelden van prima java applicaties.

[Sixie]

mail implementatie hoef geen java te zijn, maar een van zijn module, bijv het Search Index, of Logs en dat is al voldoende

[Yoshi]

lijkt me niet zoveel bijzonders aan, genoeg systemen die vatbaar zijn voor die bug in de log4j software.Er is ook nergens gezegd dat het systeem dat die mailinfra (deels) draaide nergens niets anders had draaien dat die bug had. Het was (hopelijk niet meer is ondertussen) dan ook vooral een zoektocht naar software waar zelfs de fabrikant niet van wist dat er log4j2 draaide in het één of ander obscuur codehoekje van hun software dat vele uren heeft gekost.

of via een ander systeem tot bij die mailserver geraakt via log4j2 bug op die eerste.

[Reactie gewijzigd door Yoshi op 31 juli 2024 07:40]

[Cyb]

Zo "bijzonder" is dat niet. Traditioneel worden veel dedicated mail server software pakketten in C/C++ geschreven, o.a. vanwege de lage resource footprint, maar zodra het om ingebouwde mail software componenten voor in een custom enterprise systeem gaat, komt enorm veel Java voor. Mail functionaliteit zit al meer dan 20 jaar in Java EE.

[Mortis__Rigor]

Of ze gebruikten iets zoals Zimbra voor hun mail omgeving. Zo exotisch is dat niet.

[michielRB]

Er zijn best wat (moderne) groupware projecten op basis van Java... Omdat jij er niet van gehoord hebt is het 'exotisch'?

[spnw]

Ondanks alle nadelen hebben ransomware en deze aanval een voordeel voor systeembeheerders. Namelijk, er zit nu een prijskaartje aan niet updaten, oude dingen blijven gebruiken en/of het geen goed IT beleid hebben. Vroeger kwam je weg met "maar het werkt toch?", als je beheerder weer eens kwam zeuren om die zes jaar oude firewall te updaten. Nu kan een beheerder veel beter duidelijk maken wat het belang is van een goed IT beleid, omdat er veel voorbeelden zijn van de kosten van zo'n aanval. En daar denken de centenknijpers (management) aan, meer niet.

[DutchHammer]

Moet zeggen dat het de afgelopen jaren al wel beter is geworden bij een hoop bedrijven; ze zijn al een tijdje wakker.

Nu nog de developers die zich wat meer bewust zijn worden van LCM op dependencies.. Hier gaan we in de zeer nabij toekomst* het CI/CD process aanpassen... Waarbij builds gewoon failen ipv alleen een waarschuwing geven dat er een (flinke) vulnerability in zit..

*Om zo even de kans te hebben om het samen met developers op orde te krijgen.

[chime]

Tja, als een product owner moet kiezen voor een nieuwe feature of een vulnerability wegwerken

[TMC]

Als het voor de product owner duidelijk is wat de potentiële risico's zijn en hij/zij kiest ervoor die risico's te accepteren, dan is dat toch prima? Dat is nou eenmaal de taak van een product owner: afwegingen maken.

[cricque]

Dat is mooi, maar dikwijls is het toch : die nieuwe feature moet er zijn tegen dan, want klant x moet dit hebben. Dat is "real life" en helaas in merendeel van de bedrijven werkt dit zo. En dit is bij mij althans dikwijls een frustratie, wetende dat het niet goed is, maar het toch moeten produceren. Ben ik ook trouwens mee gestopt. Oftewel doen we het correct oftewel doen we het niet. Bij een bug wil ik hiervan afwijken, en zo snel mogelijke en oplossing bieden, maar als de fix er is, dan wil ik wel meteen het correct doen ook. En wat die product owner, zijn baas of de baas van de baas wilt, dat is hun probleem. Ik doe het correct of ik doe het niet meer, en dan zoek je maar lekker iemand anders. Veel beter voor mijn gemoedsrust .

[TMC]

Dit gaat volgens mij meer over de minimale kwaliteit die jij wilt leveren om je comfortabel te voelen. Dat is een andere discussie. Overigens denk ik dat het zeer goed is dat je dat doet.

[Stufipower]

De belangen zijn niet helemaal optimaal: nieuwe features genereren op korte termijn omzet, waar vulnerabilities wegwerken onzekere risico’s mitigeren. Vaak wordt zekere omzet geplaatst boven mogelijke problemen later. Ook in de beoordeling van de product owner. Het is de verantwoordelijkheid van de developers om hard genoeg te zeuren over vulnerabilities zodat er tijd voor gemaakt kan worden. Zij moeten inschatten hoe belangrijk het is. Als het goed is, kloppen zij namelijk niet alleen code maar denken zij mee in het belang van het bedrijf vanuit een technisch oogpunt en zij hebben het beste zicht op dit onderdeel.

[DutchHammer]

Een goede security afdeling met het mandaat om te roepen dat in zo'n geval als nu, alle prio's vervallen (nou ja.. bijna alle) totdat je dit opgelost hebt is ook wel handig om te hebben.

[TMC]

In jouw stukje tekst zit de aanname dat het slecht is om korte termijn winst voorrang te geven. Maar dat is maar de vraag, daar is geen goed of fout antwoord op te geven. De product owner is als het goed is dagelijks in gesprek met stakeholders uit de business, als de business korte termijn belangrijker vindt, dan is dat blijkbaar wat belangrijker wordt geacht.

[Reactie gewijzigd door TMC op 31 juli 2024 07:40]

[Stufipower]

Ik bedoelde vooral het psychologische deel te belichten: 100% zeker 1000 euro krijgen wordt dan ook waarschijnlijk gekozen boven 20 procentpunt minder kans op 8000 euro verliezen. Dat zou dan niet optimaal zijn. (Ja, de getallen zijn een voorbeeld en in de praktijk zijn ze onzeker, maar je snapt mijn punt wel denk ik).

[TMC]

"Dat zou dan niet optimaal zijn" -> er is geen optimum. Het is een subjectieve risico-afweging. Het is de taak van de PO om die te maken.

[FreezeXJ]

Dankzij een paar van dit soort fouten hangt er nu een helderder prijskaartje aan die keuze. Risico op een maand omzet-verlies of toch net die ene feature die door 50 man gevraagd wordt. Tot nu toe was het 'dat zal toch wel meevallen', en nu roept (bij Defensie) vermoedelijk niemand dat meer.

[eborn]

Het is dan wel belangrijk om elke dag minimaal 1 build te triggeren. Vooral bij applicaties die enkel maintenance ontvangen krjigen natuurlijk niet elke dag een build te verwerken.

[DutchHammer]

Jup, geheel waterdicht zou het dan ook niet worden.. Maar dan hebben we nog de verschillende scans op de servers die ons een seintje geven ;-)

[Standeman]

Hoewel je over het algemeen gelijk hebt, sla je de plank in dit geval een beetje mis. Het grappige is dat juist door het niet updaten van systemen deze niet kwetsbaar waren voor dit lek. Ik ken zelf een aantal systemen die nog op log4j 1.2 zitten welke dus geheel veilig zijn. Het prijskaartje hier zat juist bij het wel up to date zijn met je software.

[FreezeXJ]

Log4j 1.x is niet 'veilig', het wordt gewoon al jaren niet onderhouden Da's nogal een verschil. Misschien dat je er in dit geval geen last van had, maar er wordt niet actief gechecked op gaatjes.

[gimbal]

lo4j 1.2 heeft dan weer andere exploits, niet updaten is alsnog niet een redding. Er is wel meer wat er niet up to date is gehouden in die systemen dan... ook stokoude Tomcat versies wellicht? De gemiddelde pentester zal al in de handen beginnen te wrijven.

[thePiett]

Klopt. Ik kan me echter nog wel herinneren dat bijvoorbeeld in het Windows XP tijdperk al genoeg exploits rondzwierven die de noodzaak tot updaten onder de aandacht brachten. Het booster blaster virus bijvoorbeeld, een ongepatchte Windows XP (ik weet even niet of Windows 2000 ook vatbaar was) aan het internet was binnen een minuut besmet en rebootte zichzelf

[Reactie gewijzigd door thePiett op 31 juli 2024 07:40]

[Qwerty-273]

Dat was Blaster en/of Sasser. En die wormen werden destijds ook aangewezen als het bewijs om it management te overtuigen van een goed patch beleid en wat de kosten kunnen zijn als dat niet zo is. Maar dat komt weer op de achtergrond na een periode omdat alles goed gaat, en dat het toch wel erg duur is en er gekort moet worden op kosten.

[Verwijderd]

En dat blijft gewoon slecht beleid. Zodra een pakket of hardware aangeschaft is zal er al rekening moeten gehouden met afschrijving. Dit moet gewoon in het budget opgenomen worden, dan is er iets niet erg duur. Ik praat heel makkelijk, dat weet ik, maar als je het niet doet maak je jezelf als bedrijf heel moeilijk.

[ViTO_xp]

booster virus

[elmuerte]

Dat betwijfel ik. Equifax is al bijna 5 jaar geleden. De mentaliteit zal altijd "dat overkomt ons niet" blijven als er gekeken wordt naar de kosten van een gezond security beleid en (echte) backups.

[michielRB]

De mentaliteit zal altijd "dat overkomt ons niet" blijven

Misschien dan maar een keer de 'rogue' sysadmin spelen en _alleen_ de mailboxen van de directie op 'intern only' zetten omdat er een direct gevaar voor besmetting dreigt.

[Grrrrrene]

Jup, na de aanval op VDL recent is bij ons op werk tijdens de nieuwjaarstoespraak van onze directeur nog eens de aandacht gevestigd op onze data-veiligheid. Eind vorig jaar is er een soort "phishing-testmail" rondgestuurd met zo'n neplink die, als je erop klikt, een berichtje naar ICT stuurt dat je in de test getrapt bent.

En waar ik mensen altijd verfoei als ze in zo'n obvious scam trappen, was ik dit keer ook slachtoffer. Niet om mezelf vrij te pleiten, ik had gewoon beter moeten opletten (maar druk druk druk zo vlak voor de kerstvakantie), maar een collega probeerde me net daarvoor een document door te sturen, maar deed dat met een link waar ik niet bij kon en op een nogal ongebruikelijke manier (doe gewoon dat document bij het attachment). Ik verwachtte dus een document, krijg ik een mail met een downloadlink naar "your document" en in de haast om het werk voor kerst af te krijgen, klik je er dan zonder verder onderzoek op.

En dat is denk ik ook de kracht van die scams: het gaat niet om hoe makkelijk het te herkennen is, maar om dat heel kleine percentage ontvangers dat zo'n mail verwacht. Zo ook met mails van een bank: de mensen die erin trappen zijn ofwel bijna digibeet en weten gewoon niet beter of ze verwachten exact die mail van hun bank. Ze hebben bijvoorbeeld net een nieuwe creditcard aangevraagd en de juiste bank stuurt ze daar net een mail over met het verzoek even in te loggen om hem te activeren. Met miljoenen ontvangers, zitten er altijd genoeg tussen die op die link zullen klikken.

Maar goed, gelukkig was dit slechts een test, maar ik schrok echt van mezelf dat ik op die link had geklikt (schijnbaar samen met 1/4e van de medewerkers nota bene).

Ik vraag me ook af hoe je als groot bedrijf met >1000 medewerkers gaat voorkomen dat helemaal niemand ooit op zo'n link gaat klikken. Ik denk dat jezelf wapenen tegen de situatie DAT er ransomware op je netwerk is gekomen, een veel verstandigere keuze is.

[hexeye]

Assume breach wordt dat wel genoemd, dat is een bepaalde mindset mbt inrichten van je infrastructuur. Het is ook niet perse het een of het ander, awareness en technische maatregelen sluiten elkaar niet uit maar vullen elkaar aan.

[Mantis]

Klopt, awareness is maar een deel van het verhaal. Insider threat is niet te onderschatten.
Ransomware criminelen bieden grof geld als je hen durft helpen en ongeveer 1 op 5 geslaagde aanvallen zijn dankzij interne hulp.

[OxWax]

Ik las ooit dat een bedrijf dat werd, in het grootste geheim, werd ingehuurd om de security te testen, simpelweg USB-sticks liet slingeren op de parking. Bleek het tijdens de vergadering de directeur te zijn die de stick had 'getest'. Had uiteraard ook de meeste rechten

[michielRB]

Had uiteraard ook de meeste rechten

Misschien qua toegang tot bestanden, daar kan ik inkomen, maar qua systeembeheer dan weer helemaal niet.
Ook (juist!) een directeur zou met een account zonder systeembeheer permissies moeten werken.

[OxWax]

"zou moeten ...." nu wel , in dat bedrijf
Remember de ransomware attack in die NL universiteit? Hoe zou dat gebeurd zijn? (heb dossier hier nog ergens slingeren, eens lezen )

[gertm]

Ooit deed ik als consultant een opdracht bij een groot bedrijf. Op een bepaald moment moest ik in hun serverzaal zijn, en daar had ik geen toegang. Ik dus naar security om te vragen of ze dat konden oplossen. Ze vroegen of ik iemand kende die toegang had. Ja, jullie lead-architect. Ok, dan kopieren we even al zijn toegangen naar jouw badge...

[michielRB]

Mijn god. Ik mag hopen dat je die badge vervolgens geweigerd hebt te gebruiken en deze 'security helden' even flink de les gelezen en aangegeven bij de directie van het bedrijf?

[Eonfge]

Waar onze organisatie vooral geluk mee heeft gehad, is de goede pipeline waar we hard aan hebben gewerkt. In geval van nood kunnen we de hele OTAP straat door in ongeveer twee uur, dus als er zo'n kritieke fout als log4j aan het licht komt kunnen we snel schakelen.

Ik zie het juist fout gaan bij grote, bureaucratische, organisaties waar de processen zo stroperig zijn dat het twee weken duurt om een update uit te rollen.

[crazyx]

En wat moet je dan in de praktijk doen?
Gewoon toch ook wachten tot de library gepatcht is. Anders moet je een groot stuk herschrijven om een andere library te gaan gebruiken (afhankelijk vd implementatie).

[Blokker_1999]

Namelijk, er zit nu een prijskaartje aan niet updaten, oude dingen blijven gebruiken en/of het geen goed IT beleid hebben.

En dan denk ik: wat heeft dit met log4j te maken? De dag dat de update uitkwam is ook de dag waarop het misbruik begon. Je moet nog tijd krijgen om te updaten ook en je moet door al je acceptatietesten heen geraken.

Leuk dat je direct met zo een nieuwtje van wal steekt, maar het is niet alsof organisaties die door log4j getroffen zijn jaren lang achter hebben gelopen met updates.

[FrostyPeet]

Kan mij voorstellen dat geheime e-mail over hun eigen server gaat. Maar gewone e-mail had toch (tijdelijk) uitbesteed kunnen worden aan een of andere dienst met overname van domeinen en e-mail adressen? Ik neem aan dat de encryptie certificaten dan ook werken. De eerste de beste clouddienst kan essentiële e-mail adressen binnen 2 werkdagen overnemen.

Niets op internet kunnen opzoeken lijkt me ook snel tijdelijk te regelen voor "google" of "facebook". De eerste de beste 4G router is met een utp kabeltje op een pc aan te sluiten.

[iemand943]

Ik denk dat het Belgische ministerie van Defensie best wel een reden heeft om het op deze manier te doen.

[zwartpet]

Als defensie je mail ff laten afhandelen door een clouddienst of iets dergelijks is denk ik echt niet de bedoeling.
Niets op internet kunnen opzoeken is denk ik ook niet zo snel te fixen, in zo'n omgeving gaat dat allemaal via een intranet met weer virtuele machines waar een gelimiteerde browser op te starten is. Ff een utp kabeltje prikken is denk ik wat te makkelijk verwoord.

[jeroen79]

Overgaan op een of andere dienst lijkt me niet eenvoudig, zeker voor een ministerie van defensie.
Je zal het moeten aanbesteden en die dienst en mensen moeten screenen.
En dan zal je de oplossing nog moeten ontwerpen, testen, uitvoeren, gebruikers inlichten, etc.

En bij een tijdelijke noodoplossing zul je ook nog moeten bepalen wat je wel en niet meeneemt.
Wanneer is mail geheim en wanneer niet? Kunnen je medewerkers dit voldoende onderscheiden of wil je toch alles streng beveiligd hebben?

[michielRB]

* michielRB mompelt iets over pro actief en fallback systemen....

[jeroen79]

Hoe lastig of gemakkelijk zou het zijn om in dit soort zaken fallback systemen te bouwen.

Dan moet je fallback systeem niet alleen op een andere locatie bij een andere provider staan maar ook nog eens andere software met andere afhankelijkheden gebruiken.

[michielRB]

Als een organisatie, als bijvoorbeeld een ministerie van defensie, vindt dat email dusdanig belangrijk is dat het altijd beschikbaar moet zijn, dan zijn daar gewoon mogelijkheden voor. ALS die keus inmiddels is gemaakt moeten ze niet gaan piepen dat het veel geld kost. Voor niets gaat de zon op...

[LurkZ]

Hoe lastig of gemakkelijk zou het zijn om in dit soort zaken fallback systemen te bouwen.

Dat is geen argument dat defentie mag gebruiken.
"De vijand is gemeen want ze schieten terug." is een soortgelijk argument.

[Verwijderd]

Is dat diezelfde Carine Knapen die elke complottheorie die er te vinden is op het www met vuur verdedigt, Corona ontkenner en antivaxer is, en ook de familie van de militair die Marc van Ranst wilde afmaken maar zich uiteindelijk zelf door het hoofd schoot, wat ook weer aanleiding voor haar was om daar complottheorieën over te verspreiden, als advocaat bijstond?
Betrouwbare bron dan wel!

[michielRB]

De miliairen werken en communiceren inderdaad via whatsapp en orders aan het wachtpersoneel geschieden ook via whatsapp of messenger ( ! )

Eigenlijk is hier maar 1 reactie op:

Ik voel een variant op de WA hack aankomen:
Officier van de wacht: Ik heb een nieuw nummer, haal mijn oude nummer uit je telefoon. Over 10 minuten komt er een konvooi aan met goederen, laat dit konvooi zonder controle door.

[Reactie gewijzigd door michielRB op 31 juli 2024 07:40]

[JonPalle]

Ik ben er niet bij geweest, de details weet ik dus niet. Echter is de kans dat het nog een keer gebeurt reëel en niet alleen in België maar in ieder land en mogelijk op de zelfde manier maar waarschijnlijk met een nieuwe truc. Een sluitende alles omvattende oplossing is er voorlopig niet of je moet gaan werken in de vorm van een blokchain technologie. En zelfs dan.

[mutley69]

Kan het belgisch leger e-mail gebruiken? Vandaar dat Putin zo gek wordt als een razende hond!