Honderden Zimbra-servers in Nederland kwetsbaar voor ernstig beveiligingslek

Uit onderzoek van The Shadowserver Foundation blijkt dat 223 Zimbra-mailservers in Nederland kwetsbaar zijn voor een kritiek beveiligingslek. Dit lek stelt aanvallers in staat om op afstand commando's uit te voeren op getroffen servers.

Wereldwijd zijn bijna 20.000 kwetsbare servers geïdentificeerd, waarbij Duitsland, de Verenigde Staten en Rusland koplopers zijn met elk meer dan 1500 ongepatchte systemen. Nederland telt 223 kwetsbare mailservers. Het beveiligingslek, dat een maximale ernstigheidsscore van 10 heeft gekregen, kan worden uitgebuit door simpelweg een e-mail te versturen met kwaadaardige code in het CC-veld. Het lek wordt gevolgd onder de CVSS-code CVE-2024-45519.

Zowel Zimbra als het Digital Trust Center van het ministerie van Economische Zaken hebben begin oktober al gewaarschuwd voor deze kwetsbaarheid. Zimbra heeft vorige maand patches uitgebracht om het probleem te verhelpen. Het gaat om versies 9.0.0 Patch 41, 10.0.9, 10.1.1 en Zimbra 8.8.15 Patch 46. Organisaties worden geadviseerd om de beschikbare beveiligingsupdates zo snel mogelijk toe te passen, aangezien er al actief misbruik van wordt gemaakt door cybercriminelen.

Reacties (26)

[FairPCsPlease]

Ik heb de klantenservice van Online.nl gebeld, die het heeft nagevraagd bij de technische staf van hun maildienst en ik kreeg het antwoord dat Online.nl de recentste update al heeft geïnstalleerd, dus webmail van Online.nl (dat ook gebruik maakt van Zimbra) zou veilig moeten zijn.

[tisvonkje]

De onderzoekers zijn niet dezelfde mensen als de mensen die zimbra draaien.
Verder maakt het wel uit of je zelf op je eigen linux server met 2 gebruikers zimbra draait, of een organisatie met > 10.000 gebruikers waarvoor mail een kritische taak is.
Het sturen van -9 is overigens niet de juiste manier om een server down te krijgen.

[sapphire]

De onderzoekers zijn niet dezelfde mensen als de mensen die zimbra draaien.

Daarom zegt @sjorsjuhmaniac ook "Als ze de RCE hebben" want: "Dit lek stelt aanvallers in staat om op afstand commando's uit te voeren op getroffen servers."

[niekdejong]

Zo hebben onderzoekers het toen ook gedaan met Log4J. Die RCE was zo wijdverspreid & makkelijk uit te buiten dat ze preventief de exploit hebben gebruikt om de workaround toe te passen, waarna de servers 'veilig' waren totdat e.e.a. herstart werd.

[tisvonkje]

dat was niet duidelijk uit de oorspronkelijke post (later gewijzigd)
Overigens is het gebruiken van een remote exploit (ook al is het met goede bedoelingen) strafbaar en ik zou zelf als onderzoeker nooit het risico nemen dat ik wellicht meer (of andere) dingen kapot maak.

[air2]

Als mail een kritische taak is, neem ik aan dat je JUIST de servers al geüpdatet hebt. Maar goed, theorie en praktijk en iets wat weerbarstiger is etc.

[CH4OS]

Er zijn nog veel beheerders met een "If it ain't broken don't fix it" mentaliteit, die bijvoorbeeld ook een aangepaste installatie hebben.

[Zoop]

Is een verklaring, geen excuus, uiteraard.
Een aangepaste installatie heeft zijn bijbehorende nadelen, dit is daar een van, daar dien je als beheerder toch op voorbereid te zijn. Ongeacht de situatie dien je toch altijd in staat te zijn om patches door te kunnen voeren. Beheerders die dat soort statements maken kan je als baas zijnde er beste maar zo snel mogelijk uitwieberen.

[Kabouterplop01]

Maar 't is juist broken, alleen is het vaak lastig om uit te leggen.

[CH4OS]

Hangt ook wel van de definitie van "broken" af.

[g_v_rijn]

Dat 'de beheerder van mailserver(s) in zijn 1'tje besluiten neemt - als dat al zo zou zijn, is het betreffende bedrijf op meerdere fronten ongeloofwaardig.

[SunnieNL]

Verder maakt het wel uit of je zelf op je eigen linux server met 2 gebruikers zimbra draait, of een organisatie met > 10.000 gebruikers waarvoor mail een kritische taak is.

Dat maakt voor hackers niet zo veel uit. Botnet client is botnet client. Hooguit dat er wat meer data op staat die je ook nog kan stelen naast het ding in een botnet te zetten.

En wat maakt het verder uit of je het voor 2 of 10.000 gebruikers hebt draaien? In beide gevallen is het gewoon noodzaak om zo snel mogelijk te updaten. Een kritieke patch een maand laten wachten en zelfs 8 dagen na een grotere waarschuwing in de media niet reageren is in beide gevallen slecht. Die 10.000 gebruikers kunnen heus wel ergens 10 minuten zonder mail (als het al niet korter is om de patch te installeren)

[CH4OS]

Als je een aangepaste installatie hebt, kan het patchen zo van 10 minuten, naar een hele dag downtime gaan.

[SunnieNL]

ach ja, maar dan heb je het risico vast ingecalculeerd toen je besloot om een volledig aangepaste installatie te gaan doen en heb je ook een patch plan liggen. Net zoals je dan nu het risico neemt al een maand niet te patchen en straks in het nieuws te komen met een gigantisch datalek omdat je een zeer kritiek probleem waar al een maand voor wordt gewaarschuwd niet hebt geinstalleerd.

Er zijn al minimaal 3 weekenden geweest en een mailserver platleggen zorgt hooguit dat de mail wat later binnenkomt. Vorige week is hij ook al opgenomen in de CISA KEV lijst waardoor hij al helemaal prio 1 zou moeten zijn om ASAP te installeren buiten alle maintenance windows om.

[cricque]

Dat zou moeten ja, maar theorie en praktijk is dikwijls heel anders. Tevens ga je in een groter bedrijf ook je tijd moeten verantwoorden. Tegen je manager: ja ik heb een dag nodig om dit te doen... Ja dat zal moeten wachten tot er tijd is. En zo gaat het dikwijls (spijtig genoeg)

[SunnieNL]

Dan moet je in een groter bedrijf maar naar je CISO of andere security manager gaan in plaats van je manager. En anders heel goed documenteren dat jij je manager hebt gewaarschuwd voor het feit dat het bedrijf een groot risico heeft op de continuiteit van de standaard bedrijffsvoering door het niet doorvoeren van een kritieke vulnerability gemeld in de CISA KEV lijst.

[uiltje]

Ik ken situaties waar het gebruik van een gepatchte versie van OpenSSL nodig was (toen was hardware nog niet via "engines" aan te roepen). Ik denk achteraf dat dat onveiliger was omdat de updates van OpenSSL waren uitgeschakeld; anders raakten we de eigen patches kwijt.

Durf het nu te zeggen omdat dit lang geleden was; tegenwoordig hoef je dat soort patches niet meer toe te passen. Maar voor specifieke software configs zal het nog steeds gelden. Ander voorbeeld: tedelijk wat problemen met plugins in Eclipse gezien; het gebruik van een oude versie is echt noodzakelijk. En dat is Java, zo'n beetje gemaakt om software samen te laten werken.

[cricque]

Helemaal mee eens, maar er zijn genoeg grote bedrijven en overheden waar het zo ook niet werkt. Maar daarmee is het probleem niet opgelost. Tevens zal je directe baas dit ook niet leuk vinden. Die zal dit dikwijls zien: hij gaat janken bij iemand anders. En dan is er ook gewoon de laksheid van bepaald personeel nog aan toe te voegen als mogelijk oorzaken. In elk geval als ik zo een dingen ooit nog zou meemaken, dan zou ik gewoon gelijk opstappen. Maar dat is dus ook een probleem voor sommige ... Die denken hey ik heb nog 5 a 10 jaar tot aan mij pensioen, we gaan hier niet moeilijk doen, ik ga dat hier nog uitzingen. Maar ook hier weer: dat lost het probleem niet op uiteraard

[halfgaar]

Ik vind het jammer dat Zimbra het niet zo nauw meer neemt met communicatie over kwetsbaarheden. Ik heb op 2 oktober deze forumpost gemaakt:

https://forums.zimbra.org/viewtopic.php?t=72975

Met als reden dat Zimbra vaak tekort schiet met publicaties hierover. In het forum post zelf reageren ze dat je de blog en wiki in de gaten moet houden, mogelijk met RSS. Maar, de blog kreeg pas 3 oktober een bericht hiervan, twee dagen nadat mijn server hackpogingen heeft gezien.

Er waren eerdere kwetsbaarheden waarover ik op het forum heb gecommuniceerd die meteen verwijderd werden, omdat het hackers zou helpen. Terwijl je gewoon de .deb file kon uitpakken en duidelijk kon zien wat de hack was.

Ik vraag me trouwens af hoe de onderzoekers die kwetsbare servers hebben geïdentificeerd. De kwetsbare functie staat niet standaard aan.

Je kan de kwetsbaarheid testen door simpelweg een curl commando in de CC te zetten. Dat is ook gebeurd dus op mijn server, vanuit Azië ergens. Ik heb de onderzoekers dit niet zien doen. Lijkt me ook wat onethisch... Dus, als ze alleen versienummers checken, is een beetje opgeblazen wellicht.

Edit: nou, wellicht is de situatie toch anders. Het IP is 45.41.187.134. Dat zit in New York. Ik meen dat het anders was. Nou ja, ze hebben mijn server in ieder geval als kwetsbaar geteld, want ik heb het curl commando dat erin stond op mijn PC uitgevoerd... Het was duidelijk een tracker:

curl crttmntmqnn2vlg148ug1xjxssxox7gcr.oast.live

[Reactie gewijzigd door halfgaar op 8 oktober 2024 11:07]

[sjorsjuhmaniac]

Als ze dan toch kwetsbaar zijn en RCE hebben kunnen de onderzoeker ze ook gewoon updaten ipv er alleen maar over schrijven

quote: bash

$ pkill -9 zimbra; apt update zimbra; zimbra &

[Reactie gewijzigd door sjorsjuhmaniac op 8 oktober 2024 08:14]

[Cybje]

"apt update" dient om de lijst met packages van de apt repositories op te halen. Waarschijnlijk moet je iets doen als "apt update && apt install zimbra" als je specifiek zimbra wilt upgraden. Of "apt update && apt upgrade" als je alles wilt upgraden.

Verder zou ik niet "pkill -9" gebruiken om een proces af te sluiten. Je forceert het afsluiten daarmee en het krijgt niet meer de kans netjes af te sluiten. Wellicht moet het nog dingen wegschrijven, of connecties afbreken. Waarschijnlijk staat zimbra gewoon in systemd en kun je iets als "systemctl stop zimbra" doen.

[CH4OS]

Ja, laat het vooral eerst verdergaan met ongewenste code uitvoeren, wanneer een dergelijk commando via de mail dus gedaan zou worden.

[Reactie gewijzigd door CH4OS op 8 oktober 2024 13:52]

[Dekar]

Zijn dit dan 223 bedrijven waarbij potentieel persoonsgegevens kunnen worden buitgemaakt? Best een flink aantal. Is er iets bekend door welke bedrijven dit wordt gebruikt?

[Reactie gewijzigd door Dekar op 8 oktober 2024 08:41]

[BoerBart]

Nee, dit zijn 223 systemen welke gebruik maken van de Zimbra applicatie. Het aantal bedrijven is niet op te maken uit het aantal systemen (servers). Theoretisch gezien is er een mogelijkheid dat persoonsgegevens buitgemaakt kunnen worden, maar of dit in de praktijk mogelijk is, zal per systeem en/of bedrijf verschillen.

[Reactie gewijzigd door BoerBart op 8 oktober 2024 15:47]

[OruBLMsFrl]

Kunnen ook nog deels losstaande en vergeten test/lab omgevingen zijn hoop je dan maar. Wat Honeypots ertussen, je gaat nooit naar de nul door dat soort redenen.

[jarco5000]

Misschien ook even het vermelden waard dat in België er ook 50 kwetsbare ip's zijn gevonden door dezelfde onderzoekers.