Windows XP naprawdę dalej dostaje aktualizacje. Po prostu ich nie widać

Miesiąc temu pojawiły się aktualizacje dla systemu Windows XP, a właściwie Windows Embedded POSReady 2009, binarnie w większości zgodnego właśnie z XP. Wiadomość ta była zaskakująca z wielu powodów. Po pierwsze, obsługę techniczną dla tego systemu zakończono pięć lat temu. Po drugie, obsługę wersji 2009 zakończono w kwietniu tego roku. Mimo to, Microsoft zdecydował się wydać aktualizacje dla słabości o nazwie BlueKeep, znajdującej się w serwerze obsługi Usług Terminalowych, czyli zdalnego pulpitu Windows. W przeciwieństwie do wielu innych dziur, łatanych co miesiąc w systemach operacyjnych, BlueKeep należy do rzadkiego i cennego dla przestępców zbioru podatności niewymagających żadnej interakcji ze strony użytkownika. Wystarczy, że system ma włączone przyjmowanie połączeń Pulpitu Zdalnego i jest wpięty do sieci, a stanowi potencjalny cel dla cyberprzestępców. Gdy komputer otrzyma odpowiednio spreparowane połączenie, możliwe jest wykonanie kodu z uprawnieniami usługi (a więc bardzo wysokimi). Taka cecha dziury w zabezpieczeniach zwie się „wormable” i przypomina o najbardziej ponurych czasach w dziejach bezpieczeństwa serwerów Windows, a więc epoce robaków Sasser, Nimda, MyDoom i Blaster. Przez ostatnie lata duża część pracy inżynierów polegała na usuwaniu wad implementacyjnych, które umożliwiały istnienie dziur wykorzystywanych przez robaki tej klasy. Między innymi dlatego Windows 10 od początku nie jest podatny na atak BlueKeep.

Ale świat to nie tylko Windows 10. Mnóstwo urządzeń dalej pracuje pod kontrolą systemu Windows XP i zazwyczaj nie są to prywatne komputery ukryte za routerem tworzącym małą, zaufaną sieć LAN. Mowa raczej o dedykowanych urządzeniach specjalnego przeznaczenia, wpiętych do rozległych, nierzadko publicznych sieci. Na efekty nie będzie trzeba długo czekać. Dla przykładu, firma Sophos donosi od kilku dni, że swoją działalność rozpoczął botnet GoldBrute, masowo skanujący port 3389/tcp, wykorzystywany właśnie przez klienta usług terminalowych (RDP).

GoldBrute pracuje bardzo łagodnie, nie podejmuje agresywnych i częstych prób logowania, a na systemach, do których się dostał nie czyni szkód, a jedynie zapewnia dalszą propagację. Takie zachowanie ma zapewne uśpić czujność niektórych serwerów IDS oraz przemknąć się w niezauważony sposób przez logi. Botnet obecnie zatem jedynie rozstawia się na użytek jakichś przyszłych kampanii, które być może już zamówiono u jego operatora. Wstrząsająco wysoka popularność portu RDP, również na nowych systemach, udostępnionego w publicznych sieciach czyni takie inicjatywy opłacalnymi. Mimo, że poprawne wdrożenia serwerów Windows w ogóle nie powinny zawierać dziś nie tylko serwera zdalnego pulpitu, ale także i samego pulpitu.

Miejmy jednak na uwadze, że GoldBrute nie wykorzystuje podatności BlueKeep. Próbuje się poprawnie i „legalnie” uwierzytelnić do systemów wystawionych na publiczne pożarcie. Załatanych lub nie – jest to bez znaczenia. Co ciekawe, BlueKeep wydaje się nie być jeszcze wykorzystywany do dużych kampanii, jak niegdyś Petya. Możliwość wykorzystania RDP do ataku opisanego w CVE-2019-0708 nie jest jednak wyłącznie teoretyczna: powstały już pierwsze sieciowe nośniki payloadu aplikowanego właśnie tą metodą. Trudno orzec, czy masa krytyczna komputerów z XP uległa rozproszeniu i nie ma już sensu prowadzić kampanii celującej akurat w ten system. Biorąc jednak pod uwagę to, jaka jest dziś rola urządzeń z tym systemem i gdzie można go znaleć (co udowodniły ataki ransomware), nie należy raczej ufać kojącemu upływowi czasu.

Microsoft wydał aktualizacje dla Windows XP dlatego, że obawiał się znacznie gorszych konsekwencji, niż w przypadku ataków Petya i WannaCry. Ogłoszenie w sprawie łatanej podatności wydało również NSA, nie wspominając o NIST. Mimo powagi sytuacji, świat jeszcze się nie zawalił. A wiele stacji z XP pozostaje, podejrzewam, niezałatanych. Aktualizacja dla XP była jednak wyjątkiem, publikowanym przy naprawdę poważnych problemach. Nie należało oczekiwać, że poza BlueKeep, powstanie więcej łatek. Takie było też zdanie komentatorów, podkreślających, że nie należy zakładać, że Microsoft będzie łatać wszelkie przyszłe podatności w XP, nawet jeżeli będą stanowić zbliżone zagrożenie.

Tymczasem nadszedł czerwiec, a następnie czerwcowy Patch Tuesday. Swoje aktualizacje otrzymał Office, Exchange, Windows Server, wszystkie miliard wersji Windows 10, Windows 7 i 8.1 oraz... Windows XP. Najwyraźniej. Jak można przeczytać na niezastąpionym Forum MSFN, klient usługi Windows Update, po przeprowadzeniu skanowania maszyny z Windows XP zaoferował nową, czerwcową aktualizację. Co więcej, wspomniana aktualizacja była również możliwa do odnalezienia z poziomu pola wyszukiwania Katalogu Windows Update. Aktualizacja KB4501226, opisana w stosownym dokumencie Knowledge Base dotyczy dostrojenia zakresu stref czasowych dla terenu Autonomii Palestyńskiej. Wydanie tej aktualizacji jest zdumiewającym aktem, z wielu różnych powodów, z których wszystkie warto przytoczyć.

Przede wszystkim, to nie jest aktualizacja dla Windows XP. To aktualizacja dla POSReady, więc można zakładać (acz są to czyste spekulacje), że być może nie pochodzi ona z legendarnego, płatnego i owianego tajemnicą programu aktualizacji zamawianych specjalnie dla XP przez instytucje rządowe i jednostki specjalizowane. Program ten, a także stosowne umowy, niewątpliwie istnieje, podobnie, jak istniał dla systemu Windows 2000. Jednak nigdy nie nastąpił z niego „wyciek” – zapewne dlatego, że upublicznienie aktualizacji (z racji skromnego zasięgu programu) prędko poskutkowałoby zlokalizowaniem źródła, wypowiedzeniem umowy i zapewne dotkliwymi karami. Z drugiej strony możliwe, że aktualizacje dla rządowego XP są po prostu oznaczane jako pakiety dla POSReady siłą inercji. Po prostu dokonano rebrandu i w zasadzie nie ma powodu, by odwracać konwencje nazewnicze w zależności od daty.

Ale w sumie dlaczego wydano aktualizację dla stref czasowych, a nie dla którejś z dziur łatanych czerwcowymi patchami? MSRC informuje, że w tym miesiącu załatano 35 podatności CVE! Czyżby żadna z nich akurat nie mapowała się na XP? To dość wątpliwe. Dlaczego więc strefy czasowe są takie ważne? Co sprawia, że najwyraźniej można je klasyfikować jako aktualizację krytyczną?

Wynika to z profilu zastosowań dzisiejszych maszyn z XP. O ile na domowym komputerze błędna godzina może wywoływać marginalne i łatwe do przegapienia problemy, w systemach typu „mission critical” jest to bardzo ważna zmienna. Wiele operacji wymaga poprawnej znajomości czasu, a przesunięcie go o godzinę w złą stronę może wywołać dość drogie konsekwencje. Stąd też biorąc pod uwagę miejsca, gdzie ostał się XP, poprawny czas istotnie może być aktualizacją krytyczną.

Alternatywne wytłumaczenie jest ciekawsze. Dostarcza je wieloletnia strategia obsługi technicznej, ujęta w dokumencie Microsoft Lifecycle Policy, zanim została zastąpiona przez tzw. Modern Lifecycle Policy dla systemów dostarczanych jako usługa. Wedle klasycznych reguł wsparcia technicznego, każda wersja systemu Windows jest serwisowana przez pięć lat aktualizacji jakościowych i nowych funkcji, a następnie przez pięć lat samych aktualizacji krytycznych. Polityka ta uległa z biegiem czasu dewaluacji i jest pełna wyjątków. Windows 7 dalej dziś otrzymuje osobno aktualizacje funkcji oraz zabezpieczeń, mimo że tych pierwszych nie powinno już być. A system Windows XP był obsługiwany znacznie dłużej, niż 10 lat. Faktem jest jednak, że wraz z upływem czasu, Microsoft zapewnia coraz mniej aktualizacji, zamiast tego serwując rosnącą liczbę wymówek, by tylko nie podejmować trudniejszych wyzwań.

Wedle ortodoksyjnej interpretacji wytycznych Lifecycle, Windows XP naprawdę powinien już otrzymywać wyłącznie najważniejsze aktualizacje, a strefy czasowe można sobie podarować. Być może jednak to rzadkie, płatne wsparcie rządzi się zupełnie innymi prawami i wciąż istnieje skromna grupa odbiorców, która otrzymuje takie aktualizacje, jakie tylko zechce. Możliwe, że liczba wciąż wydawanych łatek dla XP jest znacznie większa, a my po prostu nie możemy ich zobaczyć. Powstaje zatem pytanie, czy kiedykolwiek uda nam się dopaść owe aktualizacje albo chociaż poznać ich spis? Szanse na to są zdumiewająco niskie, a za dowód niech służy to, że nie otrzymaliśmy takiego spisu dla systemu Windows 2000, ale w międzyczasie wykradziono... kod źródłowy owego systemu, w dość znacznej części.

Jest jednak więcej rzeczy, które nie pasują w tej historii. Zgodnie z niedawnym ogłoszeniem, cała infrastruktura Windows Update v6 ma zostać wyłączona w lipcu. Podobnie, jak niegdyś wyłączono wersję dla systemów Windows 98/Me (v4) oraz Windows 95 (staticW95). Oznacza to, że stare wersje Agenta Windows Update nie będą umiały „dodzwonić się” do katalogu aktualizacji, a dawna strona internetowa update.microsoft.com, wymagająca zresztą obsługi ActiveX, przestanie serwować treść. Systemy Windows Vista i nowsze korzystają bowiem z zupełnie innej infrastruktury aktualizacji, zarówno po stronie klienta, jak i serwera.

Po co więc wydawać aktualizację dla nikogo, publikując ją na serwerze, który zaraz ma zostać wyłączony? Link do KB4501226 dalej działa, ale nie zaoferuje jej już ani Windows Update ani Katalog. Ale jest ona wciąż dostępna na serwerach będących zapleczem WU. Owszem, zbiór aktualizacji dostępnych do pobrania wydaje się być niemal losowy, znikają z niego rzeczy nowe i potrzebne, gdy starocie dalej tam leżą, ale nowsze aktualizacje rządzą się już nieco bardziej logicznymi prawami. Być może zatem Windows Update v4 wcale nie będzie wyłączone, a jedynie dostępne przez VPN? Gdyby tak było, i gdyby same nowe aktualizacje dalej leżały na serwerach Katalogu, wystarczyłoby znać do nich URL...

Niestety, to trudne. Adres aktualizacji zawiera sumę kontrolną (40 znaków), co uniemożliwia zgadywanie. A listowanie zawartości folderu jest zablokowane po stronie serwera. Więc cokolwiek leży w katalogu „d/msdownload/update/software/uprl/2019/06”, raczej nie dotrzemy do tego metodą zgadywanki.

Wreszcie, jest ostatnie wytłumaczenie. Pozornie niemożliwe. Otóż możliwe, że aktualizacja powstała przez przypadek. Po prostu odpalono job kompilujący plik stref czasowych, zaznaczono w nim o jeden tick za dużo, a serwer buildowy wypluł paczkę formacie dla Windows XP i wciągnął ją do WSUS. W dobie zaawansowanych narzędzi do ciągłej integracji i zautomatyzowanych wydań oprogramowania, stworzenie paczki siłą rozpędu jest wbrew pozorom całkiem możliwe. Jeżeli to jednak była pomyłka, za miesiąc zapewne już do niej nie dojdzie. I jeżeli wciąż jednak powstają łatki dla Windows XP, raczej się o nich nie dowiemy.