Microsoft brengt tussentijdse patch voor kritiek lek in Windows Server uit

Microsoft brengt dinsdag een patch uit voor een kritiek lek in Windows Server. Door het lek heeft kunnen gebruikers meer rechten kunnen krijgen dan ze horen te hebben, maar Microsoft maakt verder geen details bekend.

Ondanks dat het lek alleen in Windows Server zit, brengt Microsoft de patch ook uit voor consumenten- en zakelijke versies van Windows. Dankzij die update zouden die pc's een iets betere beveiliging tegen eventuele aanvallen moeten krijgen, omdat de bug wel bestaat in die versies van Windows, maar kwaadwillenden met alleen dat lek niets kunnen uitrichten; daarvoor zouden ze meerdere lagen van beveiliging moeten doorbreken.

Microsoft maakt geen details bekend over het lek, alleen dat het kan leiden tot 'elevation of privilege' van gebruikers. De patch komt om zeven uur 's avonds Nederlandse tijd uit voor alle besturingssystemen en Microsoft zal ook zijn malwaretool Malicious Software Removal Tool updaten. Het lek zit in alle bekende Windows-versies waaronder ook de preview-versie van Windows 10. De oudste versie van Windows die Microsoft patcht zijn Server 2003 en Vista.

Update, 19/11 11:00: Microsoft heeft de patch inmiddels uitgebracht.

Reacties (55)

[wildhagen]

De patches zijn voor zover ik kan zien nu online, dit is het bijbehorende security bulletin (MS14-068): https://technet.microsoft.com/library/security/ms14-068

Betreft dus een Kerberos-related issue.

[Reactie gewijzigd door wildhagen op 27 juli 2024 04:47]

[Verwijderd]

Inmiddels geïnstalleerd. Prima!

Edit: @Armin ik had er ook 2.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 04:47]

[Verwijderd]

Vulnerability in Kerberos Could Allow Elevation of Privilege
https://technet.microsoft.com/library/security/ms14-068

This security update resolves a privately reported vulnerability in Microsoft Windows Kerberos KDC that could allow an attacker to elevate unprivileged domain user account privileges to those of the domain administrator account. An attacker could use these elevated privileges to compromise any computer in the domain, including domain controllers. An attacker must have valid domain credentials to exploit this vulnerability. The affected component is available remotely to users who have standard user accounts with domain credentials; this is not the case for users with local account credentials only. When this security bulletin was issued, Microsoft was aware of limited, targeted attacks that attempt to exploit this vulnerability.

Details staan op de Security Research & Defense blog:
http://blogs.technet.com/...-about-cve-2014-6324.aspx

Met andere woorden. Patch je Domain Controllers a.s.a.p.!

[ODF]

Nou mooi, net vorige week al mijn beheerde Windows Servers meerdere keren mogen opstarten voor de aanwezige updates/patches en nu weer dus. Weer een avond werk inplannen Maar ja zonder deze kritieke patch heb ik misschien meer werk te doen.

[Armin]

Volgens mij vergist Tweakers zich dan ook.

Zoals ik het lees is het een update op een vorige week uitgebrachte fix. Als onderdeel van de kritieke fix van vorige week voor de SSL/TLS bibliotheek (SChannel) werd tevens een nieuwe feature toegevoegd. Dat was namelijk een backport van de in Windows 8.1.1 geintroduceerde AES-GCM ciphers.

Nu blijkt dat onder bepaalde omstandigheden clients die nieuwe ciphers 'niet leuk' vinden. Er zijn geen details maar dat lijkt me vooral een compatibiliteits probleem met oude non-Microsoft clients. (UPDATE: Inderdaad oudere Java versies blijken gevoelig door een bug/beperking in Java SSL die anders gemaskeerd bleef omdat eerder een andere cipher default gekozen werd.) Hoe dan ook Microsoft heeft vervolgens eerst een workaround via het register bekend gemaakt waarmee je die nieuwe addities handmatig uit kunt zetten. Het KB artikel was ook geupdate.

Omdat dat omslachtig is (Je moest een stukje specifiek text uit het midden van drie bestaande registry key waarde halen), heeft men nu een automatische patch toegevoegd die dit automatisch doet. Je kunt ze dan nog steeds weer aanzetten als admin, maar ze staan nu dus default uit. Dat is gedaan via een toevoeging, en het KB artikel is vervolgens weer geupdate.

Echter omdat bestaande servers de oude patch dus al geinstalleerd hebben, wordt de patch ge-herpubliceert. Wie naar het security bulletin van tweakers kijkt ziet dan ook dat het de bestaande bulletin van vorige week is.

Details over deze specifieke heruitgebrachte fix zijn hier te lezen:

https://support.microsoft.com/kb/2992611

Admins die uberhaupt al een custom cipher list gebruikten zijn niet getroffen, omdat de custom lijst immers altijd de default overschreef.

UPDATE: Het blijkt dus om twee updates te gaan. De eerste zoals beschreven in de text van het Tweakers artikel is een nieuwe fix. Echter de link van Tweakers verwijst naar het algemene bulletin waarin de fixen van vorige week beschreven staat. Deze lijst is echter geupdate vanwege het door mij beschreven probleem (kb 2992611).

Dat verklaart ook waarom ik twee updates aangeboden kreeg

[Reactie gewijzigd door Armin op 27 juli 2024 04:47]

[dasiro]

hondse job toch hé, sysadmin zijn. liever buiten in de kou bladeren prikken

[johnkeates]

Dit soort repeterende taakjes zijn eigenlijk meer voor computers bedoeld, en toch moeten mensen te uitvoeren, klopt niet helemaal, denk je niet?

Edit: wat die heren onder mij dus zeggen. Je gaat echt niet je hele park met de hand updaten mag ik hopen. Je jast alles toch wel door je DTA heen en daarna rol je het gewoon automatisch uit op productie.

[Reactie gewijzigd door johnkeates op 27 juli 2024 04:47]

[Gepetto]

Als je als sysadmin iets niet wilt, is het wel dat servers automatisch gaan updaten en rebooten. Dit hoor je gewoon zo te plannen dat het op een tijdstip gebeurt dat niemand er last van heeft.

[Verwijderd]

Doen wij hier wel hoor, wij hebben meer dan 200 servers hier. We approven ze via wsus en 's nachts rebooten ze. In praktijk valt er wel iets om, maar op jaarbasis is dat verwaarloosbaar.

[.oisyn]

Wat de meneer boven me zegt. Het feit dat je zelf het tijdstip wil kiezen, impliceert niet dat je elke server handmatig moet updaten.

[Gepetto]

Dus jullie testen niet eerst even of een update geen problemen geeft, maar voeren ze gelijk automatisch door op 200 servers? Lijkt me toch dat je dan niet vrolijk wordt wnneer er een 'vuile' update tussen zit.

(Ik vraag me trouwens af of je niet 200 werkstations bedoelt, want bij 200 servers vraag ik me toch af hoe groot het bedrijf wel niet is waar je werkt.)

[Noeandee]

Is het een update waarbij een herstart nodig is dan? Anders valt het nog wel mee..

[wildhagen]

Ja, deze update vereist een herstart.

[Neko Koneko]

Nou mooi, net vorige week al mijn beheerde Windows Servers meerdere keren mogen opstarten voor de aanwezige updates/patches en nu weer dus. Weer een avond werk inplannen Maar ja zonder deze kritieke patch heb ik misschien meer werk te doen.

Och arme, wat is MS ook stom, ze hadden gewoon moeten wachten tot Patch Tuesday

Ik vind het juist goed dat MS er in dit geval gewoon snel bij is

[Armin]

Zeker omdat een van de twee updates dus een compabiliteitsprobleem is met o.a. oude Java versies.

Zou leuk zijn als men doodleuk zou zeggen dat ze maar tot volgende maand moeten wachten en tot die tijd geen Java met SSL gebruiken

[Soldaatje]

Gaat dat niet vanzelf dan?

[wildhagen]

Je kan patches wel automatisch laten installeren, en op werkstations is dat meestal ook wel het geval.

Maar op een server wil je toch vaak liever zelf de controle hebben over de zaken, omdat je goed wil controleren of alles netjes terugkomt bijvoorbeeld. Of denk aan ketens van applicatiservers die afhankelijkheden van elkaar hebben en in een bepaalde volgorde downgebracht moeten worden.

Het is zo lullig als bijvoorbeeld al je domain controllers tegelijkertijd herstarten na installatie, en als er dan een probleem is en ze komen niet meer in de lucht heb je een .... uitdaging, zullen we maar zeggen

Als je het zelf doet voorkom je dat soort dingen dus een beetje.

[HyperBart]

Mwoah, vandaag de dag (zeker met gevirtualiseerde omgevingen) hoor je toch al je dingen wat redundanter uit te voeren en dan met SCCM of consoorten de juiste maintenance windows er op hangen en gestaged patchen...

Buiten applicatie-gerichte servers die specifiek niet te ontdubbelen is het allemaal wel goed te doen vandaag de dag.

File-server
AD
Exchange
ADFS & ADFS Proxy
SQL
RDS
XenApp
Hyper-V
etc

Allemaal rollen die al heel prima high available of geclustered gedraaid kunnen worden.

[MAX3400]

Je komt enigszins generaliserend over; er zijn zat kleinere/MKB omgevingen die wel een RDS-omgeving hebben staan maar dat dan mooi draaien op 1 hele dikke host. Of dat er geen geld is voor een fors SAN waardoor je veelal hypervisor-hosts ziet die niet 100% geclusterd of HA elkaar wel gedeeltelijk kunnen ondersteunen.

Daarnaast, maar dat is altijd een afweging van geld vs. tijd: zaken clusteren (of het nou bare-metal of gevirtualiseerd is), is in bijna alle gevallen aanzienlijk duurder zowel voor hardware als software, om nog maar te zwijgen over (langdurige) personeelskosten voor de goede/correcte beheerders.

[Gert]

Daarnaast failovert lang niet alles met behoud van verbinding waardoor gebruikers dit merken en die willen dat niet merken, dus elke failover is er een te veel.
Zelfde als dingen als domein controllers, prima redundant uit te voeren maar toch blijf je er liever van af...

[Noeandee]

Ook applicatie servers kan je best redunant draaien als ze bedrijfskritisch zijn, middels App-v, citrix of andere app virtualisatie paketten of via wat slim powershell scripting. Tenzij je echt aan servergebonden licenties vast zit. Of restricties hebt kwa capaciteit.

Wel goed van Microsoft, dat ze tussendoor patchen indien nodig.

[johnkeates]

Wel goed van Microsoft, dat ze tussendoor patchen indien nodig.

Wat een onzin van Microsoft dat ze patches standaard niet uitgeven zodra ze klaar zijn, maar voor een vast moment kiezen. Dan moet je dus opeens alle patches na gaan zitten lopen en testen voor dat je eens verder kan met je werk.

[Alex3]

Dan moet je vaker opnieuw opstarten. Niet zo handiger met een server.

[johnkeates]

Hoezo? Je hoeft toch niet patches te installeren puur om dat ze er zijn? Je kan dan gewoon zelf je schedule bepalen en als er tussendoor een kritiek probleem bekend is kan je gewoon zelf beslissen of je 'm direct controleert in je testomgeving en dan in je productie omgeving gaat draaien, of dat je hem pas in de volgende maintenance window meepakt.

Nu ben je dus verplicht om je patch moment op Microsoft af te stemmen en blijven patches die je misschien wel heel graag wil hebben dus uit tot dat Microsoft denkt dat het een goed idee is. Daarnaast geeft het ook een distributie spike om dat iedereen op hetzelfde moment moet gaan downloaden.

[Gepetto]

Daarnaast geeft het ook een distributie spike om dat iedereen op hetzelfde moment moet gaan downloaden.

Ach, ik heb nooit het idee gehad dat MS bandbreedte tekort kwam.

[Alex3]

Nee, dat kan niet. Als een patch eenmaal bekend is kun je hem misbruiken.

[johnkeates]

Volgens mij worden patches gemaakt om dat er te misbruiken lekken zijn ik denk dat je het verkeerd om hebt.

Je zou misschien nog kunnen kijken naar stille updates voor lekken die alleen Microsoft weet, maar die kan je dan alsnog op een vast tijdstip uitrollen.

[Alex3]

Als een patch al bekend gaan mensen hem vergelijken met de oorspronkelijke code en komen zo achter de kwetsbaarheden. Daarmee kun je op nog niet gepatchte computers inbreken.

[johnkeates]

Welke oorspronkelijke code? Het lijkt nu alsof je een beetje een uitweg aan het zoeken bent. De code is alleen in te zien door Microsoft en een klein groepje partners.

Verder kan je er van uit gaan dat Microsoft bij het vinden van een lek niet de enige is.

[Alex3]

Je dacht toch zeker niet dat er niemand was die de code dissembleert en zo het lek vindt door de versies te vergelijken?

[Phyxion]

Klopt, alhoewel er wel manieren zijn om gewoon een vaste tijd te schedulen (of gewoon even een script in elkaar draaien die Windows Update draait).

[trisje]

Ja dat kan Windows ook automaties hoor. Geen script voor nodig zit gewoon ingebakken.

[Verwijderd]

Mee eens, al ging het me nog nooit mis handmatig. Tot afgelopen weekeinde dan (BSOD). Dan ben je heel blij dat je zelf aan de knoppen zit.

[kuips55]

Same here

[SuperDre]

achja, daar wordt je toch ook gewoon voor betaald...

[Soldaatje]

Tenzij hij vrijwilliger is, dan krijgt hij alleen een kerstpakket.

[woekele]

Zo te horen is dit niet remote exploitable??? Kan morgen dus ook geinstalleerd worden?

Waarom word ik naar 0 gemod? Het is ongeveer de belangrijkste vraag die je kunt stellen.

[Reactie gewijzigd door woekele op 27 juli 2024 04:47]

[wildhagen]

Uit het Security Bulletin:

An attacker must have valid domain credentials to exploit this vulnerability. The affected component is available remotely to users who have standard user accounts with domain credentials; this is not the case for users with local account credentials only.

In andere woorden, hij is dus remote exploitable, mits ze een domain account + bijbehorend password in handen hebben. Anders niet.

[woekele]

+ er moet een service listening zijn om die gegevens op in te typen lijkt me. Een webserver is dan niet genoeg, hoop ik?

[johnkeates]

Bij Microsoft wel als je IIS draait. Bij andere webservers is de integratie weer anders, of afwezig, waardoor je dat probleem inderdaad niet hebt.

[Eloy]

Waarom maken ze dan geen details bekend? Het is een kwestie van uren voordat een programmeur de patch reverse-engineert en ziet wat er wordt gepatcht. Zoals met de goto fail; bug, verschil was wel dat de source beschikbaar was natuurlijk.

[Verwijderd]

Details staan op de Security Research & Defense blog:
http://blogs.technet.com/...-about-cve-2014-6324.aspx

[wildhagen]

Die details zijn bekend gemaakt op het moment dat de patches uitgekomen zijn, gisteravond rond 19:00

Waarom ze dat eerder niet doen: simpel, geen slapende honden wakker maken en uitleggen hoe het lek te misbruiken is, vóór de patch beschikbaar gesteld is, en er iets tegen gedaan kan worden.

[Eloy]

Door het lek heeft kunnen gebruikers meer rechten kunnen krijgen dan ze horen te hebben, maar Microsoft maakt verder geen details bekend.

Ik zie nu pas in het artikel dat de patch nog helemaal niet wat uitgebracht toen het artikel was gepubliceerd. Het is nuduidelijk waarom ze op dat moment nog geen details hadden gepubliceerd.

[syl765]

Microsoft account is experiencing technical problems. Please try again later." Duh.

Typerend.
Ik loop steeds vaker tegen dit soort zaken aan. ook bij Microsoft kunnen er web wise nog heel wat zaken verbeterd worden.

Goed dat ze het lek direct patchen. Wat ik wel een beetje eng vind, want vaak zijn ze niet altijd even snel. En als ze nu al met een patch komen voor een onbekend lek dan houd ik mijn hart vast.

[The_Weird1]

Misschien iets met betrekking tot het Kerberos Golden Ticket probleem?
http://www.infoworld.com/...olden-ticket-attack-.html
http://cert.europa.eu/sta...TheGolden_Ticket_v1_1.pdf

[RBekooy]

http://support.microsoft.com/kb/3000850 => November 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2

[Tadream]

Wij hebben een test RDS server waar voornamelijk wij als sysadmins op werken en voeren daar altijd eerst de updates op uit. Vervolgens wachten we minimaal een week en houden sites zoals Tweakers in de gaten om te kijken of er geen gekke meldingen komen. Pas dan zullen we het op de overige servers uitrollen.
We hebben vrijwel alles virtueel en alles is zo teruggezet met veeam backup maar ik voorkom het liever.
Dit soort dingen ga je absoluut niet automatisch doen binnen je bedrijf/vestigingen.

[syl765]

@Tadream

Lijkt mij toch redelijk riskant. Ik weet niet hoe groot het serverpark is, maar wat doe je als je inderdaad slachtoffer blijkt te zijn. Ga je dan je machines terugzetten, en als dat zo is, van welke datum. Een machine van een week oud terugzetten is nu niet echt fijn om te doen.
En tot welke datum vertouw jij je data? Alle data inclusief je databases een week terug houd dus in dat je een week niets hebt gedaan. Tevens kun je data niet meer vertouwen die na vandaag veranderd is, je weet namelijk niet wanneer het lek misbruikt is. Daar is natuurlijk wel achter te komen maar dat gaat heel veel tijd kosten en tijd is toch vaak een belemmerende factor.

Ik neem liever geen risico en patch vandaag. Als er problemen ontstaan dan is dat jammer, maar even een heel nieuw forest optuigen omdat er een x aantal dagen geleden iemand in heeft lopen rommelen en je totaal geen idee hebt wat er allemaal gebeurt is is een veel grotere bak ellende. Natuurlijk heb je shit als er aken niet meer werken, maar ik kan nog wel mijn data vertrouwen en dat vind ik toch wel een groot voordeel.

[Reactie gewijzigd door syl765 op 27 juli 2024 04:47]