Ataki Man in the Middle

0

Ataki Man in the Middle (w skrócie MITM) stanowią zagrożenie dla każdej, nawet szyfrowanej komunikacji typu klient – serwer. Koncepcja tego ataku przewiduje podsłuch i przejęcie połączenia, nawet w przypadku braku możliwości złamania stosowanego przez strony komunikacji algorytmu szyfrowania. Szczególnie częstym przedmiotem ataków MITM są szyfrowane sesje SSH (Secure Shell) i SSL (Secure Sockets Layer), które służą do przesyłania często bardzo istotnych i poufnych informacji.

Szyfrowanie komunikacji za pomocą SSL jest obecnie najpowszechniejszą metodą nawiązywania bezpiecznego połączenia pomiędzy klientem a serwerem. SSL jest podstawową techniką „bezpiecznej komunikacji” stosowaną w Internecie, m.in. w handlu i bankowości elektronicznej.

SSL, w którym można w zasadzie tunelować transmisję dowolnego rodzaju, jest rodzajem komunikacji szyfrowanej. Stosowane w nim mechanizmy kryptograficzne są stosunkowo pewne – pod warunkiem, że używasz 128- lub więcej bitowego klucza. SSL należy (podobnie jak SSH) do technologii korzystających z dobrodziejstw szyfrowania asymetrycznego. Bezpieczeństwo komunikacji przez SSL zależy od relacji zaufania między stronami komunikacji oraz, ewentualnie, trzecią stroną dokonującą poświadczenia tożsamości stron nawiązujących połączenie.

Specyficzne dla połączeń SSL w Internecie (dla celów handlu elektronicznego) jest to, że tylko przeglądarka (klient) jest „zainteresowana” uwierzytelnieniem serwera przed powierzeniem mu tajnych danych (np. podczas logowania na stronę transakcyjną w banku internetowym). Taka jednostronna identyfikacja zazwyczaj także wystarcza do odbioru klucza, przeznaczonego do szyfrowania transmitowanych informacji. Serwer w tym momencie przekazuje przeglądarce swój certyfikat poświadczony przez zaufaną trzecią stronę (Certificate Authority). Do weryfikacji poświadczenia i „wyłuskania” z niego klucza sesyjnego (tj. służącego do szyfrowania transmisji w kierunku serwera) klient wykorzystuje klucz publiczny ośrodka certyfikacyjnego. W chwili wymiany danych poświadczających otwiera się krytyczny moment transmisji SSL, szczególnie podatny na tak MITM.

Jednym ze składników SSL jest protokół uzgodnień SSLHP (SSL Handshake Protocol), który świadczy usługi identyfikacyjne i negocjuje metodę szyfrowania. Drugim ważnym elementem SSL jest protokół rejestracji SSLRP (SSL Record Protocol), który odpowiada za pakowanie danych, tak aby mogły być efektywniej szyfrowane. Pierwszy z omawianych protokołów pracuje w warstwie aplikacji, a drugi w warstwie prezentacji stosu protokołów OSI.

Mechanizm ataku Man-in-the-Middle
Ataki Man-in-the-Middle często wykorzystują luki w oprogramowaniu. Przykładem jest luka w przeglądarce IE, które powoduje, że program ten nie wykrywa błędów w ścieżce poświadczenia certyfikatu X509 (standard opisujący format certyfikatów cyfrowych stosowanych w kryptografii asymetrycznej), czyli certyfikatu serwera SSL. Powyższa luka pozwala atakującemu dokonać ataku MITM poprzez wstawienie do ścieżki certyfikującej własnego certyfikatu. W efekcie ofiarą może stać się każdy użytkownik łączący się za pomocą IE z serwerem korzystającym z SSL.

Atak na ścieżkę certyfikacji nie jest procesem prostym. Wymaga on od atakującego dużej wiedzy i uporu i odpowiedniego doboru ofiary. Pamiętaj – atak nie powiedzie się, jeśli zainstalujesz najnowsze łaty na Internet Explorera.

Atak krok po kroku
Prześledźmy punkt po punkcie, czego potrzebuje napastnik do przeprowadzenia skutecznego ataku MITM na sesję SSL.

  1. Fałszywe żądanie poświadczenia certyfikatu serwera (Certificate Signing Request), pod który napastnik chce się podszyć.
  2. Dowolny, legalny klucz prywatny oraz certyfikat serwera SSL wydany przez znanego przeglądarce IE dostawcę (najczęściej będzie to VeriSign). Konieczność podania prawdziwych danych w celu zdobycia klucza i certyfikatu może zniechęcić niedoświadczonego włamywacza!
  3. Ostatnim elementem układanki jest podstawowy certyfikat VeriSign (dostępny na stronie firmy VeriSign).

Następne czynności są z punktu widzenia koncepcyjnego proste. Należy pakiet zawierający CSR podpisać kluczem prywatnym i opatrzyć certyfikatem VeriSign (dokładnie tak jak to robi urząd certyfikacyjny). Operacja taka jest możliwa pomimo flagi CA: False używanego certyfikatu, która oznacza, że nie jest on przeznaczony do podpisywania innych certyfikatów.

Przechwycenie Atak MITM na sesję SSL wymaga również przechwyruchu SSL cenia ruchu pomiędzy klientem oraz serwerem. Do tego celu można posłużyć się znanym pakietem dsniff (http://www.monkey.org/~dugsong/dsniff), zawierającym bardzo przydatne dla celów ataku MITM narzędzie – dnsspoof. Program ten dokonuje, dla celów późniejszego przechwycenia komunikacji SSL, ataku na serwer DNS (tzw. atak DNS spoofing, czyli atak podszywania pod serwer DNS).

Dnsspoof stanowi pewnego rodzaju pułapkę. Czeka on na żądanie Dnsspoof klienta kierowane do serwera np. banku internetowego. Żądanie takie, w akcji szczególnie gdy komunikacja jest nawiązywana po raz pierwszy, wymaga odpowiedzi serwera DNS zawierającego adres IP serwera docelowego. Zadaniem dnsspoof jest wychwycenie zapytania klienta o numer IP Sewera banku. Po przechwyceniu takiego zapytania dnsspoof zwraca odpowiedź ze sfałszowanym adresem IP, czyli z adresem atakującego.

W tym momencie klient jest już na łasce napastnika. Pod adresem zwróconym przez dnsspoof przygotowany jest już mechanizm, który zapewni powodzenie rzeczywistego ataku MITM. Zakładając, że do ataku posłuży script kid, to narzędziem tym będzie najprawdopodobniej webmitm (również będący częścią pakietu dsniff).

Webmitm nasłuchuje na porcie 443 TCP (najczęściej używanym przez SSL) połączeń inicjowanych przez oszukanych przez dnsspoof klientów. Webmitm przedstawia klientowi przygotowany wcześniej, fałszywy certyfikat wraz z łańcuchem certyfikacji składającym się na stworzony certyfikat oraz certyfikat VeriSign. W ten sposób klient uznaje, że serwer został autoryzowany, a komunikacja z nim jest bezpieczna. Dane są szyfrowane, atakujący, grając rolę serwera banku, ma pełen wgląd do niezaszyfrowanej postaci sesji. Aby nie wzbudzać podejrzeń, atakujący przesyła dane otrzymane od klienta innym tunelem SSL do prawdziwego serwera banku, który myśląc, że ma do czynienia z klientem, przesyła wszystkie wymagane dane. Także do tych danych ma dostęp atakujący. Dane te po przejściu przez maszynę włamywacza również są przekierowywane do klienta. W efekcie zarówno bank, jak i klient mają wrażenie, że połączenie między nimi jest prawidłowe – w końcu otrzymują przesyłane do siebie dane.

Z punktu widzenia włamywacza największym problemem w przedstawionym wariancie ataku MITM jest zdobycie prawidłowego certyfikatu serwera. Certyfikat można uzyskać, tworząc go samemu za pomocą ogólnie dostępnych CA lub wykorzystać legalny certyfikat dowolnej organizacji.

Wykorzystanie luki w IE to nie jedyny sposób na skuteczny atak na sesję SSL. Możliwe jest, przykładowo, ustawienie pomiędzy klientem i serwerem niewidocznego serwera pośredniczącego (transparent proxy), przechwytującego, deszyfrującego i odczytującego ruch SSL. W takim przypadku przeglądarka jednak zawsze wyświetla ostrzeżenie, że dane mogą być „podglądane” przez osobę trzecią. Niestety, daje także możliwość kontynuacji połączenia, z czego większość użytkowników skwapliwie korzysta (bo nawet nie zadali sobie trudu przeczytania ostrzeżenia).

Atak na serwer SSH
Secure Shell (SSH) jest kolejnym rozwiązaniem w zakresie zabezpieczania komunikacji. Tak jak w przypadku SSL bezpieczeństwo jest osiągane przez z mechanizmy szyfrowania. O ile jednak SSL to „tylko” zaszyfrowany TCP, SSH udostępnia o wiele większe możliwości. Można tunelować w nim praktycznie wszystkie popularne protokoły, ma on także funkcjonalność usług telnet i uniksowych usług r*.

Jak już udowodniliśmy, szyfrowanie danych chroni skutecznie przed podsłuchem, ale nie zapewnia ochrony przed atakami MITM. Dotyczy to zarówno SSL, jak i SSH czy innych podobnych technik. Pewnym utrudnieniem dla atakującego sesję SSH jest, tak jak w przypadku sesji SSL, konieczność posłużenia się techniką DNS spoofing. Trudność tego rodzaju nie będzie jednak zniechęcająca dla odpowiednio umotywowanego napastnika.

Używaj SSH w wersji co najmniej 2. Wersja pierwsza pozbawiona jest uwierzytelniania stron komunikacji, przez co szczególnie wrażliwa jest na ataki MITM. Darmową implementację SSH znajdziesz pod adresem: http://www.openssh.org.

Na bazie poniższego schematu można prześledzić krok po kroku atak na szyfrowaną sesję transmisji SSH (Secure Shell).

Klient wysyła do serwera DNS zapytanie o adres IP serwera SSH. Zapytanie jest podsłuchiwane przez napastnika. Zanim klientowi odpowie serwer DNS, napastnik podszywa się pod DNS i odpowiada, przekazując klientowi własny IP jako adres serwera SSH (rysunek 1).

Właściwy serwer DNS w końcu odpowiada klientowi, ale ten mając, już „odpowiedź”” ignoruje tę informację. W rezultacie klient nawiązuje połączenie z napastnikiem, mając go za serwer SSH (rysunek 2).

Dodatkowym aspektem tej fazy ataku jest wykorzystanie techniki ataku DNS spoofing. Pierwsze dwie fazy ataku MITM mogą napastnikowi sprawić największe problemy, zwłaszcza że ich częścią jest nie tylko wspomniany DNS spoofing, ale także atak Denial of Service (DoS – odmowa usługi).

W celu bardziej szczegółowego przedstawienia działań napastnika należy także pokrótce omówić mechanizm ataku DNS spoofing. Ataki na DNS są dość złożone, jednak wariant wykorzystywany w ramach ataków MITM jest, na szczęście napastnika, dość ograniczony. Polega on na tym, że napastnik sprawdza, jaki adres IP ma serwer DNS. Następnie inicjuje atak DoS skierowany przeciwko serwerowi DNS, tak aby nie mógł on odpowiadać na zapytania klienta. W dalszej kolejności napastnik czeka, aż klient wyśle do serwera DNS właściwie zapytanie o adres serwera docelowego usługi SSH. Klient otrzymuje odpowiedź spreparowaną przez napastnika, zawierającą adres IP będący tak naprawdę adresem IP komputera kontrolowanego przez napastnika. Oczywiście sfałszowany pakiet zawiera także podrobiony adres źródłowy (jako adres źródłowy podstawiany jest adres IP zablokowanego serwera DNS).

Zgodnie z rysunkiem 3 napastnik przedstawia klientowi fałszywy certyfikat, a sam nawiązuje połączenie z serwerem SSH, udając klienta.

W efekcie (rysunek 4) klient akceptuje uwierzytelnienie fałszywego serwera i przesyła mu swoje tajne dane. Te z kolei są przesyłane do właściwego serwera, który na nie odpowiada, przy czym odpowiedzi serwera są przez napastnika przejmowane i następnie przekazywane do klienta.

Legalni uczestnicy połączenia w ten sposób mogą nawet nie zauważyć, że komunikacja odbywa się za pośrednictwem komputera włamywacza. Jak więc widać, ogólny schemat ataku jest podobny jak w przypadku ataku na sesję SSL.

Spróbujemy prześledzić rzeczywiste działania potencjalnego napastnika (poniższe polecenia i programy dotyczą systemu GNU/Linux).

Po pierwsze, musi on ustawić swój komputer, tak aby przejmowane pakiety były przekazywane do uprawnionych stron sesji (tzw. ip forwarding):

echo „1” > /proc/sys/net/ip4/ip_forward

Aby sfałszować odpowiedzi DNS i w konsekwencji podać własny IP jako IP serwera SSH, należy na komputerze przechwytującym wydać polecenie:

dnsspoof –f dns.false

Parametrem jest tutaj nazwa pliku zawierająca odwzorowanie nazwy komputera atakującego na IP serwera DNS.

Ponadto napastnik na tym samym komputerze musi uruchomić program sshmitm (także z pakietu dsniff – w przypadku ataku na sesję SSL użylibyśmy webmitm).  sshmitm –I –p adres_serwera_SSH 22

Sshmitm użyty w powyższy sposób (z argumentem –I) umożliwia oglądanie na ekranie wszystkiego, co z klawiatury wprowadzi „ofiara”, czyli osoba korzystająca z komputera – klienta.

Jak widać, dzięki narzędziom powszechnie dostępnym w Internecie przeprowadzenie ataku MITM jest stosunkowo proste. Oczywiście nie jest to aż tak proste jak w przedstawionym powyżej schemacie. Zakłada on bowiem, że klient nie komunikował się do tej pory z serwerem SSH, napastnik jest obecny w sieci, do której należy klient, dokładnie wie, kiedy klient wysyła zapytanie do serwerów DNS i SSH oraz napastnikowi uda się przeprowadzić skuteczny atak DoS na serwer DNS.

Podsumowanie
Aby uniknąć przykrych skutków ataku na sesje SSH lub SSL, wystarczy jedynie odrobina spostrzegawczości. W przypadku ataku MITM na sesję SSL w momencie autoryzacji (tj. w momencie ataku) oprogramowanie klienta wyświetla komunikat, wskazujący, iż certyfikat jest prawidłowy, ale został wystawiony przez firmę niezaliczoną do grupy zaufania (użytkownik może mimo to, jeśli chce, kontynuować nawiązywanie połączenia).

W przypadku ataku na sesję SSH pewnym utrudnieniem dla atakującego jest to, że raz pobrany klucz publiczny serwera SSH przechowywany jest w lokalnej bazie certyfikatów serwera. Jeśli więc atak zostanie przeprowadzony na komputer, który już raz skutecznie łączył się z danym serwerem SSH, wówczas oprogramowanie klienckie zauważy zmianę certyfikatu i wyświetli odpowiedni komunikat, aczkolwiek pozostawi swobodę w zakresie decyzji o kontynuacji lub przerwaniu sesji.

W obu przypadkach wiele, zależy od użytkowników. Większość z nich nie czyta praktycznie żadnych komunikatów wyświetlanych przez oprogramowanie, a tylko mechanicznie potwierdza daną operację. Ataki MITM wykorzystują więc przede wszystkim lenistwo i brak spostrzegawczości. Dlatego najlepszym remedium na ataki MITM jest uważne czytanie wszystkich komunikatów, powiadamianie administratorów o anomaliach oraz instalowanie najnowszych poprawek do używanego oprogramowania i ciągłe uświadamianie użytkowników w kwestii potencjalnych zagrożeń.

PODZIEL SIĘ

BRAK KOMENTARZY

ZOSTAW ODPOWIEDŹ