NCSC: ruim 40 procent van Nederlandse Exchange-servers is nog kwetsbaar

Het Nationaal Cyber Security Centrum waarschuwt dat meer dan veertig procent van de Microsoft Exchange-servers in Nederland nog niet geüpdatet is en daarmee kwetsbaar is. Vorige week bleek al dat de kwetsbaarheden ook in Nederland worden misbruikt.

Het NCSC concludeert na eigen onderzoek dat meer dan veertig procent van de Exchange-servers nog kwetsbaar is. Dat betekent dat de vorige week uitgebrachte beveiligingsupdates niet zijn doorgevoerd. Met de kwetsbaarheden kunnen kwaadwillenden op afstand volledige controle krijgen over de servers.

Microsoft maakte begin vorige week bekend dat er in Exchange Server vier zerodays aangetroffen waren, die uitgebuit werden door Chinese hackers om data te stelen van vooral Amerikaanse bedrijven. Microsoft heeft updates uitgebracht die de kwetsbaarheden verhelpen en het NCSC adviseerde direct die te installeren.

Vorige week donderdag meldde het NCSC ook dat de kwetsbaarheden in Nederland actief worden misbruikt. Zaterdag publiceerde de instantie aanvullend advies, waaronder tijdelijke, mitigerende maatregelen. Het NCSC adviseert nogmaals dringend om Microsoft Exchange-servers te voorzien van de benodigde updates.

Volgens securitydeskundigen hebben de zerodays geresulteerd in honderdduizenden infecties wereldwijd. Ook nadat Microsoft op 2 maart patches uitbracht, werden per uur nog 'duizenden bedrijven' getroffen. Het gros van de infecties zou nog niet actief uitgebuit worden, maar kwaadwillenden die toegang hebben verkregen tot de kwetsbare servers, kunnen ook op een later moment het beheer van de servers nog overnemen. Alleen al in de Verenigde Staten zouden op zijn minst dertigduizend organisaties getroffen zijn.

Door Julian Huijbregts

Nieuwsredacteur

08-03-2021 • 15:28

87

Reacties (87)

Sorteer op:

Weergave:

En zoals eerder gemeld, na doorvoeren van de patches ook controleren op ongewenste bestanden die reeds voordien geplaatst zijn. Anders heeft alleen patches weinig zin!

https://www.microsoft.com...rgeting-exchange-servers/

[Reactie gewijzigd door SED op 22 juli 2024 13:25]

Yep, script draaien wat op github vanuit MS staat: https://github.com/microsoft/CSS-Exchange/tree/main/Security

Wanneer je server getroffen is staat er hoogstwaarschijnlijk een webshell in .aspx vorm in de www root van de inetpub, Sophos detecteerde bij 1 van onze klanten de webshell, maar een ander type met de naam Supp0rt.aspx werd weer niet direct opgepakt. Maar wel door Windows Defender.

[Reactie gewijzigd door Pandanl op 22 juli 2024 13:25]

En ééntje genaamd dicover.aspx ( al dan niet met een paar 'leet-letters' )

MS heeft ondertussen al een heel lijstje gepubliceert met mogelijkheden, zie link hierboven ergens
Kan je dan niet beter dat hele ding opnieuw installeren? Als je moet gaan zoeken naar ongewenste bestanden..
Weet niet of je wel eens een Exchange server hebt opgetuigd, maar daar ben je waarschijnlijk langer mee bezig dan die folders te checken.
De vraag is ook of dat de enige plek (of plekken zijn) waar bestanden aangepast zijn. Als er een webshell is opgetuigd kan er van alles mis zijn met het systeem.
Precies, en als de patches ver achterlopen kan je er praktisch vergif op innemen dat het systeem een extra remote beheerder heeft gekregen.
Het hele idee dat je dan niet opnieuw gaat installeren is complete waanzin. Waarschijnlijk gaan veel bedrijven deze zomer met ransomware te maken krijgen...
Wat een onzin. Het feit dat dit niet onwaarschijnlijk door een overheid opgetuigd is, geeft al voldoende zekerheid dat ze geen ransomware erop gaan zetten. Zij hebben er namelijk totaal niks aan als ze servers waar ze toegang tot hebben op slot gooien.

Verder vraag ik me af waar je op baseert dat het tooltje van MS draaien onvoldoende zou zijn om het systeem gepatched te krijgen? Zodra de signature van de webshell bekend is, is opsporen niet een heel groot probleem.
Neen - als een server is geraakt door een kwetsbaarheid kun je de gehele server niet meer vertrouwen.
Als je je IT security serieus neemt bouw je het dan op een verse opnieuw op.

Klote? Ja. Verantwoordelijkheid management die dan het patch beleid een update mag geven.
Een overheid zou het niet zo in de gaten laten lopen, denk ik.
Tenzij het er om gaat om schade te berokkenen.
Nee, heb nog nooit een Exchange server opgetuigd.
Maar met linux vervangen we het hele systeem, als we niet weten wat een aanvaller gedaan zou kunnen hebben. Maar moet toegeven, dat het maar een half tot uur werk is, ongeacht de dienst.
Welke stappen onderneem je bij een Linux mailserver om die volledig terug in te richten op (maar) half uur? 8)7
Hij vergeet voor het gemak even de mail database.
Een nieuwe Exchange Server laat zich ook wel in een half uurtje installeren, alhoewel je waarschijnlijk ook nog wel een half uurtje bezig bent met het opruimen van de restanten van de oude server.
Tegenwoordig is devops een ding. Tools als Terraform, Ansible en containers zorgen ervoor dat het best makkelijk word om alles automatisch te doen. Genoeg voorbeelden en uitleg op het internet met de termen die ik je nu geef, leef je uit. Als je ook maar iets in IT doet is het sterk aan te raden dat je dit leert.

Het lastige hier is garantie geven dat je bestaande data niet besmet is, dat is een ander onderwerp en ga je niet zomaar automatiseren.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 13:25]

Hoezo? Die inrichting heb je toch opgeslagen? Onze infra hebben we ook beschreven als code. Iedere wijziging is dan ook beschreven en als het moet kunnen we de hele rits opnieuw neerzetten. Kost ff wat tijd ja, maar het is vrijwel volledig geautomatiseerd.
Is automatiseren zo moeilijk? Ik zeg in mijn systeem, herinstalleer deze. Vervolgens wordt een server opnieuw geïnstalleerd met de juiste configuratie. Zodat het systeem weet waar die zijn accounts vandaan moet halen en voor de storage.
Ah leuk vergelijken: Dus in de configuratie staat waar die zijn accounts vandaan moet halen. Hoe bedoel je dit precies? Basis config sets aan folders, accounts en wachtwoorden? En waar staat de database cq hoe is de maildatabase gekoppeld?
Misschien is dit concept nieuw voor je https://en.wikipedia.org/wiki/Infrastructure_as_code , maar je gaat toch geen servers meer met de hand installeren en configureren?

En als je de gebruiker account + data op de zelfde server hebt staan, zal je idd een restore vanuit een backup moeten doen. Wat idd wat langer kan duren afhankelijk van de omvang en je netwerk.

Dit allemaal ter zijde, als jij niet 100% zeker kan zijn wat een hacker op je systeem heeft gedaan. Kan je dat systeem, dan nog wel vertrouwen?
Nee je gaat geen servers meer met de hand installeren, maar TB's aan mail storage zet je ook niet zomaar even over. En dan blijft je laatste vraag ook nog staan. Hoe weet jij of je maildatabase die je weer koppelt op je nieuwe Linux systeem nog correct is?
En de mail storage staat niet gewoon op een ander volume dan het operating systeem?
Jawel, maar of het nu lokaal of shared storage is, vanuit het OS zijn het benaderbare bestanden.
In theorie kan een hacker natuurlijk een attachment in een maildatabase verstopt hebben, maar die database is geen executeerbare code voor de mailserver. Herinstalleren van de server software lost in ieder geval het probleem van persistente remote backdoors op de mailserver op.
Ik denk dat het pas vanaf een bepaalde bedrijfsgrote rendabel is om zaken zoals een exchange server als Infrastructure as code in te zetten. Tevens is het ook helemaal geen populaire/bekende manier onder de Microsoft systeembeheerders. Voor een bedrijf die maar een simpele exchange server draait is het niet rendabel om daar automatiseringsscripts voor te bouwen. Dat script bouwen en testen is al sneller duurder dan een server handmatig configureren.

Microsoft zelf doet dit wel heb ik wel eens begrepen in O365. Daar zou een server ongeveer 6 weken bestaan. Eerste 2 weken mailbox migratie, 2 weken in productie, laatste 2 weken mailboxen weg migreren. Maarja, dat is natuurlijk wel enorm grootschalig.
Praktisch gezien heb je twee grotes: Of je bent groot genoeg om je eigen infrastructuur te hebben, en dan is automatisering kostenbesparend, want 'mail server een halve dag offline na iedere zero day' is simpelweg erg duur. Of je bent te klein om het het waard te maken en je laat het door iemand anders beheren. Je eigen infrastructuur als klein bedrijf is gewoon onlogisch en inefficient.
Dat vertrouwen moet je per definitie niet doen, je moet er juist vanuit gaan dat ze al zes maanden in je systemen actief zijn en daar je beveiliging beleid op voeren.
MS Safety Scanner draaien. Deze checked en verwijderd webshells die zijn gevonden.
bron: https://www.bleepingcompu...-exchange-server-attacks/

[Reactie gewijzigd door Verwijderd op 22 juli 2024 13:25]

Ik word hier echt een beetje misselijk van.

Heb alle scripts, scans en checks gedaan die Microsoft heeft gevraagd en geen rariteiten gevonden behalve een poging om Autodiscover te proben (waar ze 200 response op kregen) en een poging naar de url ecp/y.js te gaan met een niet bestaand admin account, waarop ze de response "recipient doesn't exist" kregen en een 401 Unauthorized melding.

Maar goed.. wat zegt dit voor de rest? Op welk punt in de chain is het ze gelukt te infecteren en op welk punt kunnen ze nog afhaken (bijv als ze het admin account misgokken)?

Het zou fijn zijn als er gewoon meer gedetailleerde informatie is naast "dit is hoe je checkt of je geïnfecteerd bent".
Als ik het goed voor heb moeten ze enkel een bestaand mailadres opgeven om de eerste kwetsbaarheid te misbruiken. Administrator@.. Is natuurlijk voor de hand liggend want de standaard admin account noemt administrator. Bij ons in de log hebben ze bijvoorbeeld ook geprobeerd met contact, info, servicedesk, admin etc., maar waren deze pogingen onsuccesvol. Ookal lijkt het alsof ze niet zijn verder geraakt dan enkel wat pogingen, toch is het aangeraden om te gaan zoeken naar wijzigen of web shells. Een goede hacker zal natuurlijk de logs aanpassen.

Nadat microsoft dit heeft bekendgemaakt komen andere hacker hier ook op af en passen de werkwijze natuurlijk wat aan.
Hoe zie je de account gebruikt bij ecp/y.js? In mijn logging is AuthenticatedUser leeg, en IsAuthenticated = FALSE.
edit:
Aha, request gevonden in de Autodiscover log.

[Reactie gewijzigd door Ultra op 22 juli 2024 13:25]

wij hebben gelukkig binnen 24 na release van de patch 80+ exchange servers weten bij te werken + full scan. Maar niet die-hard IT mensen realiseren zich niet of nauwelijks hoe gevaarlijk dit lek is. Dus ik snap dat er nog zoveel ongepatchte systemen zijn.
Moet je daar "die hard IT" voor zijn om dat te beseffen?
het is zeer breed uitgemeten in het nieuws. Ik heb meerdere systeembeheerders gesproken die zeiden: "oh, niet meegekregen, is dit een probleem dan?" En dan later vreemd opkijken als al je shares encrypted zijn en er een blaadje op de printer ligt of je 3 bitcoin wil sturen.
Tja, dan is de vraag of ze daar wel op hun plaats zitten ....
Vergeet even niet dat niet elke systeembeheerder een Exchange beheerder is. In veel organisaties is Exchange beheer een hele andere tak van sport, waar anderen zo ver mogelijk vandaan willen blijven en dus niet inhoudelijk gaan kijken naar Exchange.
goede reden om een migratie naar M365 te starten en die exchange server met pensioen te sturen.
Als je hem toch niet kan beheren, dan maar de deur uit, of onderbrengen bij een partij die wel actief beheer doet op je server(s) zoals @pleh
Kosten ...goedkoop is idd duurkoop en dat beseffen veel bedrijfjes nog niet tot het te laat is ...
Ik kreeg ooit een belachelijk aanbod qua loon en wagen naar keuze tot bleek dat ik een ing moest vervangen omdat ik meer 'hands-on' was.
Ik zou wel 7 op 7 beschikbaar moeten zijn als ENIGE support (+-700 apothekers/artsen) moeten leveren.

De logica : een hoog loon voor 1 werknemer is nog steeds goedkoper dan 2 werknemers 8)7 :(

[Reactie gewijzigd door OxWax op 22 juli 2024 13:25]

Wat heb je toen gezegd? Denk je dat ze hun beleid aangepast hebben?
Thanx but no thanx ...zelfstandig werken is één ding, helemaal alleen ...
goede reden om een migratie naar M365 te starten en die exchange server met pensioen te sturen.
Als je hem toch niet kan beheren, dan maar de deur uit, of onderbrengen bij een partij die wel actief beheer doet op je server(s) zoals @pleh
Dat klinkt heel goed op papier, maar in praktijk niet. Ook met het hele "alles in de cloud" verhaal blijf je zelf mensen nodig hebben die doorzien hoe systemen samenwerken in. Zo'n M365 kan heel veel maar er kan ook heel erg veel mis gaan. In mijn ervaring snappen gewone gebruikersk niet genoeg van dit soort systemen om verstandige beslissingen te nemen over zaken als toegangsrechten en API's.
Nu denkt iedereen altijd dat je daar niks mee te maken hebt als je 'alles uitbesteedt naar de cloud' maar niemand in deze wereld kan doe met 1 softwarepakket. Iedereen gebruikt meerdere pakketten van verschillene leveranciers en die moeten al snel aan elkaar gekoppelt worden.

Daar gaat het helemaal fout zonder gespecialiseerd personeel dat zowel de software als je eigen omgeving kent. Geen enkele externe consultant kan iets zinnigs zeggen over hoe applicaties moeten samenwerken met jouw data. Als daar in het algemeen iets over te zeggen was dan was het niet configureerbaar. Je eigen personeel weet het ook niet (dat was de stelling) dus dan wordt er altijd gekozen voor "het moet wel werken he, de beveiliging komt later wel".

Binnen de kortste keren heb je een onwerkbare hel vol ondoordachte keuzes waardoor veiligheid onmogelijk wordt.

Er zijn prima redenen om een deel van je infrastructuur extern te laten beheren maar je moet het niet als bezuiniging doen, zeker niet op de korte termijn. Als je geen personeel kan betalen om je huidige omgeving te beheren dan moet je niet denken dat je er veel op vooruitgaat door het buiten de deur te zetten. (Note: ik zeg niet dat je nooit geld kan besparen met zo'n verandering of dat het altijd slechter wordt, maar er toverstokken bestaan niet. Met het juiste personeel kan het best werken. Maar doe het niet omdat je de illusie hebt dat je dan zonder gespecialiseerd personeel toe kan. Mensen met de juiste kennis zijn alleen maar moeilijker te vinden en duurder).
En om dan vervolgens hun manager de schuld te geven terwijl de sysadmins de specialisten horen te zijn....
tja dat doet deze hacker groep dan weer niet,

maar nu de exploit op straat ligt kun je wachte tot er komende weken andere groupen deze exploit ook gaan gebruiken.
Als je 80 Exchange servers beheerd, heb je al overwogen om ze niet direct naar het internet te laten connecten? Mail relais, proxy oplossingen, loadbalancers, mail sanity zoals ironport, fireeye etc. en Mobile iron lijken me voor de hand liggende zaken voor zo'n flinke omgeving?
Volgens mij zegt ie nergens dat ze alle 80 vanaf internet benaderbaar zijn.
Maar nadat je de externe OWA servers gepatched hebt, wil je ook je interne servers wel patchen. Die zijn minder makkelijk te benaderen, maar je moet ook met een interne dreiging rekening houden.
Zijn allemaal individuele klanten. Meeste is inderdaad legacy en zal wel een keer naar o365 worden omgezet. Maar klanten investeren doorgaans in een concept voor 5 jaar en dan wordt het hetzien. Is redelijk kapitaal vernietigen als je net een nieuwe infra gekocht hebt en de handel dan weer vervangt.
Verwijderd @pleh8 maart 2021 16:19
80+ servers met exchange?
Zeker voor 80+ verschillende bedrijven die dat als dienst afnemen, want ik ken geen bedrijf wat 80+ mailservers nodig heeft 😱
Klopt. Veel verschillende klanten met eigen mailserver.
Verwijderd @pleh8 maart 2021 16:24
Vraag ik me wel af waarom die exchange willen, maar goed, dat zal wel zijn omdat geld geen rol speelt en het zo lekker bekend klinkt ;) Keuzes... O-)
Van Exchange weet je gewoon dat je X betaald en dat die shit voorspel baar werkt. Bij alternatieven moet je dat maar afwachten
Van Exchange weet je gewoon dat je X betaald en dat die shit voorspel baar werkt. Bij alternatieven moet je dat maar afwachten
En hoe is je mening NU daarover ?

Want zo voorspelbaar was het allemaal niet kennelijk
Een actief lek, een paar zero-days, die niet helemaal "zero" meer waren, een NCSC wat een dag NAdat MS zijn patchtuesday als "high profile" weggezet heeft, terwijl MS in het verleden wel vaker de bal gemist heeft met hun updates en patches ( als in meer problemen door zo'n update )

Met zo'n trackrecord begrijp ik sommige systeembeheerders wel .... in 9 van de 10 keer hebben ze gelijk door te wachten.
Maar dat dit die éne keer was dat het niet handig is .....
want ik ken geen bedrijf wat 80+ mailservers nodig heeft 😱
Ik wel, maar die stonden wel wereldwijd verspreid met 250.000 mailboxen er op. (voordat ze naar O365 verhuisden)

In Nederland hadden we er 12. Maar als je alles dubbel uitvoert dan kom je er vrij snel aan bij een enterprise omgeving. 2 stuks voor OWA, 2 stuks voor je smtp gateway, wat mailbox clusters.
uiteindelijk is dat ijzer ook niet de kosten.
250.000 mailboxen....

Ik draaide er 4.000.000 op 10 linux bakken. ;)
Dat zegt natuurlijk geen zier. Hoeveel mails komen er per dag binnen, hoe groot zijn die mails, hoe zwaar gebruiken de mensen die mailboxen. Hoe groot zijn de mailboxen. Zijn ze bv gemiddeld 100GB?
De meeste bedrijven hebben geen ongelimiteerde grootte voor de mailboxen.
In plaats van 4 mailbox clusters hadden we er eentje kunnen doen. Leuk om stoer te doen tegen mensen die niet beter weten, maar verder alleen maar onhandiger en duurder.
Hadden we mailboxen met minder functionaliteit, zoals gebruikelijk op Linux, dan was de afweging wellicht anders geweest.
Gemiddeld 100G per mailbox? Wellicht moet je dan gebruikers gaan opvoeden.
Mail is tekst, tuurlijk, tegenwoordig met alle bijlagen is het meer, maar daar zijn nu ook weer betere oplossingen voor dan vroeger.
En opruimen is ook een kunst blijk wel weer.

Mailboxen met minder functionaliteit? Mail er in, mail er uit. Hoeveel functionaliteit wil je hebben... ;)
Precies de reactie die ik verwachtte :)
Ik kan je er verschillende opnoemen die ook nog eens opereren vanuit de NL.
Zelfde hier, downtime was op woensdag gedurende de lunchperiode dus weinig medewerkers hebben het gemerkt.

In het weekend nog de scripts uitgevoerd maar gelukkig is het lek bij ons niet misbruikt. _/-\o_
Of de geïnstalleerde webshell heeft z'n sporen goed uitgewist ;)
Waarom downtime? Juist Exchange kun je heel makkelijk redundant uitvoeren.
Of is de omgeving daar te klein voor?
Slechts 40 mailboxen, inderdaad te klein daarvoor.
Mogelijk omdat beheerder van dat soort klein zakelijk spul vaak door mensen wordt gedaan die het er een beetje bij doen?
Dat deel zal dus nog open staan...
Of de handige zoon "die zoveel van computers snapt".


Klein zakelijk kan beter cloud diensten afnemen als je het mij vraagt ;)
Klein zakelijk kan beter cloud diensten afnemen als je het mij vraagt ;)
Heel eerlijk gezegd, in NL hebben we cloud van Microsoft (Exchange Online), maar de performance is gewoon slechter dan gewend met de onsite Exchange server. Voor een beetje internet en email hoef je geen snelle (lage latency etc.) internet verbinding te hebben, maar voor de cloud diensten dus weer wel...
Edit: Misschien misbruiken we Outlook dan ook wel, maar we zitten ruim onder de limieten die MS zelf aangeeft.

Groot voordeel is het "gebrek" aan beheer, we hoeven zelf niet meer na te denken en alleen de updates op de laptops te doen.

[Reactie gewijzigd door wjn op 22 juli 2024 13:25]

wat doe jij dan dat het niet werkt, ?

Ik heb zelf een 30+ GB mailbox in office 365 maar ik heb geen enkele issues met performance, kan ook bijna niet gezien alles lokaal in je ost staat dus zolang je die maar op een SSD hebt staan. maar daar gaat een lokale server ook niet bij helpen.

Heb je soms grote mailboxen zonder local cache , maar dat is dan ook niet de best practise. dus iets klopt er niet bij je.

Wat bedoelje precies met outlook misbruiken wat dat klinkt idd als iets wat issues kan veroorzaken.
Bekend probleem inderdaad. Performance is slechter. FSLogix helpt dan wel weer.
Ik twijfel of je performance slechter is ,

Denk dat je bedoelt dat je netwerk latency hoger is. aangezien je aangeeft flogix te gebruiken heb jij het ook niet over normaal gebruik maar heb je het over terminal servers neem ik aan. Maar dat is al lang niet meer een best practise als we het hebben over cloud.
Ik bedoel inderdaad RDS en Citrix SBC servers. Dat lijkt me toch niet achterhaald.
meeste bedrijven die ik ken stappen daar al jaren geleden weer van af omdat het niet bij moderne cloud past tenzij het domme terminals zijn net als bijvoorbeeld een kassa.

Voor clients geld dat het mobiel moet zijn dus vaak een eigen keuze laptop als je een beetje modern bedrijf hebt of zelfs bring your own. en dan passen citrix servers toch echt niet meer, daarnaast zijn ze minder secure dan een physiek apparaat bij de eind gebruiker.
Inderdaad, als je niet de kennis en beschikbaarheid om binnen 24 tot 48 uur te patchen moet je niet zelf aan Exchange beginnen, dan moet je lekker Office365 afnemen.
Gaat vaak niet om daadwerkelijk kennis en beschikbaarheid maar dat de bedrijven in kwestie een situatie waar wel elke 24 tot 48 uur patches gedraaid wordt te duur of om andere redenen als nadelig beschouwt (liever op een vast moment v/d week midden in de nacht, maar wel tegen bodemtrarief alsjeblieft en ondanks het niet vaker dan dat éne vaste moment in de week/maand, géén lekken).
Vooraf al aannemen dat iets wel of niet aan de hand zou zijn om daar vervolgens ook nog even gemakkelijk een mening op te baseren over een groep lijkt me niet gepast.
Of het verstandig is om een eigen mailserver te laten onderhouden hangt volledig van de omstandigheden af. Wat net zo goed op gaat voor alle bedrijveb. Dus zolang niet duidelijk is wat hier de keuzes zijn en om welke bedrijven of andere organisaties het gaat is dit wel erg makkelijk om iets over anderen te vinden. Daarbij is een clouddienst ook niet perse beter of een goede oplossing voor de mogelijke omstandigheden.
Hoe heeft NCSC dat onderzoek uitgevoerd? Dat staat n.l. niet op hun site. Zaterdag heb ik onze Exchange server gepatcht. Voor diegenen die zeggen: waarom pas zaterdag? Welnu, in het eerste bericht van MS was het lek nog niet zo ernstig. Patchen halfweg de week wil nog wel eens voor nare verrassingen zorgen, dus dat doe ik liever in het weekend.

Na installatie van de patch de check-script gedraaid en jawel, voor CVE-2021-26855 doken twee regels op. Net een uur voordat ik de patch installeerde. Anchor mailbox: burpcollaborator.net. "Burp Collaborator is a service that is used by Burp Suite when testing web applications for security vulnerabilities.". Nu is de vraag: heeft het NCSC gebruik gemaakt van de Burp suite of de hackers?
Verder heb ik geen webshells of andere narigheid gevonden, maar ik ben er nog lang niet gerust op dat we niet gehackt zijn. Ik heb inmiddels de Fileserver Resource Manager ingeschakeld om het maken / wijzigen van een aantal bestandstypes in de gaten te houden en een ICT security bedrijf gevraagd de boel bij ons door te lichten.

Wat in het verhaal van Microsoft ontbreekt is wat te doen als je gehackt bent. Her en der wordt gezegd dat gebruikers hun wachtwoord moeten wijzigen en dat je je Exchange server opnieuw moet installeren. Maar daarmee is naar mijn idee het probleem nog lang niet opgelost. De hackers kunnen zich admin-permissies toebedelen en hebben daarmee het hele netwerk in handen. Wachtwoorden wijzigen heeft dan geen zin - als admin kan ik immers overal bij. Idem voor het opnieuw opzetten van de Exchange server. Als hacker heb ik immers toegang tot ALLES wat Windows draait. Ofwel, om zeker te zijn van een schoon systeem, zou je ALLES opnieuw moeten installeren. Niet alleen de servers, maar alles wat Windows draait. En dan komt het leukste - het overnemen van de data van het oude systeem. Hoe ga je dat doen? Ja, een backup terugzetten. En weet je zeker dat die vrij van narigheid is? Nee, want het lek is al oud, dus wie weet hoelang het al wordt misbruikt.

Zucht.
Er op 2 maart meerdere lekken door Microsoft bekend gemaakt. Een daarvan had toen al een CVSS score van 9.1 op een schaal van 10 wat betreft ernst. Ik ben dan wel benieuwd wat er dan voor zorgt om dat dan nog niet als ernstig genoeg te beschouwen en wat er dan nodig was om wel te gaan patchen.
Als ik de patch niet heb gedraaid als administrator. Kan ik hem dan gewoon opnieuw draaien?
Ja, ik voer de patches altijd uit vanuit een powershell prompt welke ik als admin draai.
Exchange wilt vaak niet (Goed) meer functioneren als je de patches niet als admin uitvoert.
Ik dacht misschien sloop ik iets als ik twee keer dezelfde patch uitvoer. Ik weet namelijk niet zeker voor 1 machine of ik wel of niet vanuit als administrator uitgevoerd CMD prompt de patch had gestart of niet.
Ik heb diezelfde avond de hotfixes doorgevoerd, en ook de tool van Microsoft even laten draaien. Bij ons gelukkig geen "infections" gevonden maar we blijven het preventief monitoren.

Dat 40 procent nog niet gepatcht is zal voor die partijen, gezien de aard van de bugs, het nu al wel te laat zijn. Laat staan hoeveel van die 40% momenteel op de hoogte zijn van deze problemen.
Klopt.
Ik heb zaterdag de server uit gezet, zondag toegang tot internet geblokkeerd van/naar die server en de updates uitgevoerd.
Er waren al 2 bestanden geïnfecteerd, terug te leiden naar deze exploits, op 3 & 4 maart.
Deze Exchange 2016 Server staat in PL.
idem hier, donderdagochtend is die van ons geïnfecteerd, vlak voordat we donderdag de update geplanned hadden. Ik kreeg door dat het serieus was en dus overlegd of we hem niet even overdag konden rebooten ipv standaard in het weekend. Was dus al te laat. Gelukkig was er nog geen schade toegebracht.

[Reactie gewijzigd door Magic op 22 juli 2024 13:25]

Moet je serieus dat overleggen bij zo'n CVE? Ik heb dat ding gewoon gereboot, security first. Overigens hoef je na de patch van MS niet te rebooten?
Nou, ik bedoel eigenlijk overleg in de context van "mededelen" :)

En rebooten is idd niet perse nodig, maar na microsoft updates is het vaak wel verstandig is mijn ervaring.

[Reactie gewijzigd door Magic op 22 juli 2024 13:25]

Haha, zo ken ik de echte beheerders ;-)
Nou 't vreemde was dat ik dacht gelezen te hebben dat een reboot niet nodig was terwijl na de installatie er toch een verzoek kwam te rebooten.... ;(
Het gaat over Windows Server 2016, dat is een editie. Wilt niet zeggen dat de beste Tweaker nog nooit geen update heeft uitgevoerd.
Grappenmaker :+

WSUS draait en ik check wekelijks en zeker elke patch Tuesday.

Het is inderdaad Microsoft Exchange Server 2016 (CU19), met "de updates" is de 0-day update bedoeld (meervoud omdat het meerdere CVE's dicht).

Op dit item kan niet meer gereageerd worden.