Microsoft waarschuwt bedrijven dat Netlogon-kwetsbaarheid actief wordt uitgebuit

Microsoft roept bedrijven wereldwijd op een kwetsbaarheid in Netlogon op Windows Server te repareren. Volgens het bedrijf wordt die kwetsbaarheid actief aangevallen, ondanks de patch die al sinds augustus uit is.

Het gaat om een kwetsbaarheid in het Netlogon-protocol, waarmee gebruikers op een domein worden geauthenticeerd. Het protocol draait op Windows Server. In augustus bracht Microsoft een patch uit voor een kwetsbaarheid in dat protocol. Met dat lek, met code CVE-2020-1472, kon een aanvaller een domain controller-account spoofen en zo inloggegevens stelen en het domein overnemen. De kwetsbaarheid zat in Windows Server 2008 R2, 2012, 2012 R2, 2016 en 2019. De patch zat in KB4557222. Destijds waarschuwde ook al het Nederlandse Digital Trust Center voor de kwetsbaarheid.

Microsoft waarschuwt nu opnieuw voor de exploit. Dit keer is de waarschuwing serieuzer, want het bedrijf zegt dat de kwetsbaarheid actief misbruikt wordt. Het gaat om 'een klein aantal meldingen' van gebruikers. "We raden iedereen die de update nog niet heeft doorgevoerd ten strengste aan dat nu te doen", zegt Microsoft. Het is niet bekend hoeveel slachtoffers last hebben van de aanvallen en wat voor type bedrijven dat zijn.

Microsoft is niet de enige partij die momenteel waarschuwt voor de uitbuiting. Die komt ook van het CISA, het Amerikaanse Cybersecurity and Infrastructure Security Agency. "Totdat iedere domain controller is bijgewerkt, is de hele infrastructuur kwetsbaar", schrijft de overheidsinstantie. De instelling heeft een script vrijgegeven waarmee systeembeheerders kunnen kijken of er onbeschermde systemen op hun netwerk zitten.

Reacties (68)

[ASS-Ware]

Vergeten we niet een registry entry?
De patch van augustus zorgt alleen voor het eventloggen van het misbruik.
Je moet nog een registry key plaatsen om het oneigenlijke gebruik te blokkeren.
Pas vanaf de update van komende januari is het oneigenlijke gebruik echt geblokkeerd.

[SmokingCrop]

Inderdaad, zie:
https://support.microsoft...channel-connections-assoc (staat gelinked in artikel, maar niet heel duidelijk dat het op "de patch" staat)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value: FullSecureChannelProtection
Type: REG_DWORD
Data: 1

[Reactie gewijzigd door SmokingCrop op 24 juli 2024 20:57]

[MrFax]

Dit is logisch, omdat zodra je het enforced met deze key, alle clients die vulnerable connections maken niet meer werken. De update is om te monitoren welke clients vulnerable connections maken, en deze zo te kunnen patchen, waarna je deze key registreert. Dit zo om ongewenste problemen te voorkomen.

[Reactie gewijzigd door MrFax op 24 juli 2024 20:57]

[themadone]

Ben ik de enige die dit graag andersom zou zien? Bij dit soort patches heb ik liever collateral damage van een paar antieke systemen die het niet meer doen als een mega vulnerability.

Dit doet Microsoft vaker zo, niet iedereen heeft oude meuk.

[raptorix]

Wellicht omdat bedrijven soms nog gedwongen zijn om legacy systemen te ondersteunen, als MS blind een feature dicht zet kan dit weer allerlei problemen geven, en zeker met Remote Desktop is dat vervelend omdat je je dan zelf kunt buitensluiten.

[themadone]

Ik bedoelde meer, zet een disclaimer bij de update, en activeer de functie voor de 85% die er geen last van hebben direct na update installatie.

Bij de gemiddelde MKB onderneming doen ze trouw hun windows updates, maar hebben ze geen team om ook alle release notes te gaan lezen waar dan heel diep in verstopt staat dat je de register key zelf moet doen.

Laat de ondernemingen met oude meuk zelf het risico bepalen, en de kleine ondernemers die zich suf patchen gewoon veilig zijn.

[Verwijderd]

Alleen de bedrijven die 'legacy' systemen gebruiken zijn vaak degenen die een hele schok door het distributie systeem laten gaan als ze stil komen te liggen door het afdwingen van het afbreken van de connectie.

Het is veel makkelijker zelf even een aanvullend script te schrijven om de benodigde registry key toe te voegen voor de juiste groepen, dan een aanvullend script te schrijven om de registry key te verwijderen uit een update voor de juiste groepen.

[Tozz]

Eens. Ik kan me ook voorstellen dat iemand denkt "Oh, de KB is geinstalleerd. We zijn veilig", terwijl je dan in werkelijkheid alleen logging hebt.

Het zou 'secure by default' moeten zijn.

[RoytjeP]

Dit dus. Erg belangrijk.

[Robthebest]

Volgens: https://www.catalog.updat...m/Search.aspx?q=KB4571694

is de update vervangen door de onderstaande:

2020-09 Cumulatieve update voor op Windows Server 2016 for x64 gebaseerde systemen (KB4577015)
2020-10 Cumulatieve update voor op Windows Server 2016 for x64 gebaseerde systemen (KB4580346)

[Mopperman]

Vergeet niet dat de patch uit augustus pas de 1 is. Daarbij zat deze in de monthly rollout van augustus, maar, deze is al superseded bij september en oktober.

Overigens: voor 2012r2 2008r2 zal je de ESU nodig hebben....

[Reactie gewijzigd door Mopperman op 24 juli 2024 20:57]

[Dennism]

Bedoel je niet 2008R2? 2012R2 is nog gewoon in support tot oktober 2023 ( https://support.microsoft...er%202012%20R2%20Standard )

Voor 2008R2 kan je wel ESU afnemen ( https://support.microsoft...er%202008%20R2%20Standard ).

Hier een overzicht van alle producten waarvoor een ESU programma loopt:

https://docs.microsoft.co...extended-security-updates

[Reactie gewijzigd door Dennism op 24 juli 2024 20:57]

[Mopperman]

Excuus - je hebt gelijk, foutje van mijn kant - heb m aangepast.

[sprankel]

2012R2 & 2012 zit in extended support wat wil zeggen dat security updates gratis zijn tot 10 oktober 2023. Daarna zul je extended security updates nodig hebben (ESU) als je op 2012R2 verder wilt gaan.

In extended support krijg je geen feature updates meer maar dit valt onder security update. Voor deze heb je dus enkel voor de 2008 ESU nodig gezien die buiten extended support is sinds 14/01/2020

[The Zep Man]

Overigens: voor 2012r2 zal je de ESU nodig hebben....

Extended support houdt simpelweg in dat enkel nog kritieke en beveiligingsupdates worden worden uitgebracht. Tot 2023 is dat dus gratis voor 2012 R2.

[PluueeR]

Hmmm, de cumulatieve updates zijn hier geïnstalleerd ik zie alleen de genoemde events niet naar boven komen. Terwijl ik weet dat er nog legacy clients zijn.

[B38A12A]

En we kunnen weer aan het werk op de vrijdagmiddag...

[Tweaker_19]

ondanks de patch die al sinds augustus uit is

Dus eigen schuld aan degene die dit nu op vrijdagmiddag abrupt moeten doen...

[kodak]

Niet helemaal. Natuurlijk is het de eigen keuze om dat op basis van bepaald informatie te willen doen. Maar je mag ook van de brenger van de informatie verwachten dat die dat niet zomaar vlak voor een weekend doet. Nu heb ik er wel vertrouwen in dat een bedrijf als Microsoft daar rekening mee weet te houden, maar dan nog mag je wel kritisch zijn over de timing als je klant bent.

[wildhagen]

Microsoft waarschuwde al in augustus, bij de release dus, voor de zeer hoge risico's van dit lek. Ook in september hebben ze nogmaals een waarschuwing verstuurd.

Het is niet alsof dit hun eerste waarschuwing is.... dit is al hun derde.

[kodak]

Dat klopt en mag zeker wel bekend zijn. Maar het is niet alsof iemand dan bij het geven van waarschuwing geen rekening meer hoeft te houden met het tijdstip. Net zo min een ontvanger er zich vanaf kan maken dat het een eigen keuze is om er nu wel iets mee te doen.

[Djerro123]

Wat een onzin, sorry dat ik het zo bot zeg. Als ze op vrijdagochtend concluderen dat het actief misbruikt wordt, moeten ze dan wachten tot maandag ochtend voor een statement? Überhaupt, wat maakt het uit wanneer zij een waarschuwing geven als je toch van mening bent dat "weekend" er hier toe doet: dan kan je zelf het toch ook naast je neerleggen tot maandag? Of denk je dat de dreiging niet bestaat wanneer MSFT dit pas op een maandag zou melden? Ik snap echt niet hoe je erbij komt dat uitgerekend timing een belangrijk iets vind bij security waarschuwingen, anders dan "zo snel mogelijk".

[kodak]

Ik beweer op geen enkele manier dat iemand geen goed zou mogen doen als dat nodig lijkt of dat een ontvanger zelf geen verantwoordelijkheid zou hebben om beslissingen te nemen. Wat ik stel is dat je als bedrijf net zo goed mag verwachten dat de ontvanger (zeker als het je klant is) ook andere belangen heeft en je daar dus beter ook rekening mee kan houden. Dat de meningen kunnen verschillen over wat een geschikt moment is, is in een relatie tussen dienstverleners en klanten niet perse minder belangrijk. Daarbij vraag ik me af wat er zo goed zou zijn als een bedrijf zich als weldoener naar voren schuift door alleen te kijken naar wat de weldoener voor belangen wenst te zien. Goed doen is namelijk zelden een kwestie van egoïstisch doen in een relatie. Zoals ik al aan gaf vertrouw ik er bij Microsoft wel op dat ze rekening houden met andere belangen van hun klanten, maar dat wil nog niet zeggen dat je daar dus niet kritisch over hoeft te zijn. Het lijkt me juist goed als Microsoft kan uitleggen waarom ze er voor kiezen om het op dat moment naar buiten te brengen en bijvoorbeeld niet eerder, in plaats van te gaan raden wanneer Microsoft iets zou hebben geweten. Dat zorgt er namelijk hopelijk ook voor dat de ontvangers die klagen over het tijdstip eerst bedenken of dat klagen wel zo terecht is en dat dan kunnen onderbouwen.

[Reactie gewijzigd door kodak op 24 juli 2024 20:57]

[vtsalf]

Microsoft waarschuwt niet pas sinds vandaag voor dit lek, maar als sinds Augustus toen zij er een patch voor uitbrachten.

Toen is al door Microsoft duidelijk gemaakt dat dit een serieus lek is en dat men dit moet gaan patchen.

Microsoft ziet sinds gisteren (want een bulletin uitbrengen duurt ook een aantal uur) dat er mensen zijn die dit lek actief misbruiken. Ze sturen dus NOGmaals een waarschuwing de wereld in over dit lek en dat er nu toch wel eens gepatchet moet worden.

Dit lek is ernstig genoeg om hier op vrijdag over te waarschuwen in geval van misbruik. Dus doet Microsoft dit. Het is aan de IT club van dienst (managed services club of eigen interne IT) om te bepalen of dit lek voor hun omgeving wel of niet ernstig genoeg is. En dus zullen er vanavond/vannacht/dit weekend genoeg sysadmins zijn die patchen. En ook genoeg die het niet doen.

Maar ik zou er vandaag juist extra blij mee zijn dat MS opnieuw waarschuwt, want ze zien actief misbruik.

[Reactie gewijzigd door vtsalf op 24 juli 2024 20:57]

[kodak]

Microsoft ziet sinds gisteren (want een bulletin uitbrengen duurt ook een aantal uur) dat er mensen zijn die dit lek actief misbruiken

Het kost natuurlijk tijd om te beslissen om te waarschuwen, maar heb je meer onderbouwing? Want Microsoft laat daar namelijk niets over los en laten op geen enkele manier blijken wel of geen rekening te houden met andere belangen. Mijn punt is dat zomaar iets doen of ergens vanuit gaan net zo goed niet gepast is voor iemand die goed wil doen als voor iemand die er mee te maken krijgt.
Maar laten we even van het positieve uit gaan, dan hoor ik nog steeds geen argument om geen onderbouwing te geven voor het moment of hoe er belangen zijn afgewogen. De argumenten lijken ook hier weer bedoeld om te verdraaien dat iemand die goed wil doen alleen maar goed bezig zou zijn en dat iemand die nog niets gedaan heeft niet moet zeuren. Maar zo werkt beveiliging en risico beheersen niet. Dat doe je op basis van goed kunnen afwegen hoe belangrijk een bericht is en hoe dat mee telt om een beslissing te nemen. Natuurlijk mag een ontvanger dan heel blij zijn dat microsoft ze (voor de zoveelste keer) nog wil waarschuwen. Maar dat geeft nog steeds geen excuus dat iemand die goed wil doen zelf geen verantwoording af hoeft te leggen over de mogelijke gevolgen. In een samenleving is het niet de gewoonte dat je zelfstandig maar voor anderen gaat bepalen wat goed is. Als het ernstig genoeg is zou Microsoft namelijk net zo goed dus kunnen aangeven wat hun afwegingen nog meer zijn geweest. Doen ze niet. Als Microsoft het belangrijk zou vinden dat bedrijven gaan patchen dan doe je dat juist ook op een moment dat je verwacht dat het verschil gaat uitmaken. Dan kunnen ze dus ook net zo goed aangeven hoe ze denken dat dit dan het beste moment zou zijn. Eigenlijk lijken er helemaal geen excuses genoemd te worden waarom Microsoft zo vaag zou zijn waarom ze dit moment uit kiezen terwijl ze weten dat er bij bedrijven ook afwegingen gemaakt worden op tijd en geld om in actie te komen. Dan zou je juist verwachten dat Microsoft er heel duidelijk over kan en wil zijn.

[vtsalf]

Het argument of onderbouwing is al in het CVE artikel genoemd: https://portal.msrc.micro...ce/advisory/CVE-2020-1472

Ik kan je, net als Microsoft, niet anders zeggen dan dat dit een _ernstig_ (netlogon service) lek is, er al sinds augustus voor wordt gewaarschuwd (dat er een patch werd uitgebracht) en dat MS ziet dat het NU actief misbruikt wordt.

Je kunt heel wollige taal gebruiken in je replies, maar soms is het gewoon; patch NU, want als je server met AD aan het internet hangt, of wanneer er een stuk malware via de mail binnen komt en van binnenuit wordt misbruikt, dan ben je de Sjaak.


Nee, MS bracht dit niet pas sinds vandaag naar buiten. Al veel eerder. Het wordt nu actief misbruikt, DOE er iets aan


Wat kan jou die arme sysadmins nou schelen? Worden ze toch voor betaald? En goed ook als het goed is (ja ja, ben zelf ook de lul geweest vroeger in de avond/nacht/weekend). Maar als je enigszins serieus met je werk bezig bent, dan is deze update al heel lang door SCCM of WSUS uitgerold.

Wat ik wil zeggen is dat deze vrijdag dus geheel niet als verrassing zou moeten komen voor sysadmins.

[kodak]

Ik krijg de indruk dat je je niet zo bezig wil houden dat patchen een afweging is met de argumenten die je geeft. Wij of Microsoft kan wel vinden dat iemand maar beter kan patchen maar de situatie is dat dit soort berichten er juist voor zou moeten zorgen dat iemand die het nog niet gedaan heeft gaat patchen. En dan ga je dus niet alleen maar roepen wanneer het je uit komt of dat er al eerder waarschuwingen zijn gegeven en iemand die nog moet patchen dan maar niet moet zeuren. Dat helpt op geen enkele manier om iemand te overtuigen en helpt ook niet om de relatie tussen iemand die iets belangrijks te melden heeft en iemand die moet beslissen om te patchen goed te houden voor de volgende keer.
Argumenten als wat kan jou of mij het nu schelen zijn daarbij van laag niveau als je omgekeerd dat maar negeert om iets over anderen te vinden. Het is tenslotte ook jou of mijn beveiliging niet. Of het een verrassing is doet er niet zoveel toe, wel of er een goede afweging gemaakt kan worden en daarbij is zomaar informeren gewoon niet altijd genoeg, ook al zouden anderen dat nog zo graag willen. Ik denk dat het daarmee ook het einde van deze discussie is.

[vtsalf]

Ik zal je de laatste reactie geven, want je wil niets van me aannemen.

Ik krijg de indruk dat je je niet zo bezig wil houden dat patchen een afweging is met de argumenten die je geeft. Wij of Microsoft kan wel vinden dat iemand maar beter kan patchen maar de situatie is dat dit soort berichten er juist voor zou moeten zorgen dat iemand die het nog niet gedaan heeft gaat patchen

Ik zal het proberen via een analogie.
Stel je hebt een voordeur met een Yale slot. Yale waarschuwt je in augustus dat ze een fout hebben ontdekt in hun produkt waarmee, theoretisch, iedereen met een nepsleutel jouw voordeur kan openen. Yale geeft het advies om een update door te voeren waardoor jouw slot niet zonder meer door iedereen te openen is.

Yale ziet vandaag, gisteren, eergisteren, dat er inbrekers zijn met die nepsleutel. Vind jij het dan daadwerkelijk erg als Yale in _Oktober_ zou herinneren dat mensen de update moeten doorvoeren?

Ik heb het idee dat je ons IT-ers iets wil uitleggen dat wij zelf niet zien en jij wel. Fair enough, maar je huidige argumenten geven geen verhouding tegen de argumenten om een patch door te voeren.

C’est ca, maar ik denk dat je door de meerderheid hier die sysadmin zijn niet serieus wordt genomen.

[Reactie gewijzigd door vtsalf op 24 juli 2024 20:57]

[kodak]

@vtsalf het is niet dat ik niets van je wil aannemen als we het oneens zijn. Ik vind alleen je argumenten niet sterk in de discussie dat patchen ook neer komt op rekening houden met andere belangen als je wil zorgen dat anderen gaan patchen. Je reactie laat helaas (weer) weg dat iemand die een afweging maakt om wel of niet te patchen dat waarschijnlijk op meer doet dan alleen wanneer er voor het eerst gewaarschuwd is of hoe vaak er al gewaarschuwd is. Er tellen vaak veel meer afwegingen mee. Dat jij of ik het erg genoeg vonden om al te patchen is het probleem niet als je een ander wil overtuigen. Het probleem is onder andere dat anderen die overgehaald 'moet' worden zich kennelijk ook geroepen voelen om het moment aan te grijpen om wel of niet iets te doen. Microsoft waarschuwt niet omdat ze niemand meer hoeven over te halen, dus als ze dat willen doen kunnen ze naar mijn mening dus maar beter meer laten zien dat ze rekening houden met meer belangen dan waar jij of ik mee te overtuigen waren. En als het geen kwaad kan lijkt me er dan ook niets mis mee als Microsoft dat uit zichzelf doet als er al veel vaker klachten zijn over de timing en gebrek aan informatie daarover.

[vtsalf]

Ik krijg het idee dat je nu meer richting het algemene doorvoeren van patches (en of dit gezond is) gaat, in plaat van dit specifieke issue.

Je riep dat het niet handig was om DIT probleem op vrijdag te melden. Maar dat probeer ik al de hele tijd ook te zeggen; DIT issue was al een tijd bekend. Maar ook ernstig genoeg om dit te benadrukken. Ook op vrijdag.

Natuurlijk zijn er genoeg patches waarbij de sysadmin moet overwegen of dat de productie kan verstoren, of het nodig is voor die specifieke machines. Niet elk issue hoeft gemitigeerd te worden, maar sommigen _moeten_ gemitigeerd worden omdat het risico dat het misbruikt wordt opweegt tegen eventuele issues NA het patchen.

Volgens mij heeft MS in deze nog steeds niets verkeerd gedaan door opnieuw te waarschuwen (waar jouw eerste ‘klacht’ begon imo).

Maar algemeen patches beoordelen was hier niet aan de orde. Ook ik heb patches NIET doorgevoerd, want niet relevant of brak productie.

Ik zie (en dat kan ik verkeerd lezen in jouw teksten) meer dat je boos bent op MS _omdat_ ze hier op wijzen.

Als dat zo is, dan moet je ook boos zijn op een Google, Amazon die met hun security teams zelfs lekken bij MS bloot leggen die nog geen patch hebben. Onder de noemer van “Responsible Disclosure”.

Zie ik jouw punt hier nu niet dan?

[kodak]

Je noemt het wel deels op maar gaat er niet echt op in. Wat er in het verleden is gebreurt is relevant maar niet de onderbouwing voor de het moment van deze waarschuwing. Microsoft geeft alleen onderbouwing wat ze gezien hebben maar niet wanneer en waarom dat het moment van melden relevanter maakt dan een eerder moment. Het is helaas juist opvallend dat microsoft niets zegt wanneer ze het al wisten. Het is namelijk ook al heel lang bekend dat duidelijk zijn waarom het een goed moment van melden is helpt om te overtuigen om te gaan patchen. Waarom zou je dan verdedigen dat microsoft zo wel genoeg doet of zelfs geen rekening hoeft te houden met wat belangen van anderen zijn? Dat is dan kennelijk niet gericht om graag te willen dat wie nog steeds niet gepatched heeft over te halen. Meer een houding van we of ze doen genoeg en niet zeuren.

[Zer0]

dat patchen ook neer komt op rekening houden met andere belangen als je wil zorgen dat anderen gaan patchen..

Daarom levert MS ook tools zodat je als bedrijf zelf kunt bepalen waar en wanneer je patches uitrolt. Daarom classificeert MS patches en security-bulletins zodat je een afweging kunt maken.
Daarom worden niet-kritieke fixes met een vast schema verspreid.

Alleen zijn in dit geval als deze opties al verstreken...

Als het ernstig genoeg is zou Microsoft namelijk net zo goed dus kunnen aangeven wat hun afwegingen nog meer zijn geweest. Doen ze niet.

Dat doen ze wel degelijk.... ze geven aan dat het actief misbruikt wordt. Genoeg motivatie

[Reactie gewijzigd door Zer0 op 24 juli 2024 20:57]

[Zer0]

Wat ik stel is dat je als bedrijf net zo goed mag verwachten dat de ontvanger (zeker als het je klant is) ook andere belangen heeft en je daar dus beter ook rekening mee kan houden.

Zeker, maar het belang van de klant is een veilige omgeving, en de klant is niet de systeembeheerder die nu wellicht over moet werken.

[kodak]

Als we nu ook al excuus gaan zoeken dat beheer geen onderdeel van de klant is en het belang van de klant gaan versimpelen dan valt er natuurlijk weinig meer te discussieren. Dat is gewoon kosten wat het kost excuus zoeken om andere belangen te negeren. Dat is net zo goed niet realistisch als een klant die net doet alsof er geen risico is en bijvoorbeeld alleen kijkt naar hoeveel er nog te doen is of waar aan te verdienen valt.

[Zer0]

Beheer is voor de meeste klanten maar een stuk gereedschap dat andere belangen dient.
Maar goed, je hebt het steeds over andere belangen, maar ik heb nog geen enkel belang gehoord wat boven het asap oplossen van deze actief gebruikte exploit zou staan.

De enigen van wie ik me kan voorstellen dat ze niet blij zijn met dit nieuws zijn ICT-dienstverleners/beheerders die nu door de klant/baas gevraagd worden of ze dit al gepatched hebben, en nu moeten uitleggen dat ze dat niet gedaan hebben.

[RGAT]

Gokje: Microsoft kwam er zo rond vanochtend achter dat het actief wordt misbruikt en nu dus zeer hoge prioriteit moet hebben bij bedrijven.
Andere optie: het is een complot van Microsoft om luie systeembeheerders die al dik twee maanden niets aan het doen waren hun weekend af te pakken, in dat geval: eigen schuld en verdient. had je maar in augustus je beveiligingsupdates moeten installeren toen ze je vertelden dat je dat moest doen...

En anders spreek je met je bedrijf af dat jullie vanaf vrijdag (of donderdag?) het internet blokkeren zodat Tweakers en Microsoft updates niet meer bereikbaar zijn, gooi je de boel maandag weer open en ontvang je dus maandag de melding, opgelost!

[Gomez12]

Wat ik stel is dat je als bedrijf net zo goed mag verwachten dat de ontvanger (zeker als het je klant is) ook andere belangen heeft en je daar dus beter ook rekening mee kan houden.

Welkom in het jaar 2020 waarin er wereldwijde communicatie bestaat. Oftewel tijd is geen belang meer als je een bericht de wereld in wilt sturen, aangezien de tijd over de wereld anders is.

[kodak]

Dat zou voor het belang van het moment een prima argument zijn. Maar het laat nog in het midden waarom dit dan het gepaste moment is dan bijvoorbeeld eerder. Het is nu namelijk ook niet duidelijk wanneer microsoft dit al wist. En sinds wanneer het al speelt kan net zo belangrijk zijn als kennis over hoe veel (of weinig) het was.

[ZeromaNoiS]

Als je dit nog niet gepatched hebt ben je echt sysadmin onwaardig naar mijn mening.

Tip: volg de rrs feed van het ncsc!

[Reactie gewijzigd door ZeromaNoiS op 24 juli 2024 20:57]

[arjankoole]

Dat klopt en mag zeker wel bekend zijn. Maar het is niet alsof iemand dan bij het geven van waarschuwing geen rekening meer hoeft te houden met het tijdstip. Net zo min een ontvanger er zich vanaf kan maken dat het een eigen keuze is om er nu wel iets mee te doen.

Bij het aantreffen van een actief gebruikte exploit en het reeds lange tijd beschikbaar zijn van de oplossingen daarvoor? Nee, dan hoef je echt geen rekening te houden met het tijdstip.

Dan is het nu een kritiek iets, wat nu verzonden moet worden, omdat het een maand geleden al gefixed had kunnen worden. Hackers houden ook geen rekening met “ach, het is bijna weekend, laten we niet vervelend doen”. Het tegendeel is eerder waar.

Wij konden binnen een uur beslissen of iets kritiek genoeg was en hadden dan in anderhalf uur de updates gescheduled staan, voor automatische uitrol gedurende de nacht.

[kodak]

Wij konden binnen een uur beslissen of iets kritiek genoeg was en hadden dan in anderhalf uur de updates gescheduled staan, voor automatische uitrol gedurende de nacht.

Dat lijkt me iets om blij mee te mogen zijn, maar waarom zou je dan mogen verwachten dat je je eigen mening over wat mogelijk moet zijn maar kan opdringen aan een ander? Want dat is wat je namelijk als bedrijf doet als je zo min mogelijk duidelijk maakt over de situatie dat je nu een vervolgwaarschuwing geeft. Kritiek is niet iets om zelf te bepalen, zeker niet als je ook een relatie met je klanten hebt waarbij je weet dat die ook aan eisen moeten voldoen. Er zijn altijd anderen die ook geen rekening met je houden maar dat is een heel slecht excuus om het zelf dan ook maar zo min mogelijk te doen. Het is juist een heel goed argument om juist wel rekening te houden als je wil bereiken dat een ander doet waar je op hoopt. Stel een ander komt naar jou toe omdat die van mening is dat jij thuis iets moet doen en daarbij geen enkele belangstelling heeft wat jij aan eisen hebt waar je ook rekening mee moet maken, denk je dan dat die ander er goed aan doet om jou te negeren?

[arjankoole]

‘Kritiek” wordt al sinds jaar en dag bepaald op basis van industriebreed gedragen criteria.

Een CVE is kritiek op basis van een aantal voorwaarden, actief misbruik in het wild.

Dat is geen mening opdringen, dat is een industrie standaard op security vlak. Anders speel je struisvogel, en daar zijn de gevolgen altijd schadelijker van. (Want dan negeer je een actief security probleem.

Jij wil geen meldingen op vrijdag. Prima, ga offline op die dag. Want de wereld gaat zeker niet stoppen met meldingen af te geven.

[kodak]

Ik stel nergens dat de security bug niet kritiek zou zijn. De conclusie 'kritiek' komt uit criteria maar dat zegt niets over hoe je er mee moet omgaan. Je kan een brand ook groot noemen maar dat wil niet zeggen dat je het dus maar met alle mogelijke middelen kan gaan blussen. Er zijn namelijk bij dat blussen ook andere zaken om rekening mee te houden, om bijvoorbeeld de brand niet onnodig groot te houden. Dus is het naar mijn mening ook redelijk als Microsoft of een andere hulpverlener dus laat zien waarom ze op een bepaald moment iets doen. Juist om er voor te zorgen dat anderen gaan patchen. Aan de andere kant zou je van een hulpdienst ook niet accepteren als alleen maar iets doet als het ze zelf het beste uit komt. Ook niet als die hulpdienst vrijwillig is.

[Reactie gewijzigd door kodak op 24 juli 2024 20:57]

[arjankoole]

Je doet een hoop semantiek.

Wat wil je nou eigelijk?

[Wim-Bart]

We hadden met SCCM de boel al binnen een dag gepatched na testen. Bedrijven die het nu nog moeten doen hebben een falend Security beleid.

[_Eend_]

Als je geen security beleid hebt kan het ook niet falen

[kw_nl]

Hier ook, maar schijnbaar is patchen niet genoeg. Je moet ook nog een erg key aanpassen...

[Wim-Bart]

Yep, maar dat hadden we al in place. Je moet in GPO wat zaken goed zetten:
Domeincontroller: Kwetsbare verbindingen via een beveiligd kanaal van NETLOGON toestaan
Lid van domein: gegevens in beveiligd kanaal digitaal versleutelen of ondertekenen (altijd)
Microsoft-netwerkclient: clientcommunicatie digitaal ondertekenen (altijd)
Microsoft-netwerkserver: servercommunicatie digitaal ondertekenen (altijd)

En als extra eventueel:
Microsoft-netwerkserver: validatieniveau voor de SPN-doelnaam van de server

[Tweaker_19]

Het is sinds augustus al bekend, en dit is al hun derde waarschuwing. Neem je eigen verantwoordelijkheid eens als ICT'er/bedrijf en zorg dat het in orde komt zou ik zeggen. Waarom verwacht je dat Microsoft iedereens handje moet vasthouden? Waar komt deze 'luiheid' vandaan?

Ze geven aan dat iets actief wordt misbruikt dat al maanden gedicht is zeg! En dan zeuren over timing omdat het bijna weekend is... Ja want de lieve misbruikers wachten wel tot het weekend voorbij is voordat ze het systeem platgooien...

Ik zou toch echt liever een paar uurtjes langer doorwerken op vrijdag dan achteraf met grote problemen zitten. Maar goed, jij hebt blijkbaar liever stipt op tijd weekend om achteraf zeker te zeuren dat het hele systeem plat ligt en je een week lang moet overwerken en je collega's niets kunnen doen in de tussentijd ofzo?

Werk hebben is niets, maar werk houden...

[Misha Engel]

Dat had je ook ergens in augustus of september kunnen doen.

[ZeroZXD]

De patch is al sinds augustus uit. Als je deze vanmiddag nog moet installeren ben je misschien al een beetje te laat.....

[wildhagen]

Als het goed is heb je deze patch 2 maanden geleden al uitgerold, hij is immers in augustus al uitgekomen.

Dus je kan rustig weekend gaan vieren.

[Verwijderd]

En we kunnen weer aan het werk op de vrijdagmiddag...

Of in de 2 afgelopen maanden he....

[Brahiewahiewa]

De melding is donderdag al geplaatst; je had er vanmorgen meteen mee kunnen beginnen

[Junia]

Hoe zit het eigenlijk met de beschikbaarheid van de update voor oudere systemen zoals 2008 R2? Vroegáh bracht MS nog wel eens updates uit voor XP, zelfs ver na support date, voor de zeer kritieke security exploits. Wordt dit nog steeds toegepast, of ben je geheel overgeleverd aan de ESU licensing?

[wildhagen]

Voor Windows 2008 R2 is de patch ook gereleased. Deze is weliswaar sinds 14 januari 2020 uit support, maar dat is nog redelijk recent.

Windows XP is al 6.5 jaar out of support, daar gaat heus geen (publieke) patch meer voor uitkomen. Daarnaast gaat het hier om een lek in de Domain Controller-functionaliteit, dat is een serverfunctie,. Windows XP was een client OS.

Ook Windows 2000, 2003, 2008 (non-R2) zijn out of support, en krijgen deze patch dus ook niet meer.

[Reactie gewijzigd door wildhagen op 24 juli 2024 20:57]

[sprankel]

Daar mag je niet op rekenen, dat is zeer uitzonderlijk en zuiver op goodwill. Of ze het nog gaan toepassen is en blijft een vraagteken. Deze update 'as is' is betalend indien je nog op 2008 versies draait.

Ook belangerijk, vanaf 09/02/2021 zullen de DC's Secure RPC afdwingen wat inhoud dat ieder verbinding naar de DC hieraan moet voldoen of afgeblokt word waarbij dit niet langer uit te zetten is via GP.

[Fijinees]

Een oud collega van mij is erg blij met deze meldingen. Er zijn altijd een stel bedrijven die laat zijn met patchen, en hij mag dan weer opdraven. Zeker zoals nu, weekendtarief.

[Djaro]

waarom hebben bedrijven dan een domain controller aan het internet hangen dan of mis ik ergens iets ?

[wildhagen]

Een aanval hoeft niet per se direct van Internet te komen he. Kan ook gebeuren via een interne PC/laptop in het netwerk die met een trojan, backdoor oid is besmet, en als ze dan via die PC/laptop het netwerk binnen komen, kunnen ze dus van binnenuit een aanval op de domain controllers uitvoeren.

[mdcoo]

Dat er een 3e bulletin wordt uitgegeven door Microsoft zegt iets over de gradatie van deze CVE, Critical dus.

In meest normale gevallen heb je niet 1 domain controller in je netwerk, zeker niet als het om een forest DC gaat. Dus dit vergemakkelijkt testen min of meer. Geen reden dus, mocht dit nog steeds op je actie lijstje staan, tenzij je patching window eens per kwartaal is. maar zelfs dan zou ik niet wachten met een Critical patch.

Microsoft heeft een mooie "manual" voor het installeren en testen van deze patch.

https://support.microsoft...channel-connections-assoc

[wokkelz]

Zit deze patch nu in de maandelijkse updates of moet je dit apart patchen?

[ASS-Ware]

Zit deze patch nu in de maandelijkse updates of moet je dit apart patchen?

De maandelijkse van augustus.

[RoytjeP]

Overigens, als men geen ESU heeft afgesloten wat ik me goed kan voorstellen daar er bijv. een ESA voor nodig is en (om wat voor reden dan ook) nog steeds Windows 2008R2 draaien, heeft 0patch.com een dienst die dit soort serieuze lekken ook fixen.

Zeer klein bedrag per jaar (lager dan ESU). Installatie van 0patch zónder reboot, aanzetten van de fix zónder reboot. Dus er is totaal geen excuus meer om dit niet uit te rollen. Letterlijk 1 vinkje omzetten. In memory is de fix direct toegepast. Mocht je alsnog tegen problemen aanlopen, welke er gewoon weg bijna niet zijn, dan is het weer 1 vinkje omzetten en de patch is uitgezet (wederom zonder reboot en deinstallatie).

[michielRB]

Heb je ook nog problemen als je uitsluitend authenticatie via RADIUS toestaat? Dan wordt de accountprovider niet direct door de client benaderd.

[arnord]

Nee Radius is in deze niet kwetsbaar aangezien het om NETLOGON gaat.

[michielRB]

Dat bedoel ik niet. M'n vraag was meer met de gedachte dat de authenticatie via RADIUS indirect is en daardoor de NETLOGON niet direct wordt aangesproken door de inloggende client.