man-in-the-middle (MITM)

Man-in-the-middle (MITM, atak z pośrednikiem) to atak, w którym napastnik wpina się w komunikację dwóch stron i może ją podsłuchiwać albo zmieniać, podczas gdy obie strony sądzą, że łączą się bezpośrednio. MITRE w katalogu CAPEC opisuje go jako wejście atakującego w kanał komunikacji między dwoma komponentami, pozwalające obserwować lub zmieniać dane, zanim trafią do adresata ^[1]. Katalog używa dziś nazwy Adversary in the Middle (AiTM) i ocenia prawdopodobieństwo ataku jako wysokie, a typową dotkliwość jako bardzo wysoką ^[1].

Jak działa

Według OWASP atakujący dzieli pierwotne połączenie TCP na dwa nowe: jedno między klientem a sobą, drugie między sobą a serwerem ^[2]. Działa potem jak pośrednik, który może czytać, wstawiać i zmieniać dane w przechwyconej komunikacji ^[2]. Przebieg pokazuje schemat poniżej.

RYS. 1Atak man-in-the-middle

CAPEC opisuje trzy fazy: rozpoznanie sposobu komunikacji, na przykład przez podsłuch ruchu, wstawienie się w kanał jako pośrednik routujący, a na końcu obserwację, filtrowanie lub zmianę przesyłanych danych ^[1].

Szyfrowanie TLS nie wyklucza ataku, ale go utrudnia. OWASP zaznacza, że MITM przez HTTPS przebiega tak samo, z tą różnicą, że powstają dwie niezależne sesje TLS ^[2]. Przeglądarka ostrzega wtedy o niezaufanym certyfikacie, a użytkownik może ostrzeżenie zignorować ^[2]. Wyjątkiem jest sytuacja, gdy atakujący przejął certyfikat serwera albo ma certyfikat podpisany przez zaufany urząd certyfikacji z pasującą nazwą ^[2].

Odmiany

Pierwsze dwie odmiany wymagają, by atakujący był blisko ofiary w sieci, na przykład w tej samej sieci Wi-Fi; zob. zagrożenia publicznych sieci Wi-Fi i evil twin (podstawiona sieć Wi-Fi). Podobny skutek na większą skalę daje DNS cache poisoning albo BGP hijacking, które kierują ruch pod adres atakującego.

Trzecia odmiana to phishing AiTM. CERT Polska w styczniu 2019 roku opisał technikę, w której fałszywa domena pośredniczy w komunikacji z prawdziwą usługą; ofiara normalnie z niej korzysta, a atakujący przechwytuje loginy, hasła, kody drugiego składnika i dane kart ^[3]. Wiarygodność zwiększają bezpłatne certyfikaty DV ^[3]. Opisane narzędzie Modlishka automatycznie przechwytywało dane logowania i ciasteczka sesyjne oraz usuwało nagłówki bezpieczeństwa ^[3].

W WordPressie

Strona WordPress jest celem MITM głównie przez logowanie. Kto przechwyci hasło albo ciasteczko sesji administratora, dokonuje przejęcia sesji i ma pełną kontrolę nad witryną. Dokumentacja WordPressa zaleca, by sieć po obu stronach, serwera i klienta, była zaufana ^[7]. Podaje przykład: kawiarnia internetowa, z której wysyła się hasła nieszyfrowanym połączeniem, przewodowym lub bezprzewodowym, nie jest zaufaną siecią ^[7].

Podstawą jest HTTPS w całej witrynie. Stała FORCE_SSL_ADMIN w pliku wp-config.php wymusza, by wszystkie logowania i wszystkie sesje administracyjne odbywały się przez SSL ^[6]. Dokumentacja wskazuje też, że niektóre wtyczki wymagają adresu witryny z protokołem https w ustawieniach ^[6].

define( 'FORCE_SSL_ADMIN', true );

Pozostaje moment pierwszego wejścia. Jeśli użytkownik wpisze adres z http://, pierwsze żądanie idzie bez szyfrowania, zanim serwer przekieruje go na HTTPS. Tę lukę zamyka HSTS.

Zagrożenia i skutki

RFC 6797 opisuje dwie klasy napastników w sieci. Pasywny podsłuchuje nieszyfrowane połączenia bezprzewodowe i kradnie identyfikatory sesji; aktywny podszywa się pod serwery DNS albo przechwytuje połączenia, licząc, że użytkownik zignoruje ostrzeżenie o certyfikacie ^[5]. Skutki MITM to:

• kradzież haseł i tokenów sesyjnych, a dalej przejęcie konta;
• podmiana treści w locie, na przykład numeru rachunku lub linku do pobrania;
• ominięcie jednorazowych kodów, bo pośrednik przekazuje je na bieżąco ^[3].

Jak się bronić

CAPEC zaleca szyfrowanie komunikacji, na przykład SSL/TLS, podpisywanie kluczy publicznych przez urząd certyfikacji, silne wzajemne uwierzytelnianie stron i wymianę kluczy bezpiecznym kanałem ^[1].

HSTS pozwala witrynie ogłosić, że jest dostępna tylko przez bezpieczne połączenie ^[5]. RFC 6797 wskazuje jednak problem pierwszej wizyty: zanim przeglądarka pozna politykę, użytkownik może wejść pod adres http; lekarstwem są listy wstępnie wczytane do przeglądarki przez jej producenta ^[5]. Warto też ustawiać flagi ciasteczek, zwłaszcza Secure, żeby ciasteczko sesji nie wyszło nieszyfrowanym kanałem.

Przeciw phishingowi AiTM CERT Polska wskazał U2F i Web Authentication, bo uwierzytelnianie odbywa się na poziomie przeglądarki, co unieważnia atak przez serwer pośredniczący ^[3]. Dziś ten mechanizm rozwija FIDO2 / WebAuthn i passkey.

Historia i przykłady

W lipcu 2019 roku Sekurak opisał działania w Kazachstanie, gdzie operatorzy telekomunikacyjni żądali od użytkowników instalacji narodowego certyfikatu root CA na każdym urządzeniu używanym do łączenia z internetem ^[4]. Po instalacji przeglądarki uznawały certyfikat za zaufany, co pozwalało odszyfrować ruch HTTPS bez ostrzeżeń ^[4]. Sekurak nazwał to klasycznym atakiem klasy man-in-the-middle ^[4].