Zgłoś błąd
X
Zanim wyślesz zgłoszenie, upewnij się że przyczyną problemów nie jest dodatek blokujący reklamy.
Błędy w spisie treści artykułu zgłaszaj jako "błąd w TREŚCI".
Typ zgłoszenia
Treść zgłoszenia
Twój email (opcjonalnie)
Nie wypełniaj tego pola
.
Załóż konto
EnglishDeutschукраїнськийFrançaisEspañol中国

Czy Windows 10 nas szpieguje? Analiza aktywności sieciowej

Morfeusz888 | 07-09-2015 20:17 |

Analiza ruchu sieciowego podczas normalnej pracy systemu – opcje domyślne

Systemy Windows stają się dużo bardziej aktywne sieciowo kiedy zaczniemy z nich korzystać. Otwieranie aplikacji, instalowanie aktualizacji, a nawet wpisywanie fraz w wyszukiwarce sieciowej sprawia, że nagle Windows przypomina sobie o serwerach znajdujących się w Redmond, na które musi wysłać zaległe raporty. Postanowiliśmy sprawdzić, jak testowane przez nas systemy operacyjne wypadają pod tym kątem. Badanie podzieliliśmy na dwie części - aktywność systemu przy wszystkich włączonych opcjach związanych z prywatnością w oknie Ustawienia oraz wyłączonych. W przypadku Siódemki żadnych opcji nie zmienialiśmy.

Windows 7

Mający już kilka lat na karku system Microsoftu, oprócz namiętnego odpytywania serwer DNS o adresy wpad.localdomain i isatap.localdomain, a także komunikacji z serwerem czasu, nawiązuje połączenia z serwerem settings-win.data.microsoft.com (adres IP: 191.232.139.253), a więc tym samym, którego Windows 10 używał do wysyłania telemetrii. Pakiety są oczywiście również zaszyfrowane, ale tym razem za pomocą TLSv1 (nie zaś v1.2, jak to miało miejsce w najnowszych Okienkach). W zrzucie pakietów obecny był również wpis o vortex-win.data.microsoft.com (adres IP: 192.132.139.253). System ponadto z serwerów wscont.apps.microsoft.com (adres IP: 23.201.171.137) i www.download.windowsupadte.com (adres IP: 2.18.216.65) pobiera najprawdopodobniej aktualizacje (lub jakieś inne dane z nimi związane), o czym może świadczyć żądanie pliku .cab oraz duża ilość pofragmentowanych pakietów TCP występujących jeden za drugim.

Pewne podejrzenia wzbudzać mogą następujące żądania do serwera csc3-2010-crl.verisign.com (adres IP: 23.37.37.163) - jest to bowiem serwer Akamai, choć rekord CNAME odpowiedzi DNS sugeruje jakieś powiązania z firmą Symantec (crl.ws.symantec.com.edgekey.net). W odpowiedzi na żądanie przesyłany jest plik CSC-2010.crl, zawierający listę nieważnych certyfikatów, prawdopodobnie dotyczących TLS/SSL.
Kolejny podejrzany serwer? Na przykład compatexchange1.trafficmanager.net, dla którego DNS zwrócił dwa rekordy CNAME: compatexchange4.cloudapp.net (adres IP: 191.237.153.160) i compatexchange13.cloudapp.net (adres IP: 104.43.237.169). Tu wymiana danych następuje za pośrednictwem TLSv1.

Windows 8.1

W dziedzinie największej gadatliwości wśród procesów działających w systemie królem został proces svchost.exe (odpowiedzialny za uruchamianie usług). Tyczy się to nie tylko Windowsa 7, ale też Ósemki oraz, jak się później okaże, Windowsa 10. W przypadku tego drugiego systemu, nawiązuje on bardzo dużo połączeń TCP z serwerami takimi, jak:

  • bg4.v4.a.dl.ws.microsoft.com (2.18.212.81),
  • bg.v4.a.dl.ws.microsoft.com (2.18.212.91),
  • fe2.ws.microsoft.com (65.55.138.158),
  • statsfe2.update.microsoft.com.akadns.net (64.4.54.22),
  • statsfe2.ws.microsoft.com.nsatc.net (131.253.14.154),
  • c-0001.c-msedge.net (191.234.4.50).

Tam, gdzie ruch TCP poprzedzony jest żądaniami HTTP można rozszyfrować, czego mniej więcej dotyczy komunikacja. Tutaj zarejestrowaliśmy dość sporo pakietów SOAP. Zainteresowała nas zawartość jednego z nich, który wędrował do serwera o adresie 23.201.184.227. A wygląda ona mniej więcej tak:

Do Microsoftu w takim pakiecie lecą dane odnośnie m.in. wykorzystywanego w systemie języka i bliżej niezidentyfikowanych tagów XML o nazwach gdmdmid i HWIDRequests. Tego typu komunikacja miała miejsce częściej:

Podobnie, jak to miało miejsce chwilę temu, nie byliśmy w stanie rozszyfrować, czego tak naprawdę dotyczą (poza językiem) przesyłane metadane.

Proces explorer.exe, również nie jest niewinny:

Jawny dowód na wysyłanie telemetrii stanowi wermgr.exe, który łączy się z serwerem watson.telemetry.microsoft.com.nsatc.net (65.55.252.43). Zastosowanie protokołu TLS do przesyłania danych powinno wzbudzić podejrzenia co do zawartości pakietów.

Drugiego przykładu nie trzeba daleko szukać, bo występuje on pod postacią procesu WSqmCons.exe. Nawiązuje on połączenie z serwerem sqm.telemetry.microsoft.com.nsatc.net (65.55.252.93). Dane oczywiście zaszyfrowane (TLS).

Windows 10

I w końcu przyszedł czas na to, na co wszyscy czekali, a więc na analizę ruchu sieciowego podczas normalnej pracy w dzień Windowsa 10. A więc po kolei.

Jak zwykle pomijamy ruch związany z pakietami ARP, gdyż w przypadku tej analizy nie interesuje nas warstwa łącza danych (pakiety ARP są rozsyłane na adres rozgłoszeniowy tej samej sieci, co nadawca i nie wychodzą poza router), a ruch, który jest kierowany "na zewnątrz". Tym, co już na początku może nas zainteresować, to dość duża liczba połączeń z różnymi serwerami powiązanymi z Akamai. Zacznijmy analizę od e16.dspg.akamaiedge.net (23.211.162.64). Zaobserwowaliśmy sporo żądań typu:

GET /image/apps.41303.9007199266251968.d10cbd2e-9dc7-48ce-a366-c68943ce209f.45a395a3-a22d-4e52-be95-23f4770aaf62?h=150

W odpowiedzi natomiast dostawaliśmy pliki .PNG, takie, jak poniższy :)

Nazwa ta stanowi alias dla serwera microsoftowego store-images.microsoft.com. Żadnych prywatnych danych – idziemy dalej.

Jak zwykle, bardzo gadatliwym procesem jest explorer.exe, który łączył się z kolejnymi serwerami Akamai (2.18.213.113, 2.18.213.122), jednak przesyłane dane ograniczone były do żądań HTTP związanych z informacjami serializowanymi do formatu XML, które mają się wyświetlać na kafelkach, czego dowodem może być poniższy zrzut. Nowe żądania wysyłane były do serwera co 30 minut.

Dotarliśmy jednak do pierwszego podejrzanego o adresie 157.56.124.151. W przechwyconych pakietach nie ma jakichkolwiek prób rozszyfrowania tego adresu np. przez protokół DNS, dlatego można pokusić się o stwierdzenie, że został on gdzieś w systemie zakodowany na stałe. Pierwsze połączenie TLS idzie od razu na ten adres, choć co dziwne – bez wcześniejszych faz obejmujących, np. ustalenie parametrów nowego połączenia. Serwer ten należy oczywiście do Microsoftu i usytuowany jest w Dublinie (Irlandia).

Jako, że nasz testowy Windows 10 korzystał z dobrodziejstw konta internetowego Microsoftu, zarejestrowaliśmy również ruch, który był najprawdopodobniej związany z logowaniem (pakiety zarejestrowane niedługo po starcie systemu). Komputer komunikował się wtedy z serwerem o adresie 131.253.61.66, oczywiście za pośrednictwem protokołu TLS, który to adres został wcześniej rozpoznany przez usługę DNS po wysłaniu zapytania przez system o domenę login.live.com.

W systemie działał proces WinStore.Mobile.exe, będący częścią sklepu Windows Store. Należał on do najbardziej aktywnych pod względem nawiązywanych połączeń. Niemal cały ruch sieciowy między nim a serwerami zdalnymi realizowany był za pośrednictwem protokołu TLS. Serwery te to:

  • e274.dspb.akamaiedge.net (23.211.161.178)
  • bn2.collections.md.mp.microsoft.com.akadns.net (65.52.108.89),
  • xsts.auth.gtm.xboxlive.com (134.170.179.199),
  • cid-5ba36b577f205d09.users.storage.live.com (134.170.105.200),
  • user.auth.gtm.xboxlive.com (191.234.241.35).

Innym procesem, który przejawiał jakąkolwiek aktywność sieciową był backgroundTaskHost.exe. Wiemy o nim jedynie tyle, że ma on coś do czynienia z aplikacjami Metro. Łączył się natomiast z serwerami skyapi.skyprod.akadns.net (134.170.104.216) oraz 64.18.20.10. W tym pierwszym przypadku cały znaczący ruch był szyfrowany protokołem TLS. Z drugiego serwera pobierane były natomiast najprawdopodobniej listy ważności certyfikatów SSL – plik pobierany był tuż przed rozpoczęciem procesu nawiązywania właściwej komunikacji przez TLS.

OHub.exe - to kolejny niezidentyfikowany proces prowadzący konwersację tym razem z serwerami prod-w.nexus.live.com.akadns.net (191.237.218.239) oraz e-0009.e-msedge.net (191.234.5.88) za pośrednictwem TLS.

OneDrive jest po zalogowaniu się na konto Microsoftowe domyślnie aktywny. Podejrzany może się wydać ruch między hostem-nadawcą a dwoma serwerami e7502.ce.akamaiedge.net (23.37.40.70) i 131.253.61.68 - jest on realizowany bowiem przez TLS. Nic niepożądanego nie wędruje do serwera ssw.live.com.nsatc.net (207.46.7.252), natomiast ciekawie wygląda sprawa e8218.ce.akamaiedge.net (23.37.43.27). Treść przykładowego żądania HTTP wygląda następująco:

A tak wygląda odpowiedź:

Zaobserwowaliśmy jeszcze dwa procesy, które urządzają się co jakiś czas pogawędkę ze swiatem zewnętrznym w formie zaszyfrowanej. Należą do nich SearchUI.exe (komunikacja z any.edge.bing.com - 204.79.197.200) oraz SettingSyncHost.exe (komunikacja z a-0011.a-msedge.net - 204.79.197.213). Na szczególną uwagę zasługuje ten pierwszy. W drugim przypadku nazwa sugeruje, że proces ten może mieć coś wspólnego z synchronizacją ustawień konta Windows.

Nie mogło się oczywiście obyć bez rejestracji ruchu idącego na serwery:

  • vortex-db5.metron.live.nsatc.net (191.232.19.254),
  • onesettings-db5.metron.live.nsatc.net (191.232.139.253),
  • sqm.telemetry.microsoft.con.nsatc.net (65.55.252.93),
Bądź na bieżąco - obserwuj PurePC.pl na Google News
Zgłoś błąd
Liczba komentarzy: 166

Komentarze:

x Wydawca serwisu PurePC.pl informuje, że na swoich stronach www stosuje pliki cookies (tzw. ciasteczka). Kliknij zgadzam się, aby ta informacja nie pojawiała się więcej. Kliknij polityka cookies, aby dowiedzieć się więcej, w tym jak zarządzać plikami cookies za pośrednictwem swojej przeglądarki.