hakin9_5_2004_atak_jabber_demo.pdf

Atak man in the middle na

szyfrowane połączenie Jabbera

Piotr Tyburski

Użytkownicy komunikatorów

sieciowych chcą mieć pewność,

że przesyłane przez nich dane

pozostaną poufne. Aby osiągnąć

ten cel, sięgają po wyrainowane

narzędzia kryptograiczne. Czy

to wystarczy do zapewnienia

pełnego bezpieczeństwa?

Gadu, do przesyłania wiadomości uży-

wają nieszyfrowanego tekstu. Z tego po-

wodu są niezwykle łatwe do podsłuchania. Więk-

szy poziom bezpieczeństwa oferują aplikacje ko-

rzystające z otwartego protokołu Jabber (patrz

Artykuł Paranoja w świecie komunikatorów

– Hakin9 3/2004). Wynika to z faktu, że z Jabbe-

ra można korzystać za pośrednictwem warstwy

SSL, zapewniającej poufność połączenia.

nie) – będzie więc mógł podsłuchiwać połącze-

nie. To właśnie jest nazywane atakiem man in

the middle .

Podstawowym warunkiem powodzenia ta-

kiego ataku jest dostęp do komputera pośred-

niczącego w przesyłaniu pakietów IP pomię-

dzy użytkownikiem a serwerem. Najprostszym

przypadkiem jest sytuacja, w której atakują-

cy ma dostęp do bramy w sieci (z prawami ad-

Człowiek w środku

Zastosowanie sprawdzonych algorytmów

szyfrowania z wykorzystaniem długich (512-

i 1024-bitowych) kluczy, renegocjowanych co

pewną ilość danych, skutecznie zabezpiecza

nas przed wyciekiem informacji z nawiązanego

połączenia. Nietrudno jednak wyobrazić sobie

sytuację, w której ktoś stanie na drodze nasze-

mu połączeniu z serwerem, podszywając się

pod niego (patrz Rysunek 1). Klient nawiąże

więc szyfrowane połączenie, tyle że nie – jak by-

śmy się spodziewali – z serwerem, lecz z innym

komputerem. Komputer ten natomiast połączy

się z pierwotnym celem i od tego momentu sta-

nie się pośrednikiem przesyłającym informacje

w obie strony (od serwera do klienta i odwrot-

Z artykułu nauczysz się...

• jak za pomocą iltra pakietów oraz progra-

mu socat przechwycić szyfrowane połączenie

Jabbera,

• jak postępować, aby mieć niemal stuprocentową

pewność, że nikt nie podsłucha sesji Jabbera.

Powinieneś wiedzieć...

• znać przynajmniej podstawy administracji syste-

mami uniksowymi,

• zakładamy, że czytelnik posiada podstawową

wiedzę o SSL,

• rozumieć, na czym polegają ataki man in the

middle (polecamy lekturę artykułu Snifing w

ethernecie z przełącznikami z numeru 2/2003).

www.hakin9.org

Hakin9 Nr 5/2004

P opularne komunikatory, takie jak Gadu-

Atak na szyfrowane połączenie Jabbera

Jak działa SSL

Kiedy irma Netscape projektowała standard SSL, chciała rozwiąząć problem ogrom-

nej podatności protokołu TCP/IP na podsłuchiwanie oraz ataki man in the middle. SSL

miał zapewnić zarówno szyfrowanie połączeń, jak i identyikację obu stron. Tę rolę

spełnia użyta w protokole technika certyikatów.

Połączenie SSL ( Secure Socket Layer ) jest tworzone na bazie zwykłego połącze-

nia TCP. Przesyłane nim dane szyfrowane są symetrycznie kluczem, który jest nego-

cjowany na początku sesji. W pierwszej fazie klient wysyła komunikat Client Hello za-

wierający informacje o wersji protokołu, identyikatorze sesji oraz o obsługiwanych al-

gorytmach kryptograicznych. Serwer odpowiada komunikatem Server Hello , w któ-

rym znajduje się nowy lub istniejący numer sesji oraz informacja o dopuszczalnych al-

gorytmach szyfrowania. W następnej fazie serwer uwierzytelnia się poprzez przesła-

nie swojego certyikatu. Klient sprawdza prawdziwość trzech warunków:

się na prawdziwym certyikacie serwe-

ra (patrz Ramka Jak działa SSL ).

Za pomocą pakietu OpenSSL

i dołączonego do niego skryptu po-

włoki CA.sh (ewentualnie jego perlo-

wej wersji CA.pl ) generujemy certyi-

kat CA (centrum certyikującego) oraz

certyikat serwera wraz z kluczami

prywatnymi. Skrypt CA.sh należy naj-

pierw zlokalizować w systemie:

$ locate CA.sh

• certyikat został podpisany przez znany i zaufany urząd certyikujący (ang. Certiica-

te Authority – CA ); najważniejsze takie urzędy to Verisign , Thawte czy AT&T ,

• certyikat jest prawidłowy i nie stracił ważności (ani nie został odwołany),

• nazwa na certyikacie odpowiada nazwie domenowej serwera.

Załóżmy, że CA.sh został znaleziony

w katalogu /etc/ssl/misc :

$ /etc/ssl/misc/CA.sh -newca

Jeśli choć jeden z nich nie jest spełniony, klient zgłasza ostrzeżenie i pozostawia użyt-

kownikowi decyzję o kontynuacji połączenia. Jeśli połączenie nie zostaje przerwane,

serwer może dokonać analogicznego uwierzytelnienia klienta. Następnie obie strony

generują tak zwany klucz master . Klucz ten wykorzystywany jest do utworzenia kluczy

sesji używanych później do szyfrowania i deszyfrowania oraz sprawdzania integralno-

ści danych przesyłanych w ramach sesji SSL. Na koniec przesyłane są zaszyfrowane

wiadomości informujące o zakończeniu działania protokołu powitalnego i może nastą-

pić wymiana danych.

Po uruchomieniu skryptu należy

jeszcze podać dane identyikacyj-

ne, które będą zapisane w certyika-

cie, oraz hasło. Utworzony zostanie

katalog ./ demoCA zawierający m.in.

plik cacert.pem (certyikat naszej in-

stytucji certyikującej) i cakey.pem

(klucz prywatny tego certyikatu).

Teraz należy wygenerować certy-

ikat dla naszego serwera. W tym celu

wykonujemy następujące polecenie:

ministratora). Przyjmijmy, że tak wła-

śnie jest. Jeśli atakujący nie ma do-

stępu do maszyny pośredniczącej,

może użyć technik w rodzaju ARP

spooing lub ARP poisoning (patrz

Artykuł Snifing w sieciach przełącza-

nych – Hakin9 2/2003).

Atak na szyfrowaną sesję Jabbe-

ra powiedzie się, jeśli agresorowi uda

się przechwycić próby nawiązania po-

łączenia z komputera klienta do por-

tu 5223 serwera i przekierować je do

innego komputera. Na tej maszynie

specjalny program musi przyjąć zaini-

cjowane połączenie i zaraz potem na-

wiązać kolejne, tym razem z właści-

wym adresatem. Spróbujmy więc wy-

konać prawdziwy atak.

$ /etc/ssl/misc/CA.sh -newreq

Skąd wziąć certyikat

Aby przechwycenie szyfrowanej sesji

miało jakiekolwiek szanse powodze-

nia, potrzebny będzie spreparowany

certyikat SSL serwera Jabbera – dzię-

ki temu klient Jabbera uzna, że ma do

czynienia z prawdziwym serwerem.

Podczas jego tworzenia należy oczy-

wiście podać takie dane, jakie znajdują

Znów trzeba podać kilka informacji

(podobnie jak przy generowaniu ca-

cert ) oraz hasło. Zostało nam już tyl-

ko podpisanie wygenerowanego cer-

tyikatu:

$ /etc/ssl/misc/CA.sh -sign

Po podaniu hasła do klucza prywat-

nego instytucji certyikującej otrzy-

mujemy podpisany cyfrowo certy-

ikat ./ newcert.pem oraz jego klucz

prywatny ./ newreq.pem .

��

Realizacja ataku

Czas na przeprowadzenie właściwe-

go ataku. Wspomnianym specjalnym

programem, który przechwyci dane

szyfrowanej sesji Jabbera, będzie

w tym przypaku socat (patrz Ram-

ka Socat – prawdziwy sieciowy kom-

bajn ), który posłuży za pośrednika

między użytkownikiem a serwerem.

W opisie przechwycenia sesji po-

służymy się dla ułatwienia imionami:

��

Rysunek 1. Schemat ataku man in the middle na sesję SSL Jabbera

Hakin9 Nr 5/2004

www.hakin9.org

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: