Czy Windows 10 nas szpieguje? Analiza aktywności sieciowej

Analiza ruchu sieciowego podczas instalacji systemów

Podczas instalacji systemu operacyjnego ciężko spodziewać się, że będzie miała miejsce jakakolwiek wychodząca z naszego komputera transmisja danych. Stwierdzenie to prawdziwe jest oczywiście tylko w przypadku, gdy tym instalowanym systemem jest któryś z rodziny Microsoft Windows. Ktoś, kto miał już do czynienia z instalacją np. dystrybucji Linuksa wie, iż często w trakcie tego procesu dociągane są dodatkowe paczki z oprogramowaniem, czy też aktualizacje. Na analizę tego, co pingwiny wysyłają do globalnej sieci, przyjdzie jeszcze czas. Póki co sprawdźmy, czy rzeczywiście systemy Microsoft Windows 7, 8.1 i 10 nie ucinają sobie miłych pogawędek z jakimiś serwerami podczas instalacji.

Windows 7

Na samym początku przyjrzyjmy się systemowi Windows 7, który w porównaniu do swoich braci w postaci Windows 8.1 oraz Windows 10 powinien (przynajmniej w teorii) prezentować się lepiej pod kątem zachowania prywatności użytkownika. A jak rzecz się ma w rzeczywistości? Otóż w początkowych fazach instalacji system nie dzieje się praktycznie nic. Ruch sieciowy wygląda jak na obrazku poniżej:

Nieco ciekawiej robi się, gdy system w trakcie instalacji, już po zainicjowaniu interfejsu sieciowego, zaczyna wysyłać do bramy komunikaty DHCP (Inform i ACK). Od tego miejsca w ruch idą protokoły DNS i LLMNR z zapytaniami o wpad.localdomain. W sumie komunikaty te nie służą niczemu konkretnemu w tej fazie "pracy" systemu - zajmują się szukaniem plików konfiguracyjnych, np. związanych z DHCP. Stwarza to oczywiście pewną furtkę do podszycia się pod serwer DHCP agresora, z czym może się wiązać w konsekwencji przechwycenie ruchu. Taki scenariusz jednak może mieć miejsce jedynie, gdy ktoś nieupoważniony wepnie się do naszej domowej sieci LAN (a więc zostanie w konsekwencji przeprowadzony atak typu man-in-the-middle). Zostawmy jednak sprawy związane z bezpieczeństwem sieciowym i lećmy dalej po ciekawostkach znajdujących się w pakietach.

Kolejnym dość interesującym zachowaniem jest odpytywanie przez DNS o adres serwera www.msftncsi.com. Po otrzymaniu odpowiedzi z jego adresem IP, system Windows wysyła żądanie GET dotyczące pliku ncsi.txt (a więc ma już miejsce komunikacja po HTTP). Po co? Ano po to, by stwierdzić, czy nam działa Internet, czy też nie (chyba każdemu znany jest wykrzyknij na ikonie połączenia sieciowego w obszarze powiadomień, jeśli coś jest pod tym względem nie tak). Teoretycznie więc nie ma się czego obawiać, bo żadne prywatne dane na serwery MS w tym momencie nie wędrują.

I w przypadku Windowsa 7 to by w zasadzie było na tyle – dalej rozpoczyna się już zaszyfrowana komunikacja po TLSv1, w której sprawdzana jest obecność aktualizacji, a następnie - ich pobieranie.

Windows 8.1

W przypadku Windowsa 8.1 ruch sieciowy podczas instalacji wygląda z grubsza podobnie do tego, co wyśledziliśmy wyżej. Są jednak pewne różnice. Przede wszystkim do wpad.localdomain i zapytań o plik ncsi.txt dochodzi połączenie z serwerem czasu time.windows.com (poprzedzone oczywiście odpowiednimi zapytaniami DNS). Po ustanowieniu połączenia dalsza wymiana danych przebiega za pośrednictwem protokołu NTP, który służy do aktualizacji czasu systemowego.

Interesujące jest też zapytanie DNS o nazwę win8.ipv6.microsoft.com, które w rezultacie zwraca adres IPv4 94.245.121.253. Nie jest jednak później nawiązywane żadne połączenie z tym adresem.

Jako, że w Windows 8/8.1 wprowadzono możliwość powiązania swojego konta użytkownika z kontem internetowym, oczywiste jest łączenie się z serwerem login.live.com w czasie konfiguracji konta użytkownika. Adresów IP, pod którymi można znaleźć tą domenę odpowiedź DNS zwraca kilka (131.253.61.68, 131.253.61.82, 131.253.61.84, 131.253.6196), po czym następuje nawiązanie szyfrowanego połączenia za pośrednictwem protokołu TLSv1.2 (a więc w wyższej wersji niż miało to miejsce w przypadku aktualizacji Windows 7).

Dalej mamy adres ctldl.windowsupdate.com, który wbrew pozorom nie jest związany z aktualizacjami systemu, ale z aktualizacjami certyfikatów TLS. Z racji tego, że po tej operacji następuje pobieranie/weryfikacja certyfikatów (domena ocsp.verisign.com), ustalenie konfiguracji połączenia TLSv1.2 oraz dość długi ciąg zaszyfrowanych danych można wysnuć podejrzenie, że operacje te są również związane z samym logowaniem do konta "live".
Nie wzbudzają podejrzeń ostatnie żądania, jakich można się doszukać w przechwyconych pakietach, związane z aktualizacjami informacji umieszczonych na domyślnych kafelkach (takich, jak informacje o pogodzie, finansach czy wiadomościach).

Windows 10

Podobna sytuacja, jak w Windows 8.1. Podczas instalacji pojawiają się żądania wysyłane do dokładnie tych samych serwerów, choć z nielicznymi wyjątkami. Większość komunikacji odbywa się za pośrednictwem protokołu TLSv1.2, zatem nie byliśmy w stanie rozszyfrować, jakie dane są na te serwery przesyłane. Wiemy natomiast, że połączenia były ustanawiane m.in. z następującymi serwerami:

• 131.253.61.82 - wcześniej do tego serwera wędrowało żądanie HTTP GET pliku ppcrlcheck.srf (pochodzące od svchost.exe),
• 65.55.138.111 - serwer Microsoftu stacjonujący w Indiach, na którym prawdopodobnie hostowane są pakiety aktualizacji Windows (adres sls.update.microsoft.com),
• m.in. 191.234.72.168 - fe2.update.microsoft.com - j.w.
• 191.232.139.253

Ten ostatni adres jest adresem... ciekawym. Mieści się pod nim serwer settings-win.data.microsoft.com, który wraz z serwerami v10.vortex-win.data.metron.live.com.nsatc.net, vortex.data.glbdns2.microsoft.com, vortex-db5.metron.live.com.nsatc.net należy do grupy serwerów hostujących usługi zarządzające, jak to określa sam Microsoft "Customer experience and diagnostic telemetry" (źródło). A więc telemetria pełną gębą. To samo dzieje się w przypadku wcześniejszych wersji Windowsa (od 7 wzwyż), ale później - nie w czasie instalacji. Bardzo interesujący jest fakt, co znajduje się w pakietach skierowanych do tych serwerów. Gdyby nie to, że są one zaszyfrowane, chętnie poznalibyśmy ich zawartość. Microsoft zapewnia jednak, że nie zbiera on żadnych naszych prywatnych danych, takich jak np. dane kontaktowe. Microsoft nie bez powodu jednak zdecydował się na zastosowanie komunikacji przez TLS, zamiast tradycyjnego HTTP - z pewnością w pakietach tych wędrują do Microsoftu jakieś dane, które mogą zostać w jakiś sposób z nami powiązane.

Tworzone są jeszcze inne połączenia, jak np. z serwerem licensing.md.mp.microsoft.com powiązanym z Akamai Technologies (to, ze względu na imponującą liczbę nawiązywanych połączeń, a także i tych nagle zrywanych powinno zasługiwać na osobną publikację) czy geo-prod.dodsp.mp.microsoft.com. Oczywiście, do środka pakietów zajrzeć nie sposób - wszystko szyfrowane za pomocą TLSv1.2. Jako, że ten ostatni podobnie, jak wcześniejsze, leży w domenie nsatc.net można spodziewać się, że również bierze czynny udział w zbieraniu pewnego rodzaju telemetrii. Inny serwer? Proszę bardzo – prod.dodsp.mp.microsoft.com.nsatc.net.
Jak widać, im nowsza wersja systemu Microsoft Windows, tym bardziej "gadatliwa". Wydawać by się mogło, że podczas instalacji OSa nic nie ma prawa komunikować się ze światem zewnętrznym - przecież nie dostajemy na ten temat żadnych widocznych informacji! Trzeba przyznać, że sami byliśmy zaskoczeni tym faktem podczas analizy pakietów, jednak to dopiero początek zabawy.

• « pierwsza
• ‹ poprzednia
• 1
• 2
• 3
• 4
• 5
• 6
• 7
• 8
• 9
• następna ›
• ostatnia »