A co z Windows Update? Jak ufać aktualizacjom po drace z SolarWinds

Reuters donosi, że seria włamań do systemów informatycznych ma ciąg dalszy. Powołując się na "anonimowe źródła" (people familiar with the matter, czyli niezawodny od lat plot device dla wiadomości z kiepskimi źródłami), reporterzy informują o wykorzystaniu przejętego oprogramowania, potencjalnie właśnie SolarWinds, do zdobycia dostępu do wewnętrznych zasobów firmy Microsoft. Oj.

Pierwszą myślą w takim przypadku nie powinno być "dlaczego Microsoft korzysta z SolarWinds zamiast z czegoś własnego?", bo to akurat jest normalną praktyką w branży. Ważniejsze pytanie to kwestia, co się stanie, gdy przestępcy wstrzykną złośliwą aktualizację do Windows Update.

W jaki sposób system "wie", że pobiera aktualizację, a nie wirusa? Istnieje kilka warstw zabezpieczeń. Źródłem pobieranych paczek musi być domena należąca do Microsoftu. Windows Defender pilnuje, by systemowy plik HOSTS nie zawierał przekierowań owych domen na podstawione fałszywki. Jeżeli jednak nawet uda się skłonić komputer do połączenia z cudzym serwerem, połączenie jest chronione certyfikatem.

Oczekiwana jest zgodność certyfikatu z adresem wystawcy. Nawet jeżeli "fejkowy" serwer przedstawi się certyfikatem i utworzy połączenie szyfrowane, Windows będzie oczekiwać konkretnego certyfikatu, a nie dowolnego.

Wreszcie, pozostaje kwestia rozproszenia procesu. Klient Windows Update pyta odmienne serwery/usługi, by otrzymać listę dostępnych aktualizacji, poznać ich sumy kontrolne oraz pobrać same pliki łatek. A więc aby podesłać komuś podstawioną aktualizację, trzeba by przejąć domenę, certyfikat oraz postawić kilka udawanych web service'ów. A pobrana paczka i tak by się nie zaktualizowała, bo nie byłaby podpisana...

Z tym, że SolarWinds rozesłał swoim klientom właśnie podpisane aktualizacje! Zainfekowano je po zbudowaniu, ale przed podpisaniem. Gdyby Microsoft padł ofiarą takiego przestępstwa, nasze klienty Windows Update pobrałyby automatycznie taką aktualizację bez żadnego marudzenia.

Musimy jednak pamiętać, że nie da się w taki sposób po prostu dostarczyć komuś uniwersalnego backdoora. Wprowadzenie zauważalnej dziury, a następnie wykorzystanie jej, zaczęłoby być wykrywane przez infrastrukturę sieciową. Złośliwe oprogramowanie podrzucone w taki sposób musi być więc subtelne i złożone, przez co (prawdopodobnie) nieprzeznaczone do uniwersalnego wykorzystania.

Pojawią się zapewne oświecone głosy, że aktualizacje należy wobec tego wyłączyć. Choć zazwyczaj ich autorów nie da się edukować, mimo to warto wspomnieć kolejny raz, że niniejszy pogląd łatwo podważyć.

Przede wszystkim, zakłada on obecność (najwyraźniej magicznego) momentu, w którym oprogramowanie przestaje być godne zaufania. Czyli na przykład wersja 19042.0, wydana jako nowy produkt, jest "w porządku", ale już 19042.365, wysyłane w ramach aktualizacji automatycznych – nie, ponieważ "już coś kombinują". To nonsens, zwłaszcza że zawsze pierwsza wersja czegokolwiek po prostu nie nadaje się do użytku.

Poza tym, wybranie sobie, że to akurat aktualizacjom nie będzie się ufać, to rozumowanie zawieszone w próżni. Bowiem jeżeli ktoś zdobył możliwość podpisywania złośliwego kodu sygnaturą dla aktualizacji, to znaczy że ma dostęp do klucza prywatnego dla rdzennego certyfikatu Microsoftu.

W takiej sytuacji należy się przede wszystkim martwić do Azure, a nie o końcówki, w postaci stacji roboczych z Windows. Integralność chmury oraz usług cyfrowych to cenniejszy skarb niż lokalne instalacje Windows 10.

Niestety, komuś trzeba ufać, co w przypadku Microsoftu oznacza pokładanie zaufania w Windows Update oraz pęku certyfikatów z Redmond. Nie jest to oczywiście zaufanie obowiązkowe. Ale jeżeli chce się naprawdę podchodzić nieufnie do tej kwestii, należałoby... kompletnie zrezygnować ze wszystkich produktów Microsoftu, ale także z usług wszystkich firm, które hostują swoje rozwiązania w chmurze Azure. Całkiem możliwe, że dziś jest to niewykonalne.

Więc nie wyłączajmy aktualizacji. Nie podwyższa to bezpieczeństwa. Żadną miarą.