Bezpieczne aktualizacje systemu Windows to fundament ochrony wielu organizacji. Najnowsze badania przeprowadzone przez zespół Eye Research wykazały jednak, iż jedno z narzędzi Microsoftu, które miało zwiększać niezawodność aktualizacji, zawierało poważną lukę, mogącą umożliwić zdalne wykonanie kodu (RCE). Co gorsza – problem wynikał z nieużywanych, porzuconych zasobów w chmurze Azure, co nasuwa pytanie, jak dobrze znane i zaufane komponenty mogą stać się wektorem ataku.
Co odkryli badacze?
Eye Research zidentyfikowało, iż Windows Update Health Tools (wersja 1.0, powiązana z KB4023057) przez cały czas odwołuje się do kont Azure Blob Storage, które nie są już zarządzane przez Microsoft.
Konkretnie narzędzie – uhssvc.exe, będące częścią Update Health Tools, łączyło się z domenami takimi jak payloadprod0.blob.core.windows.net, które – dzięki przewidywalnemu schematowi nazewnictwa – można było zarejestrować. Po rejestracji tych porzuconych kont Eye Research zaczęło otrzymywać dziesiątki, a choćby setki żądań HTTP GET od urządzeń na całym świecie, pochodzących z niemal 10 000 odrębnych dzierżaw Azure („tenants”).
Mechanizm ataku i technologia
Badacze przeanalizowali działanie usługi uhssvc.exe, która po uruchomieniu:
- Sprawdza, czy urządzenie jest zarejestrowane w Azure/Entra (czy należy do zarządzanej organizacji).
- Jeśli tak, pobiera plik enrolled.json z kontenera blob odpowiadającego konkretnej dzierżawie (/<tenant_hash>/enrolled.json).
- Następnie pobiera plik Devices/<device_id_hash>.json, który zawiera politykę przypisaną do danego urządzenia („policy ID”).
- Usługa kontynuuje polling plików .json w kolejnych ścieżkach, w zależności od wersji systemu i procesora, aż w końcu odczytuje pole „EnterpriseActionType” w pliku konfiguracyjnym.
- Jedna z możliwych akcji to ExecuteTool, czyli wykonanie binarki. Okazało się, iż narzędzie pozwala na uruchamianie wyłącznie plików podpisanych przez Microsoft.
- Badacze wykorzystali ten mechanizm do stworzenia JSON-owego payloadu, który wskazywał na explorer.exe (pochodzący z Windows), a następnie przekazywał parametr uruchamiający, np. calc.exe. W ten sposób w testach rzeczywiście udało się uruchomić kalkulator — klasyczny dowód na możliwość RCE.
Źródło: Eye Research
Źródło: Eye ResearchWersja 1.1 i poprawki
W nowszej wersji Update Health Tools (1.1), która pojawiła się w grudniu 2022 roku, Microsoft zmienił mechanizm komunikacji: porzucił bezpośrednie odwołania do Azure Blob Storage na rzecz prawdziwego serwisu webowego (devicelistenerprod.microsoft.com). Ponadto stworzono nowe endpointy specyficzne dla UE – m.in. w domenach payloadprodeudbX oraz devicelistenerprod.eudb.microsoft.com.
Eye Research odkryło jednak, iż w wersji 1.1 przez cały czas istnieje możliwość przywrócenia starego mechanizmu komunikacji poprzez ustawienie odpowiednich wpisów w rejestrze Windows (np. flaga UHS.ENABLEBLOBDSSCHECK = 1, a także możliwość zmiany punktu końcowego na własny).
Skala i wpływ problemu
W ciągu tygodnia po zarejestrowaniu 10 porzuconych kont blob badacze odnotowali 544 386 żądań HTTP z Update Health Tools, pochodzących od 9976 unikalnych dzierżaw Azure.
Wśród nich: 8 536 tenantów wysyłało zapytania o status „enrolled”, a 3 491 tenantów (lub więcej) miało przynajmniej jedno urządzenie pobierające politykę — co przekłada się na 40 973 unikalne urządzenia w testach Eye Research.
Oczywiście nie wszystkie urządzenia korzystają z wersji 1.0 – według Eye Research ten problem dotyczy relatywnie niewielkiej części, bo wiele instancji zostało już zaktualizowanych, a część może używać flag kompatybilności.
Reakcja Microsoftu i odpowiedzialne ujawnienie
Eye Research zgłosiło problem Microsoftowi 7 lipca 2025 roku. Firma potwierdziła istnienie luki 17 lipca, a już 18 lipca badacze przepisali własność porzuconych kont Azure z powrotem na Microsoft. Dzięki temu zagrożenie zostało znacząco zredukowane — kontrola nad punktami końcowymi umożliwiającymi potencjalny atak wróciła do Microsoftu.
Wnioski i zalecenia
- Ponowna kalkulacja ryzyka płynącego z zapomnianej infrastruktury
To nie tylko ataki aktywne, ale zaniedbane zasoby (np. nieużywane konta w chmurze) mogą stanowić luki. Jak zauważa Eye Research – stare, porzucone komponenty mogą stanowić „ślepe punkty” w zabezpieczeniach. - Projekty bezpiecznej architektury
Badacze rekomendują, by nie usuwać w pełni kont Azure powiązanych z oprogramowaniem, ale ograniczyć dostęp lub zamknąć publiczny dostęp zamiast pozwalać na rejestrację przez nieautoryzowane osoby. - Oddzielenie transportu od treści
Eye Research podkreśla, iż Microsoft mylił transport security (czyli szyfrowanie połączenia) z message security (czyli weryfikacją zawartości wiadomości). Zamiast tylko polegać na TLS/SSL, lepiej byłoby podpisywać samą zawartość (np. JSON z poleceniem ExecuteTool), co zapobiegałoby wykonywaniu nieautoryzowanego kodu — choćby jeżeli kontrola nad kontem Azure zostanie przejęta. - Uaktualnianie wersji
Organizacje powinny sprawdzić, czy ich instancje Windows Update Health Tools są zaktualizowane do wersji 1.1 lub nowszej oraz czy nie mają ustawionych rejestrów, które celowo włączają stary, podatny tryb działania.
Podsumowanie
Luka w Windows Update Health Tools pokazuje, iż choćby narzędzia o wysokim zaufaniu — dystrybuowane i podpisywane przez sam Microsoft — mogą być wykorzystane do ataku, jeżeli ich infrastruktura jest źle zarządzana. Odkrycie Eye Research to przypomnienie, iż infrastrukturę chmurową należy monitorować również po jej „dezaktywacji” i iż bezpieczny projekt systemu wymaga ciągłej uwagi na zależności i mechanizmy komunikacji.
