Q&A: bezpieczeństwo WiFi

Czasami ktoś się coś o mnie pyta. Tym razem dostałem od Mateusza następujące pytanie (fragment):

Podłaczając się do sieci wi-fi (budżetowy, domowy routerek np. D-Link, Linksys). Czy jest możliwe podsłuchanie ruchu https? Rozumiem, że można przeprowadzić atak ARP Spoofing, ale w takim przypadky przy wejściu na stronę zabezpieczoną https, otrzymam komunikat o 'problemie' z certyfikatem. A czy istnieją sztuczki, które pozwolą taki ruch (https) przechwycić i odczytać zawartość, bez powiadamiania użytkownika o problemie z certyfikatem?

Tu są co najmniej dwa tematy. Bezpieczeństwo wifi i bezpieczeństwo HTTPS.

Trochę o WiFi

Jeśli chodzi o wifi, to niezależnie od tego, czy jest to publiczny hotspot, czy też nasz własny AP, proponuję przyjąć założenie, że ktoś może słuchać. Nawet więcej – załóżmy, że nasz intruz jest w stanie przeprowadzić atak aktywny, dlaczego ma się ograniczać wyłącznie do ataku pasywnego? W pytaniu wspomniany jest ARP Spoofing, ale równie dobrze może to być “podstawiony” serwer DHCP, który poda podłączającemu się urządzeniu delikatnie zmodyfikowaną konfigurację sieci, na przykład “własny” serwer DNS, inną adresację i routing, konfigurację serwera proxy (przez WPAD, patrz: Czy WPAD może się przydać malware?).

Tu pozwolę sobie na małą dygresję. Szczerze mówiąc nie przywiązuję wielkiej uwagi do tego, jak moje dane są przekazywane między moim komputerem i pierwszym urządzeniem w sieci. Po prostu zwykle nie wiem jak moje pakiety są traktowane na kolejnych hopach. To, że moje WiFi jest dobrze zabezpieczone wcale nie znaczy, że będąc podłączonym do tej sieci mogę się bezpiecznie logować do jakichś usług z wykorzystaniem HTTP, a jak jestem w innej (publicznej) sieci, korzystam tylko z HTTPS.

Można iść dalej z tą paranoją, a bliżej jeśli chodzi o topologię sieci. Ostatnio pisałem o wykorzystaniu iSCSI w przypadku domowego NAS. Akurat w tym konkretnym przypadku korzystałem z kabla (jednak jest to szybsze, niż WiFi), ale w ogólnym przypadku można spodziewać się, że dostęp do NAS odbywa się po WiFi. Nie do końca jest ważne z wykorzystaniem jakiego protokołu NAS udostępnia swoje zasoby (iSCSI, CIFS, FTP) – zawartość przesyłanych plików podróżuje sobie w formie jawnej. Można co prawda spróbować skonfigurować dodatkowo IPSec, oczywiście o ile posiadany NAS taką funkcję wspiera.

Co prawda jeśli korzysta się z WPA2, sieć ma mocne hasło a jej nazwa jest niestandardowa (nazwa sieci pełni rolę soli przy przekształcaniu hasła, dla WiFi też są rainbow tables), szansa na to, że ktoś obcy dostanie się do naszej sieci jest niewielka. Czasami jednak trafiają się takie kwiatki: Miliony domowych routerów Wi-Fi podatnych na atak.

Jeśli ktoś myśli, że wprowadzenie filtrowania po adresach MAC podnosi bezpieczeństwo, jest w błędzie. Adres MAC można zmienić, nie nadaje się więc on jako cecha klienta, którą można wykorzystać do potwierdzenia jego autentyczności. Zamiast tego można skorzystać z 802.1x, o ile nasz AP na to pozwala, ale to już trochę inny temat.

Trochę o HTTPS (SSL)

Załóżmy teraz, że już w naszej (nie koniecznie bezprzewodowej) sieci mamy intruza, który może nas nie tylko podsłuchiwać, ale również aktywnie ingerować w ruch. Czy SSL może nam tutaj pomóc? W pewnym stopniu tak, bo:

SSL jest skomplikowanym protokołem i przy jego wykorzystaniu można popełnić wiele błędów, które bezpieczeństwo całego rozwiązania obniżą. Na przykład:

Czy można w jakiś sposób podsłuchać komunikację HTTPS w taki sposób, by użytkownik nie był tego świadomy? Oczywiście, na kilka sposobów.

Pierwsze pytanie – po co mam się męczyć i próbować podsłuchiwać ruch HTTPS, skoro mogę przekonać użytkownika, by zamiast tego skorzystał ze zwykłego HTTP? Tak robi na przykład sslstrip. Różnica w GUI przeglądarki między połączeniem HTTPS i HTTP może być dla użytkownika mniej zauważalna, niż komunikat o nieprawidłowym certyfikacie. I nie, taki atak wcale nie jest możliwy tylko wtedy, gdy serwis jest dostępny również po HTTP. Pamiętajmy, że atakujący jest “w środku”, więc dla swojej ofiary może wystawić wersję HTTP serwisu, do właściwego serwera atakujący odwoływać się będzie już z wykorzystaniem HTTPS.

Jednym z potencjalnych rozwiązań tego problemu jest nagłówek HTTP Strict Transport Security, który mówi przeglądarce, że dana strona powinna być oglądana wyłącznie z wykorzystaniem HTTPS, przynajmniej przez określony, podany w nagłówku, czas. Trzeba tylko pamiętać, że to ma szansę zadziałać tylko wtedy, gdy przed atakiem klient był na tej stronie. No, prawie. Jest jeszcze coś takiego jak HSTS preloading, ale to już jest cecha przeglądarki.

Kolejnym problemem jest zachowanie urzędów certyfikacji, które dość dobrze opisane jest tutaj: Trustwave announces name change: henceforth will simply be 'Wave' . Ogólnie chodzi o to, by zdobyć certyfikat, który przez przeglądarkę klienta zostanie uznany za prawidłowy. Można to zrobić na przykład przez:

Tu przy okazji warto wspomnieć o Public key pinning. W tym wypadku atakującemu nie wystarczy posiadania certyfikatu, który powinien się zweryfikować poprawnie w przeglądarce ofiary. Przeglądarka ofiary sprawdzi jeszcze, czy certyfikat ten jest zgodny z tym certyfikatem, którego się spodziewała. To tak, jak było w przypadku SSH i key fingerprints , choć tam akurat całej otoczki PKI nie było (przynajmniej w typowym przypadku).

Ten fragment bynajmniej nie wyczerpuje tematu. Atakujący może próbować, że certyfikat jest prawidłowy, również na inne sposoby. Tak robił ostatnimi czasy między innymi słynny Flame: Flame, certificates, collisions. Oh my., Flame malware collision attack explained.

Trochę jeszcze o czym innym

Wcale nie jest powiedziane, że atakujący musi atakować ruch sieciowy, by widzieć co jest w środku. Może zaatakować aplikację. Dobrze nadaje się do tego XSS, a jego wprowadzenie przez atakującego może być możliwe przez:

Ten ostatni przypadek jest dość interesujący. Pamiętajmy, że obecnie aplikacje webowe to często mieszanina różnych komponentów pochodzących z różnych źródeł (skrypty statystyk, gadżety społecznościowe, itp.). Zgodnie z Transport Layer Protection Cheat Sheet nie należy mieszać ze sobą treści pobieranych po HTTP i HTTPS (patrz: 2.5.5 Rule – Do Not Mix TLS and Non-TLS Content). Jeśli jednak jakikolwiek “gadżet” pobierany jest przez HTTP, atakujący w trywialny sposób może go zmodyfikować i wstrzyknąć tam swój kod. Ten scenariusz ma jednak pewien słaby punkt – przeglądarki ostrzegają użytkownika, że część zasobów na stronie jest pobierana po HTTP i domyślnie nie są one używane. Oczywiście użytkownik może się na to zgodzić... Atakujący może też zaatakować te serwery, z których dane są pobierane. W tym wypadku bezpieczeństwo samej komunikacji nie ma znaczenia.

I na zakończenie...

Na zakończenie zostawiłem sobie XSS ChEF. Jeśli atakującemu uda się wyeksploitować jakieś rozszerzenie w przeglądarce ofiary, to już nie będzie jej przeglądarka.

Proponuję pooglądać sobie filmiki demonstrujące możliwości XSS ChEF. To, czy otwarta przez ofiarę strona została dostarczona przez HTTP czy HTTPS nie ma już większego znaczenia... Samo “zainfekowanie” podatnego rozszerzenia można zrealizować w sposób niezauważalny dla użytkownika...

To jaka jest odpowiedź na pytanie:

A czy istnieją sztuczki, które pozwolą taki ruch (https) przechwycić i odczytać zawartość, bez powiadamiania użytkownika o problemie z certyfikatem?

Nie rozpisując się za bardzo, odpowiedź brzmi: oczywiście, że tak. Bój się!

Oryginał tego wpisu dostępny jest pod adresem Q&A: bezpieczeństwo WiFi

Autor: Paweł Goleń