Door Microsoft opgegeven Azure-locaties maakten rce mogelijk via Windows-tool

Het Nederlandse securitybedrijf Eye Security ontdekte een kwetsbaarheid in Microsofts Windows Update Health Tools die remote code execution mogelijk maakte op Windows-apparaten van 'bijna tienduizend bedrijven wereldwijd'. De kwetsbaarheid is inmiddels opgelost.

De Windows Update Health Tool is software die automatisch via Windows Update naar zakelijke apparaten worden verstuurd die beheerd worden met Microsoft Intune. De software maakt het updaten van apparaten betrouwbaarder en laat bedrijven bijvoorbeeld sneller kritieke updates installeren. "Een oudere versie bleef echter verbinding maken met Azure-opslaglocaties die niet langer in beheer waren van Microsoft", schrijft Eye Security.

Het beveiligingsbedrijf registreerde na deze ontdekking het Azure-opslagdomein, waarna ze 'binnen enkele uren wereldwijd verkeer zagen binnenkomen'. "Het ging om gestructureerde verzoeken van apparaten die een door Microsoft ondertekende updateservice gebruikten. Een voorspelbaar naamgevingspatroon wees vervolgens op nog meer verlaten endpoints. In zeven dagen tijd ontvingen tien van deze opslaglocaties meer dan een half miljoen verzoeken afkomstig uit bijna tienduizend Azure-tenants. In een gecontroleerde test konden we aantonen dat remote code execution onder specifieke voorwaarden mogelijk was."

In een uitgebreidere blogpost legt Eye Security uit dat rce alleen mogelijk was in de 1.0-versie van de Windows Update Health Tools. Vanaf versie 1.1, die in december 2022 verscheen, waren alle Azure-locaties nog wel in Microsofts beheer. Eye Security zegt dan ook dat de impact van de kwetsbaarheid klein was, omdat er veel meer Windows-apparaten in omloop zijn dan de duizenden apparaten die de kwetsbare Windows Update Health Tools gebruiken. Eye Security meldde het probleem op 7 juli bij Microsoft en droeg later die maand het beheer van de Azure-locaties over aan het bedrijf. De kwetsbaarheid is daarmee gedicht.

Update, 13.34 uur – Het artikel is aangevuld met informatie over de Windows Update Health Tool. Met dank aan FREAKJAM.

Reacties (17)

[david-v]

Wat ik niet helemaal begrijp, dit was een kwetsbaarheid in de Windows Update Health Tools. Die zorgt ervoor dat een PC juist de laatste updates heeft. Wordt de tool dan zelf niet geupdate? Want dit was in versie 1.1 opgelost en die kwam al in 2022 uit.

Zijn dit machines die deze tool wel hebben maar vervolgens de beschikbare updates niet installeren, waaronder ook de update van de tool?

[FREAKJAM]

De omschrijving in het artikel van Windows Update Health Tools klopt niet helemaal. Ik heb de redactie hier net over getipt.

De Windows Update Health Tool is geen algemene software die via Windows Update naar alle pc’s wordt verspreid. Het is een component dat specifiek wordt gebruikt in zakelijke omgevingen waar apparaten worden beheerd via Microsoft Intune.

Deze tool maakt deel uit van de expedite functionaliteit binnen Windows Update for Business. Met expedite kunnen organisaties het uitrollen van kritieke updates versnellen, bijvoorbeeld bij zero-day kwetsbaarheden of andere urgente patches, zonder bestaande update-ringen en hun geplande schema’s aan te passen.

Normaal gesproken definieer je in Intune update-ringen om updates volgens vooraf ingestelde schema’s te distribueren. Wanneer echter een urgente patch noodzakelijk is, kun je via expedite het updateproces direct starten. Binnen de Windows Update Health Tool bevindt zich onder andere expediteupdater.exe, dat verantwoordelijk is voor het versnellen van dit proces.

[Reactie gewijzigd door FREAKJAM op 23 november 2025 13:19]

[Bor]

Die zorgt ervoor dat een PC juist de laatste updates heeft. Wordt de tool dan zelf niet geupdate?

Jawel maar dan moet je die updates wel installeren natuurlijk. Sommige mensen updaten nooit (dom dom!) maar er zijn ook systemen die door problemen of sterke beperkingen niet kunnen updaten. Dat had natuurlijk al lang moeten opvallen. Uiteindelijk is met name degene die slecht of geen beheer uitvoert in dit geval kwetsbaar.

[david-v]

Uiteindelijk is met name degene die slecht of geen beheer uitvoert in dit geval kwetsbaar.

Ja vooral dit is wel elke keer gebleken. Het gaat hier niet om een zero-day vulnerability. Up to date blijven is de oplossing voor veel andere problemen zoals deze. Ik vermoed wel dat de meeste PC's die dit probleem hebben achter een bedrijfspolicy zitten waardoor ze misschien geen updates konden installeren. Dat maakt deze exploit nog erger als dat zo is, want dan kan zijn de PCs bij die bedrijven kwetsbaar.

[Bor]

Bij mensen "achter een bedrijfspolicy" zorgt het bedrijf er doorgaans voor dat een systeem up to date blijft natuurlijk.

[Flex-Able]

Wat ik er van begrijp is dat het gaat om machines die de Health Tools (al) hebben, maar vanwege updateproblemen of beperkingen toch niet de nieuwste versie van de tool of andere updates installeren.

[Flex-Able]

Keurig opgelost naar mijn idee, leuk artikel trouwens.

[Bor]

Dat het is opgelost is belangrijk maar mede net zo belangrijk vind ik hoe dit heeft kunnen gebeuren.

"Een oudere versie bleef echter verbinding maken met Azure-opslaglocaties die niet langer in beheer waren van Microsoft",

Dit soort locaties behoren niet vrijgegeven te worden precies omdat er vroeg of laat iemand anders kan zijn die de locaties in handen krijgt die mogelijk niet echt goede bedoelingen heeft.

[Blokker_1999]

Wat mij betreft is er een groter probleem in heel de cloud wereld. Op een platform als Azure, maar ik neem aan dat dit bij meerdere platformen zo is, kan je een hoop resources aanmaken die vanaf het internet bereikbaar zijn, maar deze moet je wel aanmaken met een globaal unieke naam. Waarom zorg je er niet voor dat als ik iets in mijn tenant aanmaak, dat dit een toegangspunt krijgt waarin een unieke identifier van mijn tenant is opgenomen? Op die manier maak je het net onmogelijk om ooit in dit soort situaties terecht te komen.

Het probleem is voor mij dan ook niet dat MS het storage account achter payloadprod0.blob.core.windows.net had stopgezet, maar wel dat ze zo een generieke URL hebben die door elke andere tenant geclaimd kan worden na het vrijgeven. Beter zou zijn resource.tenantidentifier.blob.core.windows.net. Dan heb je dit nooit voor.

[Reactie gewijzigd door Blokker_1999 op 23 november 2025 13:24]

[Keypunchie]

Maar toch ook gek dat er blijkbaar geen signing plaatsvindt van de patches?

[carlo]

Ik neem aan dat er signing op de patches zit, maar omdat deze tool naar keuze een versie kan pushen, kun je dus ook een (zeer) oude versie pushen met bekende vulnerabilities.

[Keypunchie]

Ah, slim, die stap had ik niet doorgedacht!

[metalmania_666]

Precies dit. Waarom zou Microsoft deze locaties van de hand doen?

Inmiddels heeft de geschiedenis wel uitgewezen dat je op je vingers kunt uittellen dat het mis gaat

[djwice]

Gebeurt relatief vaak, ook gezien bij Coca-Cola en bij andere grote bedrijven dat locaties waar door wereldwijde software naar wordt gekeken gewoon wordt verwijderd omdat iemand uit dienst gaat of een team opgeheven wordt, zonder dat het beheer overgedragen is. Dus geen kostenplaats die de kosten dekken, mailtjes komen niet aan, en dus haalt de centrale IT organisatie gewoon de infrastructuur weg (= vaak geautomatiseerd proces).

Als je dan weet dat het vaak om enkele tientjes per maand gaat, is het natuurlijk zeer bijzonder dat dit gebeurd.

Lastig met moderne infra is dat als je het goed inricht je automatische updates hebt en zeer lage tot geen beheerkosten. En dat vertaalt zich weer tot opheffen van werk, teams en dan weer infra.
Veel organisaties kunnen niet omgaan met belangrijke infrastructuur die kosten heeft op het niveau dat de laagste team manager er niet eens over nadenkt en blind ondertekend.

Traditioneel waren kritieke componenten op het prijsniveau waar de CTO/CIO/COO besluiten over neemt (meerdere tonnen, miljoenen).
Nu ontglipt het dus de aandacht i.v.m. het verwarren van prijs met impact of belang.

Voorbeeld: ooit een 2M/yr kostende Oracle oplossing vervangen door een 8.5k/yr RedShift Spectrum oplossing met 1.5x versnelling van de verwerkingstijd. Het meest lastige was de kosten verlaging, wat eerst een trost team was die een dure oplossing beheerde en alles mocht, werd ineens niet eens een agenda puntje en kreeg kostendruk op mensen omdat daar de resterende kosten lagen...

Organisaties zijn vreemde dingen. Veel externe kosten maken geeft soms aanzien, als die wegvallen kunnen sommige mensen hun ego er niet meer mee poetsen en dat geeft bijzonder gedrag.

[Reactie gewijzigd door djwice op 23 november 2025 13:26]

[neevedr]

Waarom zit dit niet achter een custom DNS naam? Die kan je lekker in eigen beheer houden en dan maakt het niet uit dat je storage account url veranderd. Azure Frontdoor er voor en je hebt gelijk een load-balancer. Wel een beetje gevalletje eet je eigen hondenvoer en lees je documentatie.

En bij een “Azure-locatie” denk ik toch echt aan een Azure Regio (west-Europe, north-Europe) omdat zowel in de Azure portal als in bijvoorbeeld ARM en BICEP dat een “location” wordt genoemd.

[Reactie gewijzigd door neevedr op 23 november 2025 13:41]

[carlo]

Volgens het artikel gaat het om domeinnamen die niet meer gebruikt werden, ergens extern geregistreerd. Achteraf is makkelijk te zeggen dat ze dit anders hadden moeten implementeren, maar veel projecten beginnen klein als een proof-of-concept en dan wordt er nog wel eens een shortcut genomen.

In v1.1 zijn die externe domeinnamen geschrapt, dat was in 2022. Toch slordig als je een tool hebt om updates uit te rollen, maar dat je die update tool al 3 jaar niet hebt ge-update.