Artykuł pochodzi z wydania: Styczeń 2025
Unikanie korzystania z publicznych sieci Wi-Fi to jedna z najczęściej powtarzanych porad bezpieczeństwa, mająca uchronić nas przed atakami typu man in the middle. Jednak czy w 2025 r., gdy w naszym przekonaniu cały ruch internetowy jest szyfrowany, zatem niemożliwy do podsłuchania i zmanipulowania, ataki z „człowiekiem pośrodku” wciąż są aktualne i stanowią zagrożenie?
Zagrożenia związane z techniką man in the middle (MITM) wielokrotnie były omawiane w naszych artykułach, jednak zawsze jako środek do osiągnięcia celu – czy to w kontekście ataków mobilnych, włamań do sieci bezprzewodowych, czy jako sposób na obejście MFA. Wielokrotnie podkreślaliśmy, że technika ta pozwala na przejęcie i modyfikowanie komunikacji między ofiarą a jej celem, dając napastnikowi pełną kontrolę nad ruchem sieciowym. W temacie numeru tego wydania „IT Professional” postanowiliśmy skupić się na istocie MITM – przeanalizujemy jego strukturę oraz omówimy technikę ARP spoofingu, która często służy do realizacji ataków tego typu w sieciach lokalnych. Wyjaśnimy, w jaki sposób MITM umożliwia manipulację komunikacją ofiary z internetem, przedstawimy kluczowe mechanizmy tego ataku oraz zaprezentujemy, jakie kroki mogą podjąć administratorzy, aby zminimalizować ryzyko.
> SZYBKI DORKING
Gdy ruch internetowy nie był szyfrowany i opierał się na protokole HTTP, ataki typu MITM – w tym ARP spoofing i DNS spoofing – stanowiły realne zagrożenie. To m.in. dlatego korzystanie z publicznych sieci Wi-Fi było uważane za niebezpieczne i przed nim ostrzegano. Protokół HTTP nie został zaprojektowany z myślą o bezpieczeństwie. W czasach, gdy powstawały jego pierwsze wersje, sieci komputerowe były wykorzystywane głównie przez ośrodki naukowe oraz wąskie grono badaczy. Wprowadzenie szyfrowania SSL oraz protokołu HTTPS sprawiło, że wiele osób nabrało przekonania, iż są już w pełni chronione, a co za tym idzie również ich komunikacja. Protokoły te faktycznie znacząco poprawiły bezpieczeństwo użytkowników, jednak w rzeczywistości wciąż nie cały ruch sieciowy jest szyfrowany – w dalszym ciągu istnieją luki, które mogą być wykorzystane przez cyberprzestępców.
Proste wyszukiwanie w internecie z wykorzystaniem techniki zwanej Google Dorking pozwala na znalezienie za pomocą wyszukiwarki takich niezabezpieczonych witryn poprzez tworzenie specyficznych zapytań, jak np.: inurl:. pl+login -inurl:https. Za ich pośrednictwem wylistujemy witryny, które zawierają słowo „login” w adresie URL, ale nie korzystają z HTTPS-u. Mimo powszechności protokołu wyszukiwanie zwraca miliony wyników. Oczywiście nie oznacza to, że faktycznie wszystkie te strony są niezabezpieczone, bo część z nich ma stałe przekierowanie (redirect 301) na stronę zabezpieczoną, jednak wiele pozwala na logowanie bez odpowiednich zabezpieczeń. Wśród takich adresów można znaleźć zarówno witryny małych i dużych firm, jak i serwisy rządowe, przedstawicieli służby zdrowia czy edukacji. Choć nowoczesne przeglądarki internetowe informują o braku szyfrowania i ostrzegają przed potencjalnym ryzykiem, mniej świadomi użytkownicy często ignorują te sygnały. Owszem, HTTPS sprawił, że korzystanie z publicznych sieci Wi-Fi jest bezpieczniejsze niż kiedyś, ale z pewnością nie można uznać go za całkowicie pewne rozwiązanie. Nie będziemy się jednak skupiać na samych sieciach i metodach ich ataków, bo to omówiliśmy w cyklu poświęconym bezpieczeństwu sieci Wi-Fi („IT Professional” 7–8/2024, s. 91, „IT Professional” 9/2024, s. 8). Teraz skupimy się na „człowieku w środku”, bo, jak wiadomo, to nie sieci same w sobie stanowią zagrożenie, ale intruz ze złośliwymi zamiarami.
> PROTOKÓŁ ARP
Gdy jedno urządzenie chce skomunikować się z innym w sieci LAN, musi najpierw poznać adres MAC docelowej maszyny, ponieważ to właśnie na jego podstawie dostarczane są pakiety na poziomie warstwy łącza danych. Aby uzyskać adres MAC, używa się protokołu rozpoznawania adresów (Address Resolution Protocol, ARP). Protokół ARP jest ważnym elementem działania sieci lokalnych (LAN), ponieważ mapuje adresy logiczne (IP) z warstwy sieciowej (L3) na adresy fizyczne (MAC) z warstwy łącza danych (L2). Proces ten polega na wysyłaniu zapytań ARP (ARP request) do sieci i oczekiwaniu na odpowiedź z adresem MAC urządzenia docelowego.
Kiedy urządzenie (host A) chce wysłać pakiet IP do innego urządzenia (host B) w sieci lokalnej, sprawdza w swoim cache’u ARP, czy ma już adres MAC odpowiadający adresowi IP docelowego hosta (hosta B). Jeśli adres MAC nie jest znany (brak go w ARP cache), host A wysyła ARP request na adres rozgłoszeniowy sieci (broadcast) z pytaniem: „Jaki jest adres MAC hosta o adresie IP X?”. W zapytaniu tym adres MAC nadawcy ma postać adresu rozgłoszeniowego ff:ff:ff:ff:ff:ff, co oznacza, że zostanie ono odebrane przez wszystkie karty sieciowe w sieci Ethernet. W treści zapytania zawarty jest adres IP hosta, którego adresu MAC szukamy (host B). Każde urządzenie sprawdza, czy adres z requestu ARP jest jego własnym IP. Jeśli tak, host B odpowiada, a jeśli nie, ignoruje to wywołanie.
Host B, którego adres IP odpowiada zapytaniu, wysyła ARP reply – odpowiedź skierowaną tylko do hosta A (unicast), zawierającą jego własny adres MAC. W ARP reply znajduje się adres MAC hosta B i adres IP, który ten adres MAC reprezentuje. Host A odbiera odpowiedź i zapisuje (cache’uje) odpowiedni adres MAC do swojego ARP cache’u. Po otrzymaniu odpowiedzi ARP host A ma już adres MAC hosta B. Może teraz wysłać pakiet danych, korzystając z tego adresu, i rozpocząć komunikację na poziomie warstwy łącza danych (Ethernet).
[…]
Adam Kamiński
Autor jest trenerem modeli AI i entuzjastą ofensywnego podejścia do cyberbezpieczeństwa.
